The freshness argument here cuts both ways though. Search_docs/read_doc always serving the current production docs kills staleness against the docs site, but the actual repo the agent is writing into is very often pinned to an older release of whatever SDK it's touching. I hit a version of this building a GraphQL skill for Hashnode's own API: the schema we described was correct for the live API, but an agent still confidently wrote a field that had been renamed since whatever training data or cached doc it half-remembered, and the fix wasn't fresher docs, it was reading the live schema at call time instead of trusting any static description, live or not. Does read_doc have a way to pin to whatever version is actually in package.json/requirements.txt, or does it always resolve to latest regardless of what the target repo is running? If it's always latest, you've traded "hallucinated from stale training data" for "hallucinated from a newer API than what's installed," which is a smaller bug but the same shape.
When an agent codes in Cursor, there are two distinct context needs:
Local repository state: Handled locally by Cursor’s codebase indexing, linters, and composer looking at your branch/lockfile.
External platform contracts & API documentation: This is where models hallucinate deprecated endpoints, renamed parameters, or deleted SDK methods because the training cutoff is outdated.
The Docs MCP specifically solves the second problem: giving the agent a live, zero-hallucination ground truth of the production API/SDK specs on demand, without polluting your prompt window with 500 lines of static markdown. Local code stays local; documentation stays fresh.
Appreciate you reading and sharing this thought!
The freshness argument here cuts both ways though. Search_docs/read_doc always serving the current production docs kills staleness against the docs site, but the actual repo the agent is writing into is very often pinned to an older release of whatever SDK it's touching. I hit a version of this building a GraphQL skill for Hashnode's own API: the schema we described was correct for the live API, but an agent still confidently wrote a field that had been renamed since whatever training data or cached doc it half-remembered, and the fix wasn't fresher docs, it was reading the live schema at call time instead of trusting any static description, live or not. Does read_doc have a way to pin to whatever version is actually in package.json/requirements.txt, or does it always resolve to latest regardless of what the target repo is running? If it's always latest, you've traded "hallucinated from stale training data" for "hallucinated from a newer API than what's installed," which is a smaller bug but the same shape.