# How docspack compares docspack overlaps with several things an agent can already do. The differences are worth being precise about, because most of them are not about capability but about which version of the truth reaches the model, and how much of it. ## docspack is an MCP server, and does not need to be "Why not just use MCP?" is a category error, and a common one. MCP is the protocol an agent uses to call a tool; it says nothing about what is behind the tool. docspack ships an MCP server — `docspack mcp` — so the comparison is not docspack versus MCP. It also does not require one. `docspack ask ""` returns the same text from the same code path, so the recommended setup is a line in AGENTS.md rather than a server. That costs no per-client configuration, no resident process, and no tool definition sitting in the context window for a session that may never ask a question. The real comparison is with documentation MCP servers that fetch from the web on each call. Those return whatever the vendor publishes today, which is rarely the version in your lockfile; they need the network on every query; and they usually return whole pages, because they have no chunk-level index to rank against. docspack answers from packages installed in `node_modules`, so the version matches by construction, nothing is fetched, and the response is ranked and bounded. ## Agent skills solve a different problem A skill teaches an agent how to do something: your review checklist, your deploy runbook, the house style for a commit message. It is authored once, lives with the agent, and is loaded as a whole document when it applies. Dependency documentation has a different shape. It changes when you bump a version, it is far larger than any context window, and it should be identical for everyone on the team regardless of which agent they use. Encoding it as a skill means one person maintaining a copy that silently drifts from the installed version. docspack ships it as a dependency instead, so it updates with `npm update` and reads the same for every agent on the team — whether they call `docspack ask` or the MCP tool. Skills and docspack compose: a skill that says "check the docs before answering API questions" is more useful when the docs are actually there. ## Vendoring documentation into the repository Copying a library's Markdown into `docs/vendor/` or pasting it into `CLAUDE.md` gets the content local, which is the right instinct. Two things go wrong. The copy has no version attached, so nobody notices when it describes a release you no longer run. And an agent either loads the whole file, which spends context on prose that answers nothing, or greps it, which finds the word but not the section. docspack keeps the content local and adds the two missing pieces: a version, and an index that returns the passage rather than the file. ## Vector databases and RAG A hosted vector store gives you semantic search, which finds a passage that means the same thing in different words — genuinely better recall than keyword search for vague questions. The costs are an embedding pipeline, a service to run, an ingestion step that has to be repeated whenever a dependency changes, and a network round trip per query. For documenting the libraries a project already installs, that machinery is aimed at a problem you do not have: the corpus is small, already written in the vocabulary the user types, and already versioned by the package manager. SQLite's FTS5 with porter stemming handles it with no service, no ingestion pipeline, and no round trip. ## The llms.txt convention `llms.txt` is a publishing convention: a Markdown index a project puts at a well-known URL, listing its documentation. It solves discovery, and docspack builds on it — `docspack build` can generate a package from one. It is not a retrieval system. Reading an llms.txt still means fetching the pages it links to, over the network, at whatever version the site serves. docspack turns that content into versioned, chunked, locally indexed packages. ## What it costs in context The concrete case, measured against Hono's published documentation: - everything the project publishes, as one file: about 92,000 tokens - the same content as a documentation package: 309 chunks, about 62,000 tokens on disk - what one query returns: 833 to 1,040 tokens across three chunks The middle number never reaches the model. The index holds it; a query spends about one percent of the first number, and the response is capped at 3,000 tokens no matter what is asked. Token counts are estimated at four characters per token.