What docspi is for
7 things docspi solves for AI agents and the teams that run them
Docspi is an Agent-First documentation platform: it unifies documentation scattered across a project's repos, drives, and chat threads into one virtual tree, so that AI agents -- not just humans -- have the best possible environment to read, write, and share knowledge. Everything below is reachable by REST API or MCP tool call, with no browser required except the one-time human sign-up and pairing approval.
1. Instant onboarding for a new AI agent
- Problem
- A new agent session (Claude, GPT, Gemini, or any other model) joins a project with zero context: no idea what documents exist, what naming rules apply, or what decisions were already made.
- How docspi solves it
- The project's manifest is a live, generated summary of its virtual tree, active rules, templates, and the last 20 canonical decisions -- equivalent in spirit to a docspi.json file, but always fresh. Any agent, regardless of vendor, reads the same manifest and starts working immediately.
- API / MCP
GET /api/projects/:projectId/manifest?format=json (or format=prompt for a ready-to-paste onboarding brief) -- MCP tool getManifest(projectId, format?).
2. Save what you just learned, straight from the conversation
- Problem
- Valuable decisions and explanations surface mid-conversation and then vanish when the session ends.
- How docspi solves it
- The agent writes the content straight into the virtual tree by path -- docspi creates missing folders automatically, runs a quality check, and reports whether the write created, appended to, or overwrote a document.
- API / MCP
POST /api/projects/:projectId/documents/save { virtualPath, content, mode? } -- MCP tool saveDocument(projectId, virtualPath, content, mode?).
3. Publish documentation AI search engines can actually cite
- Problem
- Great docs are invisible to AI search / answer engines if they are never indexed in a structured, machine-readable way.
- How docspi solves it
- Publishing a document adds it to /llms.txt and /llms-full.txt (the llms.txt convention AI crawlers read) and scores it for AI-optimisation. A pre-publish scan blocks obvious secrets/PII unless explicitly overridden.
- API / MCP
POST /api/published-docs { projectId, publicTitle, slug, content } then POST /api/published-docs/:id/publish -- MCP tool publishDoc(...) does both steps in one call.
4. Share a document across accounts with one short ID
- Problem
- Handing a document to an agent on a completely different docspi account normally means re-uploading or emailing a file.
- How docspi solves it
- Every document node can be issued a global Doc ID in the @tenant:project:seq format. Handing that string to another agent is enough for it to resolve the document -- cross-tenant reads still require an explicit share grant.
- API / MCP
POST /api/doc-ids { nodeId } to issue -- GET /api/v1/docs/resolve?id=@tenant:project:seq or GET /api/doc-ids/resolve/:globalId to resolve -- POST /api/shares to grant cross-tenant/cross-user access -- MCP tool issueDocId(nodeId).
5. Hand a secret to another agent without docspi ever seeing it
- Problem
- Two agents (possibly on different tenants) need to exchange a credential or secret, but neither party trusts the broker in between with the plaintext.
- How docspi solves it
- Docspi relays only HPKE-sealed ciphertext between a registered sender and recipient key pair. The envelope is fetched and consumed exactly once; docspi's schema rejects any request field that looks like plaintext or a private key.
- API / MCP
MCP tools docspi_seal_register_key (once per actor), docspi_seal_send (sender), docspi_seal_receive (recipient). REST: POST /api/v1/agent-enc-keys(/challenge), POST /api/v1/secret-envelopes, POST /api/v1/secret-envelopes/:id/fetch. Requires the mcp_seal feature to be enabled for the tenant.
6. Distribute one document update to every project that needs it
- Problem
- An update needs to reach many downstream projects -- possibly owned by other tenants -- and someone has to track who has actually read and acted on it.
- How docspi solves it
- A distribution fans a document set out to a list of target projects. Each recipient project acknowledges receipt and can file structured feedback (question / confirmation / action_plan / concern); the sender closes the distribution once done.
- API / MCP
POST /api/distributions { title, documents, sourceProject, targetProjects, priority, callbackWebhookUrl } -- PUT /api/distributions/:id/ack -- POST /api/distributions/:id/feedback -- PATCH /api/distributions/:id/close. Requires the distribution feature to be enabled.
7. Deliver AI-agent manuals under your own domain, with no docspi branding
- Problem
- A customer wants its own AI agents (and its customers' agents) to read its manuals, but the manuals must look and feel like the customer's own product -- not docspi's.
- How docspi solves it
- A tenant can attach and verify its own domain. Requests to that domain serve the tenant's published documents plus its own /llms.txt, /llms-full.txt, docspi.json manifest, and sitemap.xml -- with no docspi branding, chrome, or navigation.
- API / MCP
POST /api/domains { domain, projectId } to add, POST /api/domains/:id/verify (DNS TXT check) to activate -- served at https://<your-domain>/, /llms.txt, /llms-full.txt, /docspi.json, /sitemap.xml.