Together AI is Agent-Ready to agents.
Discry independently scored how well an AI agent can discover and understand the Together AI 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 · 86/100Comprehension
55% of score · 96/100What we found
- An agent discovering Together AI finds a near-complete readiness surface: robots.txt explicitly opts into AI training and input (Content-Signal: ai-train=yes, ai-input=yes), a 42KB API-focused llms.txt index, a 1.8MB llms-full.txt, a valid OpenAPI 3.1 spec with embedded code samples, and a live .well-known/mcp.json pointing to a docs MCP server.
- Error recovery is exemplary — every status code from 400 to 529 has an explicit cause and fix, and rate-limit docs prescribe exponential backoff keyed to the x-ratelimit-reset header. An agent hitting a 429, 403, or 402 is told exactly what to change rather than left to guess.
- Every documentation page is served as clean markdown (append .md to any URL) with multi-language, copy-pasteable code samples (Python/TypeScript/cURL) and OpenAI-compatible snake_case naming, so an agent can parse and execute without HTML wrangling.
- The main discovery gap is the absence of an AGENTS.md in any primary togethercomputer repo (together-python, together-typescript, openapi, MoA all 404) — a coding agent cloning the SDK gets no repo-level instructions, though the docs do ship 'agent skills' and a live MCP server as an alternative.
- Dozens of end-to-end workflow guides (RAG pipeline, AI search engine, step-by-step batch jobs, conditional workflows) mean an agent can chain operations for real tasks, not just call endpoints in isolation.
What to change
Prioritized by impact on discoverability. You (or your docs platform) deploy these — Discry never touches your API.
- 01Add an AGENTS.md to the primary SDK repos (together-python, together-typescript, openapi) — the single highest-impact discovery fix. At weight 3 it would lift the discovery score from 86 to ~100.
- 02Document idempotency keys (or explicitly state which write endpoints are non-idempotent and their safe-retry semantics) so agents can retry create/upload calls without risking duplicate side effects.
- 03Publish a tighter 'core capabilities' overview, or trim the 42KB llms.txt index, so an agent can grasp the primary inference surface in under 5,000 tokens without parsing the full index.
- 04Pursue an official, first-party MCP server listing in the major registries (Glama, Smithery, PulseMCP currently surface only third-party image-generation wrappers) so the canonical Together MCP is the top discovery hit.
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 documented thoroughly. Auth is a single Bearer API key in the Authorization header (account signup uses Google/GitHub OAuth, but the API itself is key-based). Errors return OpenAI-shaped JSON objects ({error:{message,type,code}}) with a full status-code table. Rate limits are dynamic per-model, surfaced via 429 plus an x-ratelimit-reset header with exponential-backoff guidance. Pagination is cursor-based (after/--after). Idempotency keys are not documented — retry safety is described informally for transient 5xx errors only.