# Context: nine agent configs, one command, and docs cached in SQLite

> Context is an MCP server that attacks the problem of agents answering confidently from stale training data by fetching library documentation on demand, and its practical cost is a per-client configuration file, since nine supported agents want the same server described five different ways.

**neuledge/context** — Local-first documentation for AI agents

- Repository: https://github.com/neuledge/context
- Stars: 417 · Forks: 48
- Language: TypeScript
- License: Apache-2.0
- Published: 2026-09-10 · Updated: 2026-09-10 · Language: en
- Canonical page: https://hysenlabs.com/projects/neuledge-context

## The problem is version drift, and the example is a major bump

The README opens by naming the failure mode precisely: agents are trained on outdated documentation, so when a library ships a new version the model does not know and answers confidently anyway. The example given is an AI SDK major, and it is the right one to pick because nothing in the old names survives the rename:

```js
// Your AI, mass-trained on AI SDK v5 docs, will suggest:
import { Experimental_Agent as Agent, stepCountIs } from 'ai';

// But v6 changed the API entirely:
import { ToolLoopAgent } from 'ai';
```

The conclusion drawn from it is short. The fix is not better prompting, it is giving the agent the right documentation. Everything else in the project is machinery for that one sentence, and the failure it is defending against is not a hallucination in the usual sense but a correct answer to a question about an API that no longer exists.

## One global install, then nine clients want five config shapes

Installation is a single global command:

```bash
npm install -g @neuledge/context
```

After that the server is always the same, a command called `context` with the argument `serve`, and the only work is telling your agent where it lives. Two clients take a shortcut, `claude mcp add context -- context serve` for Claude Code and `codex mcp add context -- context serve` for Codex. The other seven need a config file, and the shapes differ in ways worth knowing before you start. Claude Desktop, Cursor and Windsurf all use an `mcpServers` key with a command and an args array, at different paths per operating system. VS Code uses `servers` instead, wants a `type` of stdio, and additionally requires version 1.102 or later with GitHub Copilot, after which you click a Start button in the file. Zed uses `context_servers` with the command as a nested object holding a path and args. OpenCode uses an `mcp` key with the command written as a single array.

## Docs are downloaded once into SQLite and then queried locally

The storage model is what makes the local-first claim concrete. Documentation is downloaded once and stored as compact SQLite databases under `~/.context/packages/`, and after that everything happens locally. The properties listed in response are derived from that single decision: local SQLite queries return in under ten milliseconds, the tool works offline including on flights, queries never leave the machine, there are no subscriptions, rate limits or usage caps, and there are no outages, API changes or service shutdowns to plan for. The agent side is automatic. When documentation is needed, the agent searches the registry, downloads the matching package and queries it, and the README is explicit that no manual `context install` step is needed for registry packages. The other file formats in play are a TOML block for Codex config and a YAML extensions block for Goose, which also carries a timeout value.

## The registry is a hundred-odd community packages in seven categories

What the agent can find is a list, and the list is maintained by contributors rather than by the project. The framing is a package manager for documentation, and the categories cover frameworks such as Next.js, Nuxt, Astro, SvelteKit, Remix and Hono; the React ecosystem including React Router, TanStack Query, Zustand and Redux Toolkit; databases and ORMs with Prisma, Drizzle, Mongoose and TypeORM; styling with Tailwind CSS, shadcn/ui and Styled Components; testing with Vitest, Playwright, Jest and Testing Library; APIs and auth with tRPC, GraphQL, NextAuth.js and Passport; and AI tooling with LangChain, the AI SDK, OpenAI and the Anthropic SDK. Anyone can add to it by opening a pull request, and the browser link points at the registry directory in the repository itself, so the catalogue is the repository's content as much as its code.

## Version pinning is the whole argument, not a side feature

It is easy to read this as a documentation search tool and miss that pinning is the point. The stated outcome of a question is a version-specific answer rather than a generally plausible one, and that only holds if the agent is reading docs for the version in front of it. The manual build command therefore takes a full source URL including a tag, so a package can be built from a specific release of a library rather than its default branch. The example given is a Next.js URL pinned to a version tag, which is the shape you would copy for a library where the default branch has already moved on. Registry packages carry the same idea implicitly, since each one is a snapshot built at a point in time. Nothing in the documentation describes rebuilding a package automatically when upstream moves, so freshness is a manual or scheduled concern rather than a property of the system.

## Internal libraries are the case the registry cannot cover

Beyond the community list, the same command builds a package from anywhere documentation exists. Four forms are shown. A git repository, given as a URL, which covers a design system hosted on GitHub at an internal address. A local directory on disk. A specific version tag on a repository. And a website that publishes an llms.txt file, with a framework documentation site given as the example. That last one is the cheapest path for a library that has never been packaged, since a site that already publishes machine-readable documentation for language models needs no scraping setup. Private repositories and internal libraries are named explicitly as supported, which is the case a general-purpose documentation site cannot serve and the clearest reason to run this locally rather than point an agent at a public site.

## Sharing a package is a database file, not a rebuild

Once a package exists, distributing it does not mean rebuilding it. The export step names the package and gives it a version and a destination directory, and what lands there is a portable `.db` file:

```bash
# Export a package
context add ./my-project --name my-lib --pkg-version 2.0 --save ./packages/

# Teammate installs it (no build step needed)
context add ./packages/my-lib@2.0.db
```

The install command takes the file path with the version embedded in the filename, and the README stresses that no build step is needed on the receiving machine. That has a practical consequence for teams: the person who prepared the documentation is the one who decided what was scraped and at which version, and everyone else inherits that snapshot. It also means a hand-built internal package travels the same way a registry package does, with no difference in what the agent ends up reading.

## A private root manifest that publishes and tags each package itself

The root of the repository has no name and no version. It is marked private and its scripts exist only to orchestrate: build, test, lint and fix all delegate to Turbo, releases are versioned with changesets, and the release script runs a build, publishes recursively, and then executes a shell loop that reads each package's own name and version with jq, creates a git tag of the form package-at-version if that tag does not already exist, and pushes the tags. So every published package carries its own version and its own tag rather than sharing one project version, which is why the registry can hold independently versioned documentation snapshots. Tooling is Turbo for orchestration and Biome for linting and formatting, with pnpm 10.27.0 declared as the package manager and esbuild as the only dependency allowed to run build scripts. Alongside sit a server specification, instructions for agents, rule files for two other coding agents, and a directory entry for the MCP listing.

## Conclusion

Context fits a team whose agents are confidently wrong about library APIs, since it is built around the version in your project rather than the version in the training data, and it fits a team with internal libraries that nobody has documented publicly. It does not fit someone who wants a hosted documentation service with guaranteed upstream freshness, because the trade is explicit: docs are downloaded once and then frozen on your disk. Three things to know before wiring it up. The installation is global and the integration is per client, with two clients offering a one-line command and the rest wanting an edit to JSON, TOML or YAML, in several cases under a different key name than you might expect. The corpus is whatever the community has built, so those hundred-odd packages are a community list rather than a vendor guarantee, and anything missing has to be built by hand. And the packaging is a private monorepo that publishes and git-tags each package in its own loop, so version numbers in the registry are per package rather than one project version. Apache-2.0, last pushed on 30 September 2026, no tagged releases.

## FAQ

### What does the Context MCP server do?

It gives an AI agent version-correct documentation for popular libraries. The agent searches a community registry of more than a hundred pre-built documentation packages, downloads the one it needs and queries it locally, so the answer matches the library version in your project rather than whatever the model was trained on.

### How do I install Context and connect it to my agent?

With `npm install -g @neuledge/context`, then one MCP configuration entry pointing at `context serve`. Some clients have a shortcut, `claude mcp add context -- context serve` and `codex mcp add context -- context serve`, while the others need an edit to a JSON, TOML or YAML config file, sometimes under a different key name.

### Where does Context store the documentation it downloads?

As compact SQLite databases under `~/.context/packages/`. After the first download the queries are local, which the project lists as the reason for sub-10ms queries, working offline, and no query leaving the machine. Registry packages need no manual install step.

### Can Context index documentation for an internal library?

Yes. `context add` builds a package from a git repository, a local directory, a specific version tag on a repository, or a website that publishes an llms.txt file, so private repositories and internal libraries work the same way registry packages do.

### How do I share a Context package with a teammate?

Export it with a name, a package version and a save directory, which writes a portable .db file, and the teammate installs that file directly with `context add`, with no build step on their side. Packages can also be pinned to a specific source tag so the docs match a specific library release.

## Sources

- [Issues](https://github.com/neuledge/context/issues)
- [License: Apache-2.0](https://github.com/neuledge/context/blob/main/LICENSE)
- [neuledge/context on GitHub](https://github.com/neuledge/context)
- [README](https://github.com/neuledge/context/blob/main/README.md)

---

Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/neuledge-context