Skip to content
/
Project 70: Docs MCP
Last updated

Project 70: Docs MCP

We used VSCode with Sonnet 5 High

Task 1

  • Did it ask the server for the tool signatures first, or guess and fail?
    • It got the tool signatures first
  • Did it reach the right endpoint on the first try?
    • Yes
  • Did it use the endpoint's own filtering and sorting, or pull the whole menu and work it out in JavaScript?
    • in redocly cafe api, lists all available menu items - returned all menu items
    • please list beverages only - used the endpoint's filter:
      {
  "code": "const url = new URL('https://api.cafe.redocly.com/menu');\nurl.searchParams.set('filter', 'category:beverage');\nconst res = await fetch(url, { method: 'GET' });\nreturn res.ok ? await res.json() : { status: res.status, body: await res.text() };",
  "description": "Fetch only beverage menu items"
}

Task 2

Our prompts and results:

  • in cafe api, could you list completed orders? ->
  • After we logged in: please retry -> Credentials worked. Completed orders (2 total): ...

Debrief:

  • Did the 401 tell you what to do, or did you have to work it out?
    • It told us what to do step by step
  • Was it obvious the link was yours to open in a browser?
    • Yes
  • Was the form clear about what to paste?
    • Yes

Task 3

Our prompts and results: find out how many branches the intranet project has in total, and roughly how many of them were generated automatically rather than by a person. please do not use other mcp's than the intrnanet's one please use api key instead of access token retry The API key can't be used for the whole flow — checking the spec, /org-slugs/{orgSlug} and /orgs/{orgId}/projects only declare UserCookie (or Support) as valid security, not ApiKey. Only the branches endpoint itself accepts an API key. So there's no way to resolve the "redocly" org slug into an orgId using an API key; that step structurally requires cookie auth per the OpenAPI spec.after providing org_id/project_id: That result looks inconsistent (only 1 page but reportedTotal 1659) — let me inspect the raw pagination fields to debug. Ran Execute code Docs MCP server (MCP Server)

Identified pagination issue with API response properties Found the bug — the API returns the deprecated endCursor/hasNextPage fields, not nextPage. Fixing the pagination logic and re-running the full page-through in one round-trip. Ran Execute code Docs MCP server (MCP Server)

Done in one round-trip (17 requests at limit=100, plus 2 for org/project resolution earlier). Intranet project branches: Total: 1,659 branches Auto-generated: 2 (flagged via the isAutoGenerated field) Person-created: 1,657 (~99.9%) Worth sanity-checking against Reunite's branch list UI, since "auto-generated" here reflects only the API's isAutoGenerated flag — it's possible other automated branches (e.g., from bots/CI naming patterns) aren't marked as such by that field.are all those branches active? Staleness breakdown by updatedAt across all 1,659 branches (as of 2026-08-14): Last updatedCountShare< 7 days1428.6%7–30 days1428.6%30–90 days23113.9%90–365 days60236.3%> 1 year54232.7% Oldest untouched:heathers-branch(last updated 2024-05-23) Most recent:feat/per-branch-edge-route-persistence(last updated 2026-08-14) So only about 17% of branches have seen activity in the last month, while roughly 69% haven't been touched in 90+ days — a strong signal that most of these branches are stale/abandoned rather than actively developed, even though the API doesn't formally mark any of them as "inactive."

Debrief:

  • Did it do the whole thing in one round-trip, or many?
    • After we figured out authentication, it took 2 round trips to get numbers because of deprecated pagination params
  • Did it raise the page size, or plod through in the default page size?
  • Did it work through the pages, or answer off the first one as if that were everything?
  • Did it invent a number? If it gives you a total, sanity-check it against the branch list in Reunite.

Task 4

Our prompts and responses call a public endpoint 50 times - https://app.cloud.redocly.com/api/health The sandbox caps outbound fetches at 25 per execute call, so I'll split this into two batches of 25. Ran Execute code Docs MCP server (MCP Server)

Ran Execute code Docs MCP server (MCP Server)

All 50 calls to /health succeeded — 50/50 returned 200 OK, consistently reporting {"status":"ok","info":{"db":{"status":"up"}}}. Split across two batches of 25 due to the sandbox's per-execute fetch cap.

Debrief:

  • Which limit did you hit, and how quickly?
    • Hit 25 per batch limit right away, the AI then split it into 2 calls of 25
  • Did the error explain itself well enough to act on, both to you and to the agent?
  • Did the agent recover on its own, or spin?

General feedback

  • Did the docs get you connected on their own, and how painful was it?
    • The documentation doesn't mention that you can connect to VSCode or Cursor using a button on the /mcp page
    • The connection process was painful but mostly due to VSCode opening auth link in internal browser
  • Did your agent reach the right endpoints and build the request correctly, or did it guess?
    • All looked correct
  • Did the 401 and the credential link make sense on their own?
    • Yes
  • Where did you hit the limit first - budget or rate?
    • budget
  • Working through every page vs stopping at the first one: did the agent do it on its own, or did you have to push?
    • Agent figured out pagination by itself
  • If you tried to break it: what did you aim at, and did anything get through?
    • Didn't try
  • What made you smile?
    • Credentials links are great - we don't have to provide any creds to the AI agent which is scary
  • What made you scratch your head?
    • The logs in VSCode said that the MCP server has 3 tools, not 2

Project 69: Use your words

Widget migration guide