gomarble-ai is Poor to agents.
Discry independently scored how well an AI agent can discover and understand the gomarble-ai 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 · 24/100Comprehension
55% of score · 74/100What we found
- An agent trying to DISCOVER this API blind would struggle: there is no llms.txt, no llms-full.txt, no .well-known/mcp.json, and no OpenAPI/Swagger spec. The tool surface is only knowable by reading Framer-hosted HTML doc pages or the GitHub repo's manifest.json.
- Strong third-party discoverability partially rescues the gap — the Facebook Ads MCP server is listed on all three major registries (Glama, Smithery, PulseMCP) and the gomarble-ai/facebook-ads-mcp-server repo has 333 stars, so an agent searching MCP registries will find it even though the site publishes no agent-native discovery files.
- Comprehension is the standout dimension: each tool page uses a task-oriented 'Purpose / What it does / Sample Use Cases' structure, and a dedicated Limits page plus a Developer 'Best Practices' section give an agent clear capability boundaries and rate-limit expectations up front.
- Error-recovery guidance is genuinely agent-usable: the docs pair failure symptoms (HTTP 429, failed SSE connection, 'Client not found') with concrete fixes (implement 25 req/min limiting + exponential backoff, delete ~/.mcp-auth and re-authenticate, remove and re-add the integration).
- Structure quality is uneven — heading hierarchy skips levels (H1 jumps straight to H4, duplicated H1s) and there is no single summary or markdown endpoint, so an agent must stitch capability knowledge across five separate per-platform tool pages instead of one token-efficient overview.
What to change
Prioritized by impact on discoverability. You (or your docs platform) deploy these — Discry never touches your API.
- 01Publish an llms.txt at the site root that names each MCP tool (Meta Ads, Google Ads, Shopify, Google Analytics, Snowflake) with a one-line description and links to its doc page — this is the single highest-impact discovery fix and would move the failing Discovery score most.
- 02Add an AGENTS.md to the gomarble-ai/facebook-ads-mcp-server repo (and its siblings) with setup, auth, and tool-usage context for coding agents; the repo currently ships only readme.md and manifest.json.
- 03Expose the MCP tool schemas as a downloadable machine-readable spec (an llms-full.txt dump or a static tools.json), since the SSE/OAuth server gives agents no way to enumerate tools without first authenticating.
- 04Add a single 'All Tools' overview page (or fold every tool into llms.txt) so an agent can understand the full capability set in under 5,000 tokens instead of scraping five separate Framer pages.
- 05Document a formal error-response format — the JSON error shape, error codes, and messages returned by the MCP tools — so agents can branch on failures programmatically rather than pattern-matching prose troubleshooting steps.
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.
GoMarble ships an MCP (SSE) server rather than a REST API. Auth is OAuth 2.0 (plus an API-key flow for the Claude Desktop .dxt installer). Rate limits are explicitly documented (25 requests/minute, HTTP 429 with exponential-backoff guidance). No formal machine-parseable error-response schema, pagination model, or idempotency support is documented — an agent would infer error shapes from the underlying Meta/Google Graph APIs.