Home

mcp-kb

An MCP knowledge base. Skills, prompts and agent material collected from git, WebDAV and folders into one catalogue, served as MCP resources — or as tools, for the clients that have no resources.

The README is the tour. This is the manual.

Where to go

You want to	Read
Run it on your own machine — Docker or Python	Quick start
Run it for real — Docker, Kubernetes, stdio	Deployment
Connect a client — Claude Code, n8n, VS Code, curl	Installing
Write a config file	The config file
Check on a running server, or fix one	Operations

The sidebar has the rest, grouped the same way: getting started, the config file, what clients get, and reference.

The shape of it

 git repo  ─┐
 WebDAV    ─┼─▶  harvest  ─▶  ┌────────┐
 a folder  ─┘   into the      │ mcp-kb ├─┬─▶  MCP resources    ─▶  agent (the interface)
                cache         └────────┘ │
                                         ├─▶  four tools       ─▶  agent with no resources
                                         │                         (the mirror)
                                         └─▶  /health /reindex ─▶  you, with curl

Everything named becomes a directory on this machine before anything reads it: a file:// path is served where it is, a git repository is cloned bare and exported at a commit, a WebDAV folder is copied in. That is the whole reason the address space, the scoping and the traversal guard do not care which backend a skill came from — they only ever see a path.

How it works

One address space. Everything the server serves is a skill:// URI, and reading one is the only operation there is: a library, a folder or a skill's own root is a directory and serves nothing, _index.md/_files.md are the indexes, and SKILL.md is a skill's instructions. Skills has the grammar in full. Progressive disclosure lives in those addresses rather than in a tool list, so a listing is a dozen index rows whether the catalogue holds nine skills or ninety.

Resources are the interface; tools are a mirror. MCP already has a primitive for material an agent reads, and it is the resource. A client that speaks resources sees no tools at all. A client that does not — n8n's MCP Client Tool is the one that matters — says so on its URL and gets the same interface as four tools with the same vocabulary. See Tools.

A source is a dependency. It is declared in a config file the way a package manifest declares one: a URL and a credential that is a reference to an environment variable rather than a value. Nothing is baked into the image; what the config names is read at container start into a cache volume. See Sources.

A plugin is a folder of skills and prompts, and a library is a query over plugins. A plugin sits at a path under a source, pinned to a revision, and carries the metadata a catalogue entry carries. A library is the first segment of every URI served, and it is a marketplace published somewhere, a list of plugins, or a query over their categories and tags. See Plugins and Libraries.

A client can be given part of the catalogue and no more. ?library=, ?categories= and ?tags= on the MCP URL, or the matching headers, are a ceiling the model cannot widen past — enforced on resources, prompts and every mirror tool alike. See Scoping.

Ten seconds in

docker run --name mcp-kb -d -p 127.0.0.1:8000:8000 --mount type=volume,source=mcp-kb-cache,target=/var/cache/mcp-kb kubed/mcp-kb:latest

That serves the built-in example config: four GitHub libraries, pinned to commits. Then:

curl -s localhost:8000/health

and point an MCP client at http://localhost:8000/mcp. Your own config, Windows, or no Docker at all: Quick start.