Miro is Needs Work to agents.
Discry independently scored how well an AI agent can discover and understand the Miro 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 · 57/100Comprehension
55% of score · 87/100What we found
- An agent searching for Miro's API would find it easily: the OpenAPI spec is published on a public GitHub repo (miroapp/api-clients) and linked directly from the API reference overview, official MCP servers are listed on Glama and Smithery, and Miro maintains its own miroapp/miro-ai repo with an AGENTS.md and Claude Code skills — an unusually deliberate investment in agent-readiness.
- Comprehension scored a strong 87 (B): endpoint docs are task-oriented ('Unique identifier of the board where you want to create the item'), code examples span five languages (Shell, Node, Ruby, PHP, Python) with an interactive 'Try It' console, and multi-step guides (OAuth end-to-end, hello-world quickstart) show an agent how to chain operations rather than just listing endpoints in isolation.
- The biggest discovery gap is the missing llms.txt and llms-full.txt — an agent that looks for the now-standard agent entrypoint hits a 404 and must crawl the ReadMe-hosted docs page by page, with no concise capability summary to anchor on.
- No sitemap.xml exists at the docs domain (404), so an agent cannot cheaply enumerate which documentation pages exist.
- Error recovery is uneven: the 429 rate-limit case has excellent, actionable guidance (implement exponential backoff, read X-RateLimit-Reset), but 400/404 responses are only labelled ('Malformed request', 'Not found') on endpoint pages with no fix guidance — an agent hitting a validation error must guess which parameter was wrong.
What to change
Prioritized by impact on discoverability. You (or your docs platform) deploy these — Discry never touches your API.
- 01Add an llms.txt (and ideally llms-full.txt) at developers.miro.com that summarizes core API capabilities and links to OAuth, the key board/item endpoints, and rate limits. This is the single highest-impact discovery fix — it improves both the llms.txt and llms.txt-quality checks at once.
- 02Publish a sitemap.xml at the docs domain listing documentation and reference pages so agents can enumerate the docs without blind crawling.
- 03Extend the strong 429 recovery model to 400/404 errors: state which parameter was invalid and the valid value ranges, so an agent can self-correct instead of guessing.
- 04Standardize or explicitly document the casing split — path/query params use snake_case (board_id) while JSON bodies use camelCase (teamId) — so agents don't have to track two conventions.
- 05Add a .well-known/mcp.json pointing at Miro's official MCP server to make agent tool-discovery automatic rather than registry-dependent.
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 documentation is strong: OAuth 2.0 authorization code flow is fully documented with both expiring/refresh-token and non-expiring variants, errors return a machine-parseable JSON envelope (status, code, message, context, type), rate limits are documented as a credit system (100,000 credits/min, weighted tiers) with X-RateLimit-Limit/Remaining/Reset headers, and list endpoints use cursor-based pagination. No idempotency-key support is documented.