Snipcart is Poor to agents.
Discry independently scored how well an AI agent can discover and understand the Snipcart 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 · 12/100Comprehension
55% of score · 91/100What we found
- An agent that already knows the Snipcart docs URL gets near-textbook comprehension: every endpoint opens with a task-oriented summary, realistic curl + JavaScript examples (real-looking GUID tokens, geeks@snipcart.com, plausible prices), and clean markdown — comprehension scored 91/100 (A).
- But an agent trying to DISCOVER Snipcart programmatically hits a wall: no robots.txt, no llms.txt/llms-full.txt, no .well-known/mcp.json, no AGENTS.md, and no publicly downloadable OpenAPI/Swagger spec. Discovery scored 12/100 (F), dragging the overall to 55 (D).
- Standout positive the rubric under-weights: Snipcart ships a FIRST-PARTY MCP Server (38 tools, documented at docs.snipcart.com/v3/mcp-server) with dedicated use-case and error-handling pages — an agent can operate the store conversationally without ever touching the REST API. It appears in community MCP lists (awesome-mcp-servers) but could not be confirmed in Glama/Smithery/PulseMCP.
- Capability boundaries are unusually well documented for agents: inline ⚠️ callouts warn that products can't be created via the API, that PUT only reads inventory fields, that status changes can capture Stripe payments, and that DELETE only archives — exactly the 'you can't do that' signals that stop an agent failing blindly.
- The sitemap.xml is the only machine-discovery asset present and it does list the v3 API-reference pages, so a crawler that finds the domain can at least enumerate the docs.
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 docs root that summarizes the REST API (base URL https://app.snipcart.com/api, HTTP Basic auth, the orders/products/refunds/subscriptions resources) and links to the MCP Server pages — this is the single highest-impact discovery fix and is largely a copy job from the existing intro page.
- 02Expose a downloadable OpenAPI/Swagger spec (the API is .NET-based, so a Swagger endpoint likely already exists internally) — this is the heaviest-weighted discovery check (weight 5) and would let agents and SDK generators consume the API directly.
- 03Add a robots.txt to docs.snipcart.com that explicitly allows GPTBot, ClaudeBot, Google-Extended, and CCBot — a missing robots.txt currently scores as a fail even though nothing is actually blocked.
- 04Add an AGENTS.md to the public Snipcart MCP Server repo and primary integration repos so coding agents get first-party setup context.
- 05List the official Snipcart MCP Server in Glama, Smithery, and PulseMCP so agents discovering capabilities via MCP registries find the first-party server rather than third-party community builds.
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 characteristics are clearly documented: HTTP Basic auth with a secret key, a machine-parseable JSON error body (message + per-parameter errors map + optional reason), and offset/limit pagination with totalItems. Rate limiting is acknowledged on POST /products ('don't call in a tight loop') but no numeric limits or rate-limit headers are specified, and no idempotency keys are documented.