DPC MCP Server

An MCP server for the DPC Zettelkasten — the knowledge base describing how the Dan's Plugins Community Minecraft plugins work.

It gives a model two things it does not otherwise have: structural queries over the collection, and the citation behind every claim. Ask it how faction power works and the answer comes back with a GitHub permalink pinned to a commit SHA, so the claim can be checked rather than trusted.

Install

Requires Node 18 or later. No runtime dependencies.

git clone https://github.com/Dans-Plugins/dpc-mcp-server.git
cd dpc-mcp-server
npm run sync      # optional — a snapshot is already committed

There is nothing to build. node src/server.js is the whole thing.

Claude Code

claude mcp add dpc --  node /absolute/path/to/dpc-mcp-server/src/server.js

Claude Desktop, or any client using mcpServers

{
  "mcpServers": {
    "dpc": {
      "command": "node",
      "args": ["/absolute/path/to/dpc-mcp-server/src/server.js"]
    }
  }
}

Related MCP server: harness-health-engineering

Tools

Full reference: TOOLS.md.

The collection is also exposed as resources at dpc-zettelkasten://note/<id>, one per note, so a client can attach a note to a conversation without spending a tool call.

The GraphQL tool

{
  notes(orderBy: degree, first: 5) {
    title
    degree
    moc { title }
  }
}

The schema travels in the tool's own description, so a model can write a correct query without a round trip — and a failed query gets the schema back in the error, which is usually enough to fix it on the next attempt. Read-only by construction: mutations, fragments, and variables are refused with an explanation rather than a parse error.

Where the data comes from

The graph and the query engine are vendored — committed into vendor/ — so the server starts with no network and always serves a known snapshot. The cost is that it goes stale, which is what npm run sync is for.

npm run sync                                  # latest commit on the collection's main
npm run sync -- --ref <sha>                   # a specific commit
npm run sync -- --from ../dpc-zettelkasten    # a local checkout
npm run sync -- --check                       # is the snapshot behind main?

Syncing resolves the branch to a commit SHA and fetches at that SHA, recording it in vendor/SOURCE.json. The server then reports which commit it is serving, both in its startup line and in list_maps, so a stale snapshot is visible rather than silent.

That pinning is not decoration. raw.githubusercontent.com caches branch paths, and an early version of this script fetched main and vendored a copy that was a commit behind — while --check cheerfully reported it current. Paths under a commit SHA are immutable and cache correctly. It is the same rule the collection applies to its own citations, for the same reason: a branch is not a version.

A sync that produces a broken snapshot is refused rather than written. The script loads the fetched engine against the fetched data, runs a query, and checks they agree before touching vendor/.

Override the source at runtime if you would rather point at a checkout:

See CONFIG.md.

One schema, not two

vendor/zk-graphql.js is not a reimplementation. It is the same file the zettelkasten's offline explorer inlines into its own page — the schema and engine live in lib/zk-graphql.js over there, and both consumers load it.

That is deliberate. A schema maintained in two places drifts, and a model given a stale schema writes queries that fail for reasons it cannot see.

No dependencies

The server implements MCP's stdio transport — JSON-RPC 2.0, one message per line — directly, in about 180 lines. The official SDK is a dev dependency, used by the test suite to drive this server as a real client would.

That is the claim worth testing, so the tests make it: 55 assertions across the vendored data, the raw wire protocol, and a live session with @modelcontextprotocol/sdk.

npm install   # dev dependencies, for the tests
npm test

Support

• Discord

• Bug reports

Contributing

See CONTRIBUTING.md.

License

MIT.