Write against the API that exists today

The failure this is for

An agent integrating someone else's API does not usually get stuck. It writes a call that is syntactically correct, idiomatic for the library, correctly typed, and aimed at a method that was renamed two major versions ago. Nothing complains until runtime, and in the worst version nothing complains at runtime either because the endpoint still exists and quietly no-ops.

This is a confidently-wrong failure rather than a visibly-stuck one, which makes it the expensive kind. The model is not hallucinating. It genuinely learned that API. It learned an older one.

The failure	What it looks like	What answers it
Training data froze the API	idiomatic call to a renamed method	version-pinned docs at write time
The docs lag the release	the page still lists a removed endpoint	releases, tags, closed issues
The docs are silent on a removal	nothing to read, so nothing looks wrong	the release notes, which say it

Two clocks, not two lookups

The pair is the whole stack, and the lazy version of it picks one and calls it done.

Context7 answers what the current documentation says. It is fast, covers an enormous range, and is a curated snapshot maintained by somebody else. The GitHub server answers what the source actually shipped, which is slower, needs you to know the repository, and is primary. When those two disagree the second one is right, and the case that matters is not disagreement but silence: a documentation site that has not mentioned a removal is indistinguishable from one where nothing was removed, and the release notes can tell those apart.

There is no item here for making an HTTP request

There was nearly a fifth item: an MCP server that wraps curl and returns the status, headers and raw body as typed JSON, so the agent sees the real response rather than an SDK's parsed idea of it. It is a real need. An agent that only ever sees a doc example's abbreviated JSON does not learn that the field is null in practice, or that pagination lives in a header nobody documented.

It is not here because the agent already has a shell, and the candidate was a 136-star wrapper around a command that has been installed on every machine for thirty years. Recommending it would have made this set look more complete without making anybody's integration work better.

What the search changed

Checked 2026-08-13.

This page had four items. Two of them were mocks: MockServer for standing where the vendor stands and failing on purpose, Keploy for standing where your application stands and recording real flows. The page argued they were less redundant than they looked.

Every stack in this directory then went through one grounded question: does any public source describe somebody running this combination, rather than these tools individually. Two things came back.

The first is that Context7 and the GitHub MCP server are genuinely paired in the wild, more than once, including in setups that add a filesystem server and name neither mock. That is the trio-minus-one shape: the documentation clock and the source clock travel together and the mocking layer is a separate decision people make separately.

The second is worse for the old page. Keploy's own material positions MockServer as an alternative to it, not as a complement. This stack was recommending two substitutes side by side and explaining at length why they were not the same thing. The vendor of one of them disagrees, in public.

That is a construction error rather than a taste difference, so both are gone. What remains is the pair the sources actually support, and the argument this page was always strongest on: two clocks, and silence on one of them is the case that costs you.

Nothing here should be read as a claim that mocking an API is unnecessary. It is that the choice between record-and-replay and stand-in-and-misbehave is a real fork, and a stack that hands you both without saying so is not selection.

Two items, and each one removed leaves a hole with a name.

claude mcp add context7 -- npx -y @upstash/context7-mcp