DocsAgent: a local MCP document index for Claude Code, Cursor and OpenClaw

The gap DocsAgent is trying to fill between an agent and a folder of files

An agent running in Claude Code or Cursor can read a file you paste into the conversation, and it can run shell commands if you let it. What it cannot do is answer a question that requires looking across a thousand documents it has never seen. DocsAgent targets exactly that gap. The README frames the problem as agents being blind to private desktop documents, and the product is a local index plus a Model Context Protocol server that gives the agent a search tool over that index. The intended user is someone with a personal or professional document archive (legal contracts, research papers, a Zotero library, an Obsidian vault) who wants agent assistance without sending the archive to a hosted service. The README states that all parsing, indexing and vector storage happen on the user's hardware. That claim is the entire pitch, and it is also the claim a prospective adopter has the least material to verify, because the README does not describe where the index lives or what format it takes.

What the MCP server actually exposes to an agent

The integration model is narrow and easy to reason about. DocsAgent runs as a stdio MCP server started with docsagent server, and the README lists two tools the agent gains: search, described as deep semantic search returning relevant snippets, and add_docs, which indexes new folders or files mid-conversation. Three more tools (list_documents, remove_document, status) are listed as coming soon, which means an agent today can add to the index but cannot enumerate or prune it through MCP. Removal is a CLI-side operation at best, and the CLI reference does not list a remove command either. That asymmetry matters in practice: once a document is indexed, the documented paths for taking it back out are thin. The README also mentions a SKILL.md file that carries usage instructions for the DocsAgent skill, but the supplied material does not include its contents, so what that file adds beyond the MCP tool descriptions cannot be confirmed.

Install, index, search: the three commands that matter

Setup is a global npm install: npm install -g @docsagent/docsagent. Indexing takes one or more paths, and the README shows directories rather than single files in its example: docsagent add ~/Documents/Legal_Archive ~/Documents/Research. Querying is a single positional argument: docsagent search "What are the key terms in the Barclays contract?". The CLI reference adds aliases, dag and da, so dag add <path> and da search "query" are equivalent forms. Two further commands round out the surface: docsagent status reports engine and indexing status, and docsagent stop stops the background engine service. That stop command implies a long-lived process separate from the CLI invocation, which is a design detail worth noting. The README does not say whether the engine starts automatically on the first add or search, what port or socket it uses, or what happens to an in-flight index if you stop it mid-run. For agent integration, the README gives three concrete configurations: an mcpServers block in OpenClaw's config.yaml with command docsagent and args ["server"], a claude code mcp add docsagent -- docsagent server invocation, and a manual command-type entry in Cursor or Windsurf settings.

The Zotero and Obsidian wrappers, and the path assumption baked into them

Two companion MCP servers are documented: papersgpt-for-zotero and docsagent-for-obsidian, both described as built on DocsAgent and both launched through npx -y with an mcp argument. The configuration is a standard mcpServers block. The interesting part is the caveat attached to each. Both default to a fixed data location (the README gives ~/Zotero for Zotero and ~/Documents/Obsidian Vault for Obsidian) and instruct you to append your real storage path behind the mcp argument if yours differs. That is a positional argument with no flag name, which makes the configuration harder to read and easier to misplace than a named option would be. Anyone whose vault lives on an external drive, or whose Zotero data directory was moved to save space on the system disk, has to edit the args array by hand. The README shows the pattern but does not show a filled-in example, so the exact expected form (trailing slash, quoting, Windows backslashes) is left to the reader.

Format coverage is three types wide, and the README's own table is the boundary

The support matrix lists PDF, Word (.docx) and PPTX, each marked full, with feature notes about layout analysis, table extraction and speaker notes respectively. Nothing else appears. Spreadsheets, plain text, Markdown, email archives, EPUB and image-based scans are absent from the table, and the repository topics mention docx, pdf and pptx without suggesting broader coverage. For an Obsidian user this is a real mismatch, since a vault is mostly Markdown files; the docsagent-for-obsidian server is documented as connecting to the vault, but the format matrix does not include Markdown, and the supplied material does not resolve that tension. The other boundary is scanned PDFs. Layout analysis is claimed for PDF, but optical character recognition is never mentioned, so a PDF that is a picture of a page is a plausible failure case. A prospective user with a scanned contract archive should treat text extraction as unverified until they test one file.

The native engine claim and what the repository does not document

The README describes a native C++ engine and millisecond-level retrieval across large libraries, and separately describes the project as TypeScript, which matches the primary language field. Both can be true at once if the C++ component is shipped as a prebuilt binary or native addon, but the material does not explain how the native piece is distributed, whether prebuilds exist for all three advertised platforms (macOS, Windows, Linux), or what happens on a platform without a matching binary. That is the first thing to check before installing on an unusual architecture. The second gap is the index itself. Nothing in the README states the storage location, the embedding model, whether embeddings are computed locally or downloaded, or the chunking strategy. The privacy claim rests on all of that, and an adopter who needs to satisfy a data-handling policy cannot complete that assessment from the README alone. A third gap is lifecycle: there are no releases retrieved for this repository, so there is no changelog to read for migration notes, and the index format's stability across versions is unknown. Rebuilding an index is cheap for a few hundred files and unpleasant for a large archive, so version pinning is the prudent default until a release history exists.

How this differs from a general-purpose vector store or a hosted document chat

The obvious alternative is a general-purpose stack: a local vector database such as Qdrant or Chroma plus your own parser and an embedding model, wired into the agent by hand. The difference is scope of work, not capability. That route gives you control over chunk size, metadata filters, incremental reindexing and deletion, and it handles formats DocsAgent does not. It also means you write the ingestion pipeline and maintain it. DocsAgent trades that control for three commands and a working MCP endpoint. The other alternative is a hosted document assistant, where you upload files and chat with them in a browser. That approach usually has better parsing for awkward formats and no local storage to manage, and it is the wrong choice whenever the documents cannot leave the machine, which is the case DocsAgent is built for. Between these, DocsAgent sits in a specific niche: small enough to configure in an afternoon, narrow enough that a corpus outside PDF, DOCX and PPTX will exhaust it quickly.

Licence, maintenance and what to verify before you commit an archive

The README carries an Apache-2.0 badge and states that DocsAgent is open-source under the Apache-2.0 License, and the badge links to a LICENSE file in the repository. The package metadata supplied here lists the licence as unknown, so the file itself is the thing to open before you rely on the terms; nothing in this material describes patent grants, attribution requirements or how the two companion MCP servers are licensed, and those are separate packages published under their own terms. On maintenance, the repository is not archived and the last push date is recent, but no releases were retrieved, so there is no versioned artifact history to reason about. That combination (active commits, no releases) usually means installs track the default branch through npm rather than a tagged version, which makes pinning harder. The concrete verification steps are therefore: run npm install -g @docsagent/docsagent, index a small folder with docsagent add, confirm with docsagent status where the index is written, run docsagent stop, and check whether the index directory still exists and what it contains. If that inspection matches your data-handling requirements, the tool does what its README says it does. If it does not, no amount of agent integration will fix it.

Editorial conclusion

Adopt DocsAgent if you want an agent to search a folder of PDFs, DOCX and PPTX files without uploading them, and you are comfortable running a global npm package plus a background engine process. Do not adopt it if your corpus is scanned image PDFs, spreadsheets, or anything you need to query with structured filters, since the support matrix lists only three formats and the CLI exposes only add, search, status and stop. Before trusting it with sensitive material, verify two things yourself: where the index and any embeddings are written on disk, and whether docsagent stop leaves that data in place. The Apache-2.0 badge in the README is the only licence statement available in the repository material, and the package metadata does not confirm it.

Official sources

1. docsagent/docsagent on GitHub
2. Issues
3. README