Teamwork is Good to agents.
Discry independently scored how well an AI agent can discover and understand the Teamwork API from what’s public — not whether it’s usable. Below: every signal we checked, what’s costing the score, and what to change.
SCORED UNDER RUBRIC 1.2 · A full re-launch under Discry Score 2.5 — a new behavioral instrument, not comparable to these scores — is in progress.
Discovery
45% of score · 74/100Comprehension
55% of score · 75/100What we found
- An agent can natively integrate without scraping docs at all: Teamwork ships an official MCP server discoverable via /.well-known/mcp.json (valid JSON with five named profiles, OAuth2/bearer auth, and endpoints) and is listed as an official server on both PulseMCP and Glama — a top-tier discovery outcome most APIs fail.
- An agent looking for AI-readiness signals finds a well-structured llms.txt and an AI-permissive robots.txt (GPTBot, ClaudeBot, Google-Extended, PerplexityBot, OAI-SearchBot all allowed; only the /launchpad login area is blocked) — Teamwork actively courts AI crawlers.
- The llms.txt is product/marketing-focused (company info, service offerings, sales links) rather than API-focused, so an agent trying to learn the API from it gets no endpoint or auth guidance — it must fall back to the separate apidocs.teamwork.com site.
- Endpoint reference is genuinely agent-usable: task-oriented descriptions, exhaustively documented query params with allowed values and defaults, and realistic copy-pasteable code samples in Python/PHP/JavaScript with plausible IDs, names, and dates.
- There is no clean, publicly downloadable OpenAPI/Swagger file — the docs are spec-backed and interactive but the raw spec isn't offered as a download, and the referenced swaggerdocs repo now 404s, so an agent can't ingest a machine-readable contract in one fetch.
What to change
Prioritized by impact on discoverability. You (or your docs platform) deploy these — Discry never touches your API.
- 01Publish a downloadable OpenAPI 3.x spec at a stable, public URL (e.g. apidocs.teamwork.com/openapi.json) for V3 — the highest-weighted discovery signal and the fastest way for an agent to ingest the full API contract in one request.
- 02Add an API-focused llms.txt (or llms-full.txt) that links to authentication, paging, error codes, and core V3 endpoints — the current llms.txt is product-focused and gives an agent no path into the API surface.
- 03Include the apidocs.teamwork.com documentation pages in a sitemap (the current sitemap only covers the marketing site), so agents crawling for API docs can enumerate every endpoint and guide.
- 04Add end-to-end, multi-step workflow guides (e.g. 'create project → add tasklist → assign task → log time') with error handling, beyond the current feature-level guides for auth, paging, and custom fields.
- 05Tighten the error-codes guide with explicit, per-parameter recovery steps (the current 400/422/500 entries are informal — 'developer fatigue', 'naughty step' — and don't tell an agent which field was wrong or how to fix it).
Execution coverage · INFORMATIONAL, UNSCORED
Whether an agent can actually complete a call and recover from errors is the deeper Audit layer — documented here, but not part of the Discry Score.
Execution characteristics are well documented: Basic and OAuth 2.0 auth with curl examples, a dedicated error-codes guide (400/401/403/404/422/500 with common causes), rate limiting (150 req/min, HTTP 429, X-Rate-Limit-Limit/Remaining/Reset headers with UTC-epoch reset), and thorough pagination docs (page/pageSize params, x-page/x-pages/x-records headers, V3 meta object with hasMore/pageOffset). Idempotency keys are not mentioned.