neuledge/context: an MCP server that ships library docs as local SQLite packages
Local-first documentation for AI agents
At a glance
- What is it?
- Context is an MCP server plus a community package registry that gives coding agents version-specific documentation instead of stale training data. It is worth adopting if your agent already speaks MCP and your stack is on the registry list; it is not a documentation generator for arbitrary codebases.
- Who is it for?
- Adopt Context if your agent is MCP-compatible and the libraries you ask about are on the registry or buildable with context add; skip it if you need doc coverage for a stack nobody has packaged and you are unwilling to author that package yourself.
- Can I use it commercially?
- Yes. Apache-2.0 is a permissive licence: you can use, modify and sell software built on it, as long as you keep its copyright and licence notices.
- Is it still maintained?
- Yes. The repository last received commits 7 days ago.
- What is it written in?
- Mainly TypeScript, according to GitHub's language statistics.
Answers come from the project's GitHub data, last synced on September 15, 2026, and from our analysis. They are not legal advice.
DEEP OPEN-SOURCE ANALYSIS
The failure mode Context targets: an agent citing an API that no longer exists
The README opens with a concrete illustration. An agent trained on AI SDK v5 documentation will suggest importing Experimental_Agent and stepCountIs from the ai package, while v6 moved to ToolLoopAgent. Nothing in that example is exotic. It is the ordinary result of training data having a cutoff date and library maintainers not having one. The project's own framing is blunt about where the fix lives: not in better prompting, but in giving the agent the right docs. That is the whole premise, and it is a narrower claim than the general pitch about AI and documentation. Context does not try to improve how a model reasons about an API. It tries to make sure the text the model reads describes the version the user is actually running. The intended user is a developer working inside an MCP-capable coding agent who has been burned by an import that the agent invented, or by a config key that was renamed two major versions ago. If you have never hit that, the tool has nothing to offer you.
What actually happens between a question and an answer
Context is an MCP server, and the README describes the flow in one sentence: the agent searches the registry, downloads the right package, and queries it locally. The registry is described as community-driven and as containing 100+ popular libraries already built. The storage format is stated directly under the Why Local section: docs are downloaded once and kept as compact SQLite databases in ~/.context/packages/. So the data path is query in, package downloaded if absent, SQLite read on disk, result returned to the agent. The README says local SQLite queries return in under 10ms, which is a claim about query latency on an already-downloaded package, not about the first fetch. Two things follow from that architecture. The first is that the expensive step is the initial download, not the lookup, which is why the project emphasizes installing once and configuring once. The second is that the registry is not a live service the agent depends on at query time. Once a package is on disk, the README states everything is local, and lists offline use as one of the properties. Whether the server re-checks the registry for updates is not described in the material available here.
Installing it and wiring it into an agent
The install is a single global npm command: npm install -g @neuledge/context. That puts a context binary on the path, and every integration in the README invokes it the same way, as context serve. For Claude Code the documented command is claude mcp add context -- context serve. For OpenAI Codex it is codex mcp add context -- context serve. Everything else is a config file edit. Claude Desktop reads claude_desktop_config.json from a platform-specific path (~/.config/claude/ on Linux, ~/Library/Application Support/Claude/ on macOS, %APPDATA%\Claude\ on Windows) and expects an mcpServers object with a command and args array. Cursor uses ~/.cursor/mcp.json globally or .cursor/mcp.json per project. VS Code with GitHub Copilot uses .vscode/mcp.json with a servers key and an explicit type of stdio, and the README notes it requires VS Code 1.102 or later. Zed nests the binary under command.path inside a context_servers block. Goose accepts YAML with a timeout field set to 300. OpenCode uses an mcp block with command as an array and enabled set to true. The pattern is uniform: one binary, one subcommand, stdio transport. The only real variation is the shape of each client's config schema.
context add, and the part of the story the registry does not cover
The registry is the reason the tool is described as plug and play, and the README is explicit that registry packages need no manual context install step. The coverage table lists frameworks (Next.js, Nuxt, Astro, SvelteKit, Remix, Hono), React ecosystem libraries, ORMs (Prisma, Drizzle, Mongoose, TypeORM), styling, testing, API and auth libraries, and AI SDKs. That is a mainstream JavaScript and TypeScript selection, and it is the honest boundary of the product as shipped. For anything outside it, the documented escape hatch is context add, which builds a package from a git repository, a local directory, or a specific version tag. The README gives context add https://github.com/your-company/design-system, context add ./my-project, and context add https://github.com/vercel/next.js/tree/v16.0.0 as examples, and mentions websites exposing llms.txt as a supported source. The README text available here is truncated mid-command in that last section, so the full flag set for context add cannot be confirmed from this material. What can be said is that the escape hatch exists and that using it means you own the package. The registry is community-maintained and the README invites pull requests to add libraries, which is a reasonable model and also means coverage tracks whoever showed up to write the package.
Where the local-first design costs you something
The privacy and offline arguments are real and follow from the architecture: queries do not leave the machine, and a downloaded package works without a network. The cost is that freshness becomes your problem. A registry package is a snapshot of documentation at the time someone built it. The README does not describe any automatic refresh of already-downloaded packages, and no release history was retrieved for this review, so there is no way to state how quickly a package tracks an upstream release. That matters precisely because the project's own motivating example is a version break. If your agent is querying a stale local package, you have reproduced the original problem with extra steps. The second constraint is scale. SQLite packages of documentation are small, but 100+ of them accumulate, and the README does not describe any eviction or pruning command. The third is that Context is a retrieval layer, not a correctness layer. It hands the agent better text. It does not stop the agent from ignoring that text, and it does not verify that the code the agent writes compiles against the version you have installed.
How this differs from pointing an agent at docs another way
The obvious alternative is letting the agent fetch documentation itself, either by browsing vendor sites or by reading context files you maintain in the repository. The difference is where the version pin lives. With a vendored markdown file or an AGENTS.md-style document, you write and update the text by hand, and it drifts silently the moment you bump a dependency. With web fetching, the agent gets whatever the site serves today, which may be the latest version rather than yours, and it depends on the network being available and the site being reachable. Context's approach is to make documentation a versioned artifact that is downloaded and stored locally, so the retrieval step is deterministic and offline. A second alternative is a general-purpose retrieval or indexing tool over your own repository. That answers questions about your code, not about the third-party library's API surface, which is the specific gap Context fills. The trade is that you are trusting a community package to represent the library accurately. Nothing in the README describes a review or verification process for registry entries.
Licence, maintenance and what adoption actually commits you to
The repository is Apache-2.0, which permits commercial use and modification and includes an explicit patent grant. The README states the project is free with no subscriptions, rate limits or usage caps, and the package is published on npm as @neuledge/context. No releases were retrieved for this review, so there is no version history to reason about, and the last push date on the default branch is recent. Operationally, the maintenance surface is small: one global npm install, one config entry per client, and a ~/.context/packages/ directory that grows. The recurring cost is not the server, it is the registry. Every library you rely on either has a package that someone keeps current or it does not, and if it does not, context add puts the build and its upkeep on you. That is the honest accounting. The server is cheap to run; the documentation supply chain is the thing that needs an owner. None of this is legal advice, and if you redistribute packages built from third-party documentation, the terms attached to that documentation are a separate question from the Apache-2.0 licence on the code.
Editorial conclusion
Adopt Context if your agent is MCP-compatible and the libraries you ask about are on the registry or buildable with context add; skip it if you need doc coverage for a stack nobody has packaged and you are unwilling to author that package yourself. Before rolling it out to a team, verify three things: that context serve starts and is visible in your agent's MCP server list, that a registry query for one library you actually use returns the version you expect, and that the packages under ~/.context/packages/ survive whatever machine image or container your team rebuilds from. The registry is community-maintained, so the coverage question is answered by the registry directory itself, not by this article.
Community notes