LangChain is Agent-Ready to agents.
Discry independently scored how well an AI agent can discover and understand the LangChain 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 · 95/100Comprehension
55% of score · 96/100What we found
- An agent looking to build against LangChain lands on best-in-class discovery infrastructure: llms.txt + a 12.6MB llms-full.txt, a clean .md version of every one of the ~1,400 sitemap'd pages, a live /.well-known/mcp.json endpoint, AGENTS.md in every major repo, and a robots.txt that explicitly opts in with 'Content-Signal: ai-train=yes, ai-input=yes'. LangChain treats agents as first-class doc consumers.
- A public OpenAPI 3.1 spec (api.host.langchain.com/openapi.json, 200 OK) plus per-endpoint .md pages mean an agent can machine-read the full Control Plane and Agent Server API surface without scraping rendered HTML.
- Endpoint documentation is genuinely task-oriented, not just interface dumps: tag descriptions explain concepts ('An assistant is a configured instance of a graph'), and operation descriptions tell you what happens and what to call next ('use POST /assistants/{assistant_id}/latest to change versions').
- Code examples are strong and copy-pasteable across Python, JavaScript, and bash, with provider-specific tabs (OpenAI, Anthropic, Gemini, Bedrock, Azure, Ollama) — an agent can pick the right snippet for its stack.
- The main drag on the score is sheer size: llms.txt is ~100KB (a site-wide index rather than a right-sized API summary), and core capabilities are spread across langsmith/oss/langgraph/api-reference trees, so full comprehension costs more tokens than an ideal single overview.
What to change
Prioritized by impact on discoverability. You (or your docs platform) deploy these — Discry never touches your API.
- 01Publish a right-sized, API-focused llms.txt (or an llms-api.txt) under ~50KB that summarizes the core Agent Server / Control Plane capabilities and links to the key endpoint .md pages, so agents get an efficient entry point instead of a ~100KB site-wide link dump.
- 02Surface rate limits and Retry-After header semantics directly in the REST API reference (Control Plane / Agent Server), not just in the SDK how-to pages, so an agent calling the HTTP API learns its limits before hitting a 429.
- 03Add explicit recovery guidance to the API-level error responses (e.g. what specific field failed validation on a 422, how to resolve a 409 conflict) rather than only returning typed error schemas, mirroring the excellent per-error troubleshooting pages the SDK already has.
- 04Add a concise 'API overview' page that maps the split doc trees (langsmith / oss / langgraph / api-reference) so an agent can orient the full surface in a single sub-5,000-token read.
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 to a high standard. The Deployment Control Plane and Agent Server APIs ship a public OpenAPI 3.1 spec with typed error responses (ErrorResponse, HTTPValidationError) covering 404/409/422, X-Api-Key/Bearer/Tenant auth, and idempotency-style controls (client-supplied UUID assistant_id plus if_exists: raise|do_nothing). Rate-limit and retry behavior (429, Retry-After, exponential backoff, max_retries) is documented mainly at the SDK layer rather than the REST layer. Claims are documentation-only and would require a live Discry Audit to verify.