# Mem0 docs: AI Agent Readiness Score 73.8% (C) **73.8% · 59/80 · AI Agent Readiness Score · 9/30 reading points · 50/50 agent surface points** Mem0 received 1 PASS votes and passed 5 of five agent surface checks. The clearest finding came from the find the exact limits task. - Tested: 2026-08-20 - Published: 2026-09-21 - Battery: v1 - Scoring: reading 30 pts · surface 50 pts - Docs: https://docs.mem0.ai/ Three AI models, GPT 5.6 Sol, Claude Opus 5, and DeepSeek v4 Flash, each read Mem0’s public documentation independently and attempted five first-hour developer jobs: store and search the first memory, find the exact limits, recover from a 429, verify a memory webhook, use the Python SDK. No accounts, API calls, or code execution were used. Every verdict came from public pages and every published quotation passed a live verification check. ## Freshness [How rechecks work](https://docsforagents.com/methodology/#freshness) - Category: [Agent frameworks & memory](https://docsforagents.com/grades/?category=agent-frameworks) - Tested: 2026-08-20 - Quotes verified: 2026-08-20 - Surface rechecked: 2026-09-21 No change since the test. 5 of 5 quoted passages still appear on the live pages. ## Agent surface checks · 50/50 | Check | Verdict | Points | | --- | --- | --- | | llms.txt | PASS | 10 | | llms-full.txt | PASS | 10 | | Markdown mirror | PASS | 10 | | MCP server | PASS | 10 | | Docs AI | PASS | 10 | ## The Reading Test · 9/30 | Task | GPT 5.6 Sol | Opus 5 | DeepSeek v4F | Consensus | | --- | --- | --- | --- | --- | | Store and search the first memory | PARTIAL | PARTIAL | PARTIAL | PARTIAL | | Find the exact limits | FAIL | FAIL | PARTIAL | FAIL | | Recover from a 429 | FAIL | FAIL | FAIL | FAIL | | Verify a memory webhook | FAIL | FAIL | PARTIAL | FAIL | | Use the Python SDK | PARTIAL | PARTIAL | PASS | PARTIAL | Docs platform: Mintlify (unscored) · verified 2026-08-20 ## What to fix first These 5 fixes could add up to 21 points to the AI Agent Readiness Score. The list ranks each fix by the points it would add. [How the ranking works](https://docsforagents.com/methodology/#what-to-fix-first) 1. **+6 points · Recover from a 429 · FAIL** **Found:** The API reference defines no 429 response or retry timing, and only a changelog entry states the Add rate limit. **Fix:** Document the 429 response and the Add rate limit in the API reference. State the retry wait and whether a retried Add creates duplicates. **Evidence:** [docs.mem0.ai/api-reference/memory/add-memories](https://docs.mem0.ai/api-reference/memory/add-memories) 2. **+5 points · Find the exact limits · FAIL** **Found:** The docs give no per-plan limits, and mem0.ai/pricing lists add, retrieval, and project limits but no throughput limit. **Fix:** Publish a docs page with each plan's monthly add, retrieval, and project limits and its API throughput limit. **Evidence:** [docs.mem0.ai/core-concepts/memory-operations/add](https://docs.mem0.ai/core-concepts/memory-operations/add) 3. **+5 points · Verify a memory webhook · FAIL** **Found:** The Webhooks page says to verify the source but documents no verification method or delivery retry behavior. The Create Webhook path also conflicts with its own code samples. **Fix:** State how to verify a webhook request's origin and what Mem0 does after a failed delivery. Use one Create Webhook path in its spec and code samples. **Evidence:** [docs.mem0.ai/platform/features/webhooks](https://docs.mem0.ai/platform/features/webhooks) 4. **+3 points · Store and search the first memory · PARTIAL** **Found:** The quickstart shows Add returning results at once, but the Add Memories reference says Add returns an event_id to poll. **Fix:** Show the PENDING Add response and a GET /v1/event/{event_id}/ poll in the quickstart before the Search step. **Evidence:** [docs.mem0.ai/api-reference/memory/add-memories](https://docs.mem0.ai/api-reference/memory/add-memories) 5. **+2 points · Use the Python SDK · PARTIAL** **Found:** The Python quickstart searches right after client.add, but the Add Memory page says add returns PENDING and needs a poll. **Fix:** In the Python quickstart, show the PENDING result of client.add and poll the event before client.search. **Evidence:** [docs.mem0.ai/core-concepts/memory-operations/add](https://docs.mem0.ai/core-concepts/memory-operations/add) ## What the docs get right - **Use the Python SDK: 1 PASS votes.** The Python quickstart searches immediately after Add, contradicting the documented pending SDK response and required poll. - **Store and search the first memory: 0 PASS votes.** The cURL quickstart shows immediate results, contradicting the asynchronous Add response that requires polling before Search. - **5 of 5 agent surface checks.** Present: llms.txt, llms-full.txt, markdown mirrors, an MCP server, docs AI. ## Store and search the first memory **PARTIAL** PARTIAL consensus from 3 PARTIAL. The cURL quickstart shows immediate results, contradicting the asynchronous Add response that requires polling before Search. The quickstart gives one unambiguous auth-add-search path with a working cURL sequence, but it shows Add returning a synchronous results array of ADD events while the Add Memories API reference and the Add Memory concept page state the call is asynchronous and returns status PENDING with an event_id to poll, so an agent cannot tell whether the search step will find the memory immediately. The path from zero (account, API key, add, search) is navigable, but the quickstart cURL response format contradicts the Add Memories API reference: one shows synchronous results, the other shows async event polling. ## Find the exact limits **FAIL** FAIL consensus from 1 PARTIAL, 2 FAIL. No page gives all requested limits by plan; the attempted pricing and rate-limit pages returned no content. The documentation site names no plan and publishes no numeric add, retrieval, project, or throughput limit; llms.txt lists no pricing or limits page, the Platform Overview and Platform vs Open Source pages carry no quota table, and the only numeric figures live off the docs site on https://mem0.ai/pricing, which itself lists monthly add, retrieval, and project counts but no API throughput limit. Monthly add/retrieval/project limits exist on the marketing site, but per-plan API throughput limits are absent. The pricing page is not part of docs.mem0.ai. ## Recover from a 429 **FAIL** FAIL consensus from 3 FAIL. The current Add reference documents no 429, Retry-After timing, or safe retry behavior; only a 2025 changelog gives 1,000/min. The Add Memories OpenAPI block documents only 400 and 401 responses, no page on the docs site mentions HTTP 429, a Retry-After header, rate-limit response headers, backoff timing, or whether a retried add is safe against duplication, and the only documented per-time-window limit anywhere is the Agent Mode signup cap of five per day per IP address. The docs do not state the applicable per-plan limit, retry timing, or safe retry behavior for a 429 response. The changelog mentions a single global rate limit but offers no recovery guidance. ## Verify a memory webhook **FAIL** FAIL consensus from 1 PARTIAL, 2 FAIL. The docs give payloads but no verification mechanism or delivery retry policy, and the REST path conflicts with cURL. Creation and payload shape are documented, but the source-verification step is stated as an instruction with no mechanism behind it, since the docs publish no signing secret, no signature header, no timestamp field, and no source IP range, and they define no delivery retry schedule, retry count, timeout, or failure notification, while the Create Webhook page contradicts itself by declaring the path /api/v1/webhooks/projects/{project_id}/ and then shipping cURL, PHP, Go, and Java samples that POST to https://api.mem0.ai/api/v1/webhooks/your_project_id/webhook/. Creating a webhook and receiving its payload are documented. However, source verification (no signing key or secret) and delivery retry behavior (no schedule or backoff) are stated as goals without concrete mechanisms. ## Use the Python SDK **PARTIAL** PARTIAL consensus from 1 PASS, 2 PARTIAL. The Python quickstart searches immediately after Add, contradicting the documented pending SDK response and required poll. pip install mem0ai, MemoryClient(api_key=...), client.add(messages, user_id=...) and client.search(query, filters={...}) match the REST v3 contract field for field, including the rule that entity IDs are top level on add and inside filters on search, but the quickstart prints an immediate add result while the same SDK call is documented elsewhere as returning status PENDING with an event_id, so the example output contradicts the API it wraps. The SDK example mirrors the REST API: install, initialize, add with messages plus entity ID, search with query plus filters. The parameters, entity scoping, and response shape are consistent between the SDK and REST examples on the same page. ## The receipt > Managed quotas per workspace No page gives all requested limits by plan; the attempted pricing and rate-limit pages returned no content. - [docs.mem0.ai/core-concepts/memory-operations/add](https://docs.mem0.ai/core-concepts/memory-operations/add) ## Agent surface notes Initialize returned an MCP Bearer OAuth challenge with valid resource metadata. The live docs expose a public Ask Assistant control. ## Method note This is a reading test of public documentation, not an execution test. No accounts were created and no API calls were run. The AI Agent Readiness Score counts fifteen reading votes at PASS 2, PARTIAL 1, and FAIL 0, for 30 possible points. Five agent surface checks add 10 points each. The total is 80. Consensus chips show each row majority and do not affect scoring. The panel split on 3 of five tasks. Quotes shown here were re-fetched and confirmed verbatim on 2026-08-20. Methodology: https://docsforagents.com/methodology/ Canonical URL: https://docsforagents.com/reports/mem0-docs-ai-agent-readiness/