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
Iterating against production	every retry is a real charge or a real email	record once, replay after
The error path never ran	retry logic written, never executed	a dependency that fails on demand
They changed it and nobody noticed	works until a Tuesday	recorded flows as a suite

Two clocks, not two lookups

The pair worth understanding is the first two, because a lazy version of this set 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.

Two directions of mock

The second pair looks more redundant than it is. Both record traffic and replay it, and they point at different things.

MockServer stands where the vendor stands. You put it in front of your code and it answers as they would, including badly: latency, dropped connections, the 429 your retry logic was written for and has never seen. Most integrations ship an untested error path, not from negligence but because deliberately provoking a vendor's rate limiter is awkward to arrange.

Keploy stands where your application stands. It watches real flows at the network layer and hands back a test suite with the stubs already captured, which is the thing that fails on the morning the vendor changes a response shape without telling anybody. One rehearses a disaster; the other notices one.

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.

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

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