neuledge/context: local documentation packages for MCP agents

The problem: agents trained on documentation that no longer matches the code

The README opens with a concrete failure. An agent that has absorbed AI SDK v5 documentation will suggest importing Experimental_Agent and stepCountIs from the ai package, while v6, according to the README, changed the API to ToolLoopAgent. The agent is not confused or under-prompted. It is answering from training data that describes an older release, and it has no way to check which version the user actually installed. The project's own framing is blunt: "The fix isn't better prompting. It's giving your AI the right docs."

That positions Context against prompt-engineering workarounds. Instead of asking an agent to be more careful about version numbers, you give it a retrieval path to documentation that was built for a specific release. The target user is an engineer running an MCP-compatible coding agent, typically on a JavaScript or TypeScript codebase, who is tired of correcting imports and method signatures by hand. It is less useful to someone whose agent already has live access to the exact documentation they need.

How Context works: an MCP server over a package registry and local SQLite

Context is an MCP server. The agent connects to it over stdio, and when a question needs library documentation, the server searches the community registry, downloads the matching package, and queries it locally. The README describes the whole flow as automatic: "no manual context install needed for registry packages." The registry is described as community-driven with 100+ libraries already built, spanning frameworks (Next.js, Nuxt, Astro, SvelteKit, Remix, Hono), the React ecosystem (React, React Router, TanStack Query, Zustand, Redux Toolkit), databases and ORMs (Prisma, Drizzle, Mongoose, TypeORM), styling (Tailwind CSS, shadcn/ui, Styled Components), testing (Vitest, Playwright, Jest, Testing Library), APIs and auth (tRPC, GraphQL, NextAuth.js, Passport), and AI and LLM tooling (LangChain, AI SDK, OpenAI, Anthropic SDK).

The storage model is the part worth pausing on. Downloaded docs live as compact SQLite databases under ~/.context/packages/, which is why the README can claim sub-10ms local queries, offline operation, and that queries never leave the machine. There is no hosted query endpoint in that description, so the privacy and latency claims follow from the architecture rather than from a service-level promise. The trade-off is that the registry is the only automatic source. Anything outside it has to be built by hand.

Installing Context and connecting it to Claude Code

The package is published on npm as @neuledge/context and installed globally. The README does not list a minimum Node version, so check that yourself before installing.

npm install -g @neuledge/context

After that, the binary is context. For Claude Code, registration is a single command:

claude mcp add context -- context serve

For an agent that reads a JSON config instead, the README gives the same server definition across Claude Desktop, Cursor, Windsurf and OpenCode. The Cursor form goes in ~/.cursor/mcp.json for a global server or .cursor/mcp.json for a project-scoped one:

{
  "mcpServers": {
    "context": {
      "command": "context",
      "args": ["serve"]
    }
  }
}

Clients with their own config format get their own shape. OpenAI Codex uses TOML in ~/.codex/config.toml:

[mcp_servers.context]
command = "context"
args = ["serve"]

Goose uses YAML in ~/.config/goose/config.yaml, and the README sets a 300-second timeout there:

extensions:
  context:
    type: stdio
    command: context
    args:
      - serve
    timeout: 300

VS Code with GitHub Copilot is the one client with a stated version floor: the README says it requires VS Code 1.102+ and puts the entry in .vscode/mcp.json under a servers key with "type": "stdio". Zed uses a context_servers key with a nested command object holding path and args, and the README tells you to check the Agent Panel for a green indicator. In every case the first real use is the same: restart the client where the README says to, then ask something like "How do I create middleware in Next.js?" and watch whether the agent pulls version-specific documentation instead of guessing.

Where Context stops being the right tool

The registry is the ceiling. It covers popular open-source libraries, and the README is explicit that everything else falls to context add: private repos, internal libraries, sites with llms.txt, or anything not yet listed. That is a real cost, not a footnote. A team whose work depends on an internal design system or a vendor SDK will be authoring and refreshing their own packages, and the README does not describe how those local packages are updated when the upstream source changes. If you need automatic freshness, the registry is the only path that gives it to you.

The second boundary is scope. Context answers documentation questions. It is not a web search tool, not a code index of your own repository, and not a substitute for reading a changelog when you are planning an upgrade. The README's AI SDK example shows what it fixes: an agent suggesting an import that no longer exists. It does not claim to catch semantic changes that keep the same signature, and nothing in the README suggests it validates your code against the docs it serves.

A smaller operational point: the docs land in ~/.context/packages/. On a managed machine with a locked-down home directory, or in a container where you want the cache somewhere else, the README does not document a path override. Treat that as something to test before standardising on Context across a team.

Context compared with pointing an agent at hosted documentation

The obvious alternative is a hosted documentation service: an agent queries a remote API and gets back documentation chunks. The difference is where the corpus lives and who pays for the query. A hosted service can index sources you never packaged, and it updates without you doing anything. Context inverts both properties. The corpus is a set of packages you or the community built, and the queries run against SQLite files on your disk. That buys offline operation, predictable latency, and no rate limits or usage caps, which the README lists as the reasons for going local. It costs you coverage: a library nobody has packaged is a library your agent cannot look up automatically.

A second alternative is simply keeping documentation in the repository and letting the agent read files, which many coding agents already do. That works when the docs are short and current, and it fails in exactly the case the README describes, where the agent's training data is more confident than the files it has. Context's answer is a queryable index rather than raw text, which is why the flow can be automatic. The honest comparison is coverage against freshness: a hosted index reaches more sources, a local package registry is faster and works on a plane.

Maintenance, release process and the Apache-2.0 licence

The repository is a pnpm and Turborepo monorepo. The root package.json is private and delegates build, test and lint to turbo, with Biome for formatting and linting, Changesets for versioning, and pnpm 10.27.0 pinned as the package manager. Releases run through a versions script that applies Changesets, then a release script that builds, publishes every workspace package, and tags each one with its name and version before pushing tags. That is a conventional setup for a multi-package TypeScript project, and it means the published npm package and the repository move together through the same pipeline.

The last push to the default branch was on 2026-09-08, which is recent enough that the project is not dormant. There are no releases in the repository data to compare against, so version history is something to check on npm directly rather than infer from the repository. The licence is Apache-2.0. That permits commercial use and modification, and it includes an explicit patent grant, but it also carries notice and attribution obligations when you redistribute the code. If you fork the server or ship packages derived from registry entries, read the licence text rather than assuming permissive means unconditional. None of this is legal advice; the LICENSE file is the authority.

Editorial conclusion

Adopt Context if your agents routinely answer with APIs from a library version you no longer run, and you want those answers served from a local SQLite store rather than a hosted documentation API. Skip it if the libraries you depend on are private, unlisted and undocumented, because you would be building and maintaining every package yourself with context add. Before rolling it out, verify three things: that the libraries you use most appear in the registry, that your agent's MCP client accepts a stdio server entry, and that ~/.context/packages/ is an acceptable place for downloaded documentation to live.

Frequently asked questions

Official sources

1. Issues
2. License: Apache-2.0
3. neuledge/context on GitHub
4. README