metricool is Needs Work to agents.
Discry independently scored how well an AI agent can discover and understand the metricool 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 · 67/100Comprehension
55% of score · 69/100What we found
- An agent looking for a machine-readable spec would succeed: a genuine, publicly downloadable OpenAPI 3.0.1 spec (swagger.json / swagger.yaml, title 'Metricool API' v2.0.0, 100+ tagged services) is linked straight from the docs landing page and returns 200 with no auth wall.
- An agent would readily discover the API through the ecosystem: Metricool ships an official MCP server (ai.metricool.com/mcp, PyPI mcp-metricool) listed on PulseMCP, Glama, Smithery and Zapier, with dedicated help articles for ChatGPT, Claude Code, Cursor, Make and n8n.
- An agent parsing the spec hits friction: many OpenAPI paths carry blank summaries and generic '200 OK' / 'Forbidden' responses with no error schema, so failure semantics must be learned by trial rather than read.
- The docs lean on a human-in-the-loop: the primary recommended way to find an endpoint is 'open your browser's Network tab and inspect the XHR calls,' which an autonomous agent cannot do — several endpoints are documented only this way.
- Naming and multi-step guidance are strong: consistent camelCase and ISO-8601 datetimes throughout, plus documented end-to-end workflows (get blogId, normalize the media URL, then create the post) in the PDF guide and help center.
What to change
Prioritized by impact on discoverability. You (or your docs platform) deploy these — Discry never touches your API.
- 01Publish an API-scoped llms.txt (or llms-full.txt) at app.metricool.com that links the swagger spec, the auth model, and the core scheduling/analytics workflows, instead of relying on the help-center-wide dump at help.metricool.com/llms.txt.
- 02Enrich the OpenAPI spec: add summaries/descriptions to every path, replace bare '200 OK' / 'Forbidden' with a documented machine-parseable error schema (code + message), and declare 401/429 responses so agents can self-correct on failure.
- 03Add an AGENTS.md to the public metricool/mcp-metricool repo (currently 404s to crawlers) covering tool usage, auth setup, and the blogId/userId conventions coding agents need.
- 04Document API rate limits with their response header names, and add a dedicated capabilities/limitations page covering plan-based caps (e.g. free-tier 3-month data window, 20-post limit) so an agent learns boundaries before hitting them.
- 05Reduce reliance on 'inspect your browser Network tab' for discovery — fully describe every integrator-facing endpoint in the spec so autonomous agents don't need a human-driven UI step.
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 static token sent in the X-Mc-Auth header alongside mandatory userId and blogId parameters on every call. Pagination exists in the spec (JsonPaging / PageInfo offset schemas) but is not explained in prose. OpenAPI error responses are minimal ('OK', 'Forbidden') with no machine-parseable error schema, and neither API rate limits nor idempotency keys are documented. A separate help-center 'Common errors' page provides human-readable recovery steps for a handful of scenarios.