Pinecone is Agent-Ready to agents.
Discry independently scored how well an AI agent can discover and understand the Pinecone 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 · 100/100What we found
- An agent looking for Pinecone would find it effortlessly: every discovery signal fires — robots.txt fully allows AI crawlers, a structured llms.txt and a 3.9MB llms-full.txt are published, a valid .well-known/mcp.json points to a hosted docs MCP server, and the official Pinecone Assistant MCP is listed in public registries.
- Pinecone has invested directly in agent tooling rather than just agent-friendly docs: official Claude Code, Cursor, and Gemini CLI plugins, AGENTS.md files in primary SDK repos (go-pinecone, examples), and dedicated /AGENTS-PYTHON and /AGENTS-JAVASCRIPT machine-readable instruction pages.
- Every documentation page is retrievable as clean markdown (.md suffix) and the official OpenAPI spec is public on github.com/pinecone-io/pinecone-api, so an agent can ground itself on canonical schemas without scraping rendered HTML.
- Comprehension is best-in-class: code examples span 6+ languages with realistic values, multi-step quickstart and RAG/search workflows are documented end-to-end, and a dedicated Error handling guide tells agents what to DO on each error class — exactly the self-correction guidance agents need.
- The only soft spots are scale-related: the llms.txt index is ~74KB (above the ~50KB agent-consumption guideline) and llms-full.txt is ~3.9MB, so a naive agent ingesting everything would burn budget — though the structured per-page .md retrieval mitigates this.
What to change
Prioritized by impact on discoverability. You (or your docs platform) deploy these — Discry never touches your API.
- 01Trim or split the llms.txt index below ~50KB (e.g., a lean core index linking to section-specific llms.txt files) so agents can load the map without spending ~18K tokens up front.
- 02Document idempotency explicitly — clarify the id-based upsert overwrite semantics and whether any idempotency-key mechanism exists for create/control-plane operations, so agents can safely retry writes after timeouts.
- 03Enumerate tool declarations inline in .well-known/mcp.json (or link a tool manifest) so agents can discover available MCP capabilities without first connecting to the server.
- 04Add a top-level 'limits at a glance' / capability-boundary summary page surfaced in llms.txt, consolidating the rate limits, quotas, and serverless feature gaps that are currently spread across multiple pages.
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 exceptionally well documented: conventional HTTP status codes with a dedicated Errors reference and a separate production Error handling guide (retry logic, 4xx vs 5xx), explicit per-namespace rate limits (100 rps for query/upsert/delete/update, 429 TOO_MANY_REQUESTS) plus read/write-unit limits and plan quotas, and pagination tokens for list operations. Idempotency keys are not documented (upserts are id-based overwrites rather than key-protected).