Mem0 is Agent-Ready to agents.
Discry independently scored how well an AI agent can discover and understand the Mem0 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 · 98/100Comprehension
55% of score · 96/100What we found
- An agent arriving cold would self-serve end to end: robots.txt explicitly permits AI crawlers (Content-Signal ai-train=yes) and points to a full sitemap, while an exceptional llms.txt opens with a 'For agents reading this file' section that mints an evaluation API key in <5s via CLI — no email, no dashboard, no OTP.
- The llms.txt is a model of agent-first design: every link is scope-tagged [Platform]/[OSS]/[Both], product routing is explicit (which SDK import signature maps to which docs), and it links directly to the OpenAPI spec, the live MCP server, and the source repo — so an agent loads only what it needs.
- Endpoint docs are answer-first and task-oriented: method, URL, and purpose ('Extract and store memories from a conversation using the V3 additive pipeline') sit at the top, with realistic multi-language examples (Python/JS/cURL/CLI), real-looking UUIDs, and both 200 and 400 response bodies shown inline.
- Discovery signals are near-complete: a valid OpenAPI 3.0.1 spec (33 paths / 52 operations) at /openapi.json, an AGENTS.md in the primary repo describing the polyglot monorepo, and official MCP server listings on Glama, Smithery, and PulseMCP — an agent can find and wire this API from any entry point.
- The main gap is operational boundaries: an agent would not learn concrete rate limits, Retry-After behavior, or idempotency-key support from the docs, and /.well-known/mcp.json points at a Mintlify preview host (mem0.main-kill-isr.mintlify.me/mcp) rather than the production https://mcp.mem0.ai endpoint documented elsewhere.
What to change
Prioritized by impact on discoverability. You (or your docs platform) deploy these — Discry never touches your API.
- 01Fix /.well-known/mcp.json to advertise the production MCP endpoint (https://mcp.mem0.ai) instead of the Mintlify preview URL, and declare the auth requirement — this is the one discovery signal below pass and an easy full-credit fix.
- 02Document concrete rate limits: publish per-tier request ceilings, the rate-limit response header names, and explicit 429 + Retry-After recovery guidance so agents can back off correctly instead of discovering limits by failing.
- 03Add an idempotency section (idempotency-key header support, or an explicit statement that add() is naturally additive) so agents can safely retry writes without duplicating memories.
- 04Consolidate error recovery into one reference table mapping each status code (400/401/402/429/5xx) to a specific cause and fix action, complementing the strong but scattered FAQ guidance.
- 05Publish a top-level capability-boundaries page (max messages per add, metadata size limits, expiration semantics, supported entity scopes) so an agent can reason about limits before hitting them.
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.
Auth is a single documented scheme: 'Authorization: Token <api-key>', reinforced in the OpenAPI securitySchemes. Error responses are shown per-endpoint (e.g. 200/400/401 example bodies) and the OpenAPI 3.0.1 spec defines error responses across operations. Pagination is page/page_size on list endpoints. Async add returns an event_id polled via GET /v1/event/{event_id}/. No specific numeric rate limits, rate-limit header names, or idempotency-key support are documented in the pages scanned.