Knowledgebase MCP: agent-ready retrieval on your hosted server.
Upload docs, get an MCP server. Every hosted Tandem deployment ships with a private retrieval-only Knowledgebase MCP that turns uploaded files into searchable, fetchable collections so agents can ground their answers in your real content.
The KB MCP is a read-oriented knowledge service. It exposes a stable agent-facing interface for discovery, collection-level guidance, search across one or more collections, and fetch of a specific document by canonical identifier. It is intentionally retrieval-only — the calling agent owns the answer.
Upload, search, fetch — grounded.
The flow is intentionally search-then-fetch. Agents discover candidate documents through a fast index, then pull the exact document they need by canonical id. Strict-grounded channels quote retrieved evidence verbatim and refuse to invent answers.
Upload through Files
Operators drag-drop docs or pick a folder in the hosted control panel's Files page. The panel proxies uploads to the KB admin API on the same VM.
Indexing
Documents are normalized, frontmatter is merged instead of overwritten, and a stable relative source path is kept. Nested trees, not just flat roots.
Search
Natural-language queries are normalized before FTS execution. Punctuation-heavy prompts are sanitized. A substring fallback covers cases the FTS path can't parse.
Ranking
Title and heading hits rank above body-only hits. Guide-like docs get a modest boost on broad questions. kb_priority breaks near-ties; lower BM25 wins.
Fetch
Agents fetch the full document by canonical doc_id — not a truncated snippet — so grounded answers can quote real source verbatim.
Self-describing
get_kb_guide() and get_collection_guide() teach an agent how to use the namespace. New agents can bootstrap from arbitrary uploaded docs.
Use it when answers must be supported
Channel replies and agent answers can be forced to quote KB evidence or fall back to “I do not see that in the connected knowledgebase.”
Use it when knowledge is private
Per-server isolation keeps your collections, indexes, and admin token on your VM. There is no shared knowledge tier across customers.
Tools the KB MCP exposes
Read tools are open to any connected MCP client on the server. Write and admin endpoints require the per-server KB admin API key. The hosted control panel reads that key from a managed secret so operators never see it.
get_kb_guide
Bootstraps an agent that has never seen this server: returns the global KB guide, the compiled-wiki model, and a summary of every collection.
get_collection_guide
Returns the generated guide for a single collection — its role, canonical docs, and search hints — so agents know what is in the namespace before they search.
list_collections
Lists available collections and their compiled-wiki metadata so callers can pick a scope.
list_documents
Lists documents in a collection with optional paging and text filtering.
search_docs
Primary discovery primitive. Searches one collection, or every collection at once when collection_id is omitted.
get_document
Fetches a document by exact doc_id. Returns full content, not a truncated snippet, so grounded answers can quote real source.
create_document / append_section / update / delete
Admin-token-gated write tools for wiki-style collections. Used by the Files surface in the control panel and by trusted authoring agents.
Collection shapes
A collection is a named bucket of documents. Collections are not raw filesystem paths — they are the unit of retrieval scope. Three shapes show up in real deployments:
Wiki collections
Long-lived team docs: policies, runbooks, contact sheets, product specs. Indexed for retrieval and searchable across all of them at once.
Output collections
Authoring surface for agents: trip reports, post-incident notes, generated summaries. Writable through the create_document and append_section tools when the agent is trusted.
Strict-grounded collections
Used by channel adapters that enforce KB-only answers. Replies that the KB cannot support fall back to 'I do not see that in the connected knowledgebase.'
Design choices
Retrieval-only by design
The KB MCP is intentionally not a second answer generator and not a task runner. It exposes search and fetch — the calling agent owns the answer.
Per-server, not multi-tenant
Every hosted Tandem server runs its own KB MCP. Your collections live on your VM. There is no shared knowledge tier between customers.
Self-describing for agents
The server's own get_kb_guide and get_collection_guide tools teach an agent how to use the namespace. New agents can bootstrap from arbitrary uploaded docs without prior configuration.
Admin token at the seam
Read tools are open to any connected MCP client. Write and admin endpoints require the KB admin API key, which the hosted control panel reads from a per-server secret.
On a hosted Tandem server
Files surface
The control panel's Files page is the upload UI. Drag-drop docs, pick a folder, organize collections — no separate KB admin tool to learn.
Auto-registered MCP
The Tandem engine on the same VM auto-registers the KB as a connected MCP server with grounding metadata. Agents see it immediately.
Per-server isolation
Your KB index, secret, and uploads live on your provisioned VM. No shared knowledge tier across customers.
- 1. get_kb_guide()When the agent does not yet know the server.
- 2. get_collection_guide(collection_id)Inspect collection-level guidance before searching.
- 3. search_docs(query)Identify candidate documents.
- 4. get_document(doc_id)Fetch the exact document by canonical id.