What can you do with this server?

This server lets a model query the DPC Zettelkasten knowledge base with structural tools and commit-pinned citations for every claim. * search_notes — full-text search across concept notes and Maps of Content. * get_note — fetch a full note with its Markdown body, links, backlinks, and citations. * list_maps — see the collection's hierarchy and what each Map of Content covers. * get_citations — inspect the commit-pinned sources behind claims, filterable by note, repository, or path. * graphql — run read-only structural queries for relationships, connectivity, repositories, and statistics. * get_schema — retrieve the GraphQL schema as SDL to write correct queries. * Resources — each note is exposed as a dpc-zettelkasten://note/ resource for direct attachment. * Transports — works over stdio or Streamable HTTP, with no runtime dependencies and a vendored, commit-pinned data snapshot.

How do I use DPC MCP Server?

1. Click on "Install Server". 2. Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state. 3. In the chat, type @ followed by the MCP server name and your instructions, e.g., "@DPC MCP Server Search for how faction power works" That's it! The server will respond to your query, and you can continue using it as needed. Here is a step-by-step guide with screenshots.

DPC MCP Server

Official

by Dans-Plugins

Overview Schema Related Servers Score Discussions

JavaScript

Local

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"]
    }
  }
}

Over HTTP

The same server also speaks MCP's Streamable HTTP transport, for the cases where a subprocess is not an option — a container, or a client on another machine:

node src/server.js --http --port 8080     # POST /mcp, health at /healthz

It binds 127.0.0.1 unless --host says otherwise, and it has no authentication of its own, so it is a local and private-network transport until it grows one. stdio remains the default and the right choice for a local client.

claude mcp add --transport http dpc http://127.0.0.1:8080/mcp

In a container

The Dockerfile builds the HTTP transport into an image. There is no npm install in it and no node_modules in the result — copying package.json, src/, and vendor/ is the whole build, which is what having no runtime dependencies buys. It runs as the base image's node user, binds 0.0.0.0 inside the container because nothing outside the network namespace could otherwise reach it, and carries a HEALTHCHECK that probes /healthz with node rather than assuming a slim image ships curl.

docker build -t dpc-mcp-server .
docker run -d -p 8080:8080 --name dpc dpc-mcp-server
curl -s http://127.0.0.1:8080/healthz
docker stop dpc

docker stop returns as soon as the server exits, because the server handles SIGTERM: it stops accepting, finishes what is in flight, and leaves — rather than ignoring the signal and being killed ten seconds later.

The image binds a public interface inside the container and still has no authentication of its own, so publish it behind something that does — the gateway, or anything else that terminates auth in front of it.

A container does not refresh itself. The image bakes in vendor/dataset.json, so it serves whatever commit of the collection was vendored when the image was built — deliberately, since that is how the server already works and it keeps the container from depending on the network at boot. Updating the served collection is npm run sync, a commit, and a redeploy. The pinned commit comes back from /healthz and from list_maps, so a stale deployment is visible rather than silent.

Related MCP server: harness-health-engineering

Tools

Tool	For
`search_notes`	Full-text search. Start here when you have a topic, not an id.
`get_note`	One note in full — Markdown, links, backlinks, and every citation.
`list_maps`	The hierarchy: each Map of Content and the concepts under it.
`get_citations`	Sources of truth, filterable by note, repository, or path.
`graphql`	Structural questions the other tools cannot answer.
`get_schema`	The GraphQL schema as SDL.

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:

Variable	Effect
`DPC_ZK_PATH`	Path to a `dpc-zettelkasten` checkout; uses its `site/dataset.json` and `lib/zk-graphql.js`
`DPC_ZK_DATASET`	Path to a specific `dataset.json`
`DPC_ZK_ENGINE`	Path to a specific `zk-graphql.js`

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 transports — JSON-RPC 2.0 over newline-delimited stdio, and Streamable HTTP over node:http — directly, rather than through the SDK. 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: 86 assertions across the vendored data, the raw wire protocol, and live sessions on both transports with @modelcontextprotocol/sdk.

npm install   # dev dependencies, for the tests
npm test

Support

Contributing

See CONTRIBUTING.md.

License

MIT.

Available Tools

6 tools

get_citationsA

Every source of truth behind a note, or across the whole collection — repository, file path, line range, the specific claim it supports, and a permalink pinned at a commit SHA. Use this to check whether a claim is actually supported, or to find which notes cite a given repository.

ParametersJSON Schema

Name	Required	Description
`id`	No	Note id. Omit to search across all notes.
`path`	No	Filter by a substring of the cited file path.
`repo`	No	Filter by repository, e.g. "Medieval-Factions".

TDQS

A3.8/5.0

Behavior3/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations, the description carries the full burden of behavioral disclosure. It discloses the return fields and scope (per note or whole collection) but does not mention potential error cases, pagination, or whether results are exhaustive. It's adequate but not rich in behavioral detail.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is two sentences long, front-loads the tool's core purpose in the first sentence, and the second sentence gives usage context. No wasted words; every part earns its place.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

The description explains what the tool returns and when to use it, which is complete for a read-only retrieval tool with three optional filters. It lacks an explicit output schema but describes the return fields (repo, path, line range, claim, permalink). Missing minor details like empty-result behavior, but overall context is complete.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The input schema has 100% parameter description coverage, so the baseline is 3. The description does not add meaning to the parameters beyond the schema; it mentions repo and path as return fields, not parameter semantics. The schema already documents id, path, and repo filters adequately.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states what the tool returns: citation sources (repository, file path, line range, claim, permalink) for a note or the whole collection. It distinguishes itself from siblings like search_notes and get_note by focusing on citations and source verification. However, it lacks an explicit verb like 'list' or 'get', relying on the noun phrase 'Every source of truth' to convey the action.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description explicitly says 'Use this to check whether a claim is actually supported, or to find which notes cite a given repository,' giving clear scenarios for use. It does not mention alternatives or when not to use it, but the provided use cases are sufficient guidance for an AI agent.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

get_noteA

Fetch one note in full: its Markdown body, its links and backlinks, and every citation with a commit-pinned GitHub permalink. Use this once search_notes or list_maps has given you an id. Every claim in this collection is grounded in a file in a Dans-Plugins repository, pinned at a commit SHA. When you use a note, cite its sources rather than presenting the claim as your own knowledge — the permalinks are what make the answer checkable.

ParametersJSON Schema

Name	Required	Description	Default
`id`	Yes	Note id, e.g. "faction-power" or "moc-plugin-architecture".

TDQS

A4.7/5.0

Behavior5/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations exist, so the description carries full burden. It discloses that notes are grounded in a specific repository pinned at commit SHAs, that citations are commit-pinned permalinks, and instructs the agent to cite sources rather than present claims as its own. This is rich behavioral context well beyond a simple fetch.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The first sentence front-loads the purpose with a clear verb and resource. The second gives usage context, and the third adds important citation-grounding context. All sentences earn their place with no redundancy.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Without an output schema, the description clearly states what will be returned (Markdown body, links/backlinks, citations with permalinks) and when to use it. For a one-parameter lookup tool, this is comprehensive and self-sufficient.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100% with a clear description of the single id parameter and examples. The tool description does not add further parameter semantics beyond the schema, so the baseline 3 applies.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description uses a specific verb 'Fetch' plus resource 'one note' and enumerates its contents (Markdown body, links/backlinks, citations with permalinks). It clearly distinguishes from siblings by stating it should be used after search_notes or list_maps provides an id.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines5/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Explicitly instructs when to use the tool: 'once search_notes or list_maps has given you an id', providing a clear workflow order relative to siblings. It implies that search/list tools are for discovery and this tool is for retrieval, and adds a behavioral expectation about citing sources.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

get_schemaA

The GraphQL schema for the collection, as SDL. Call this before writing a non-trivial query with the graphql tool.

ParametersJSON Schema

Name	Required	Description	Default
No parameters

TDQS

A4.5/5.0

Behavior4/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Without annotations, the description needs to carry behavioral context. It discloses the output format (SDL), the scope (the collection), and positions it as a prerequisite for non-trivial GraphQL queries. It doesn't discuss auth or rate limits, but for a zero-parameter read-only schema fetch, this is sufficient.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Two short sentences, with the primary statement first and a usage hint second. Every word earns its place, making it appropriately sized and front-loaded.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

The tool is simple (no params, no output schema), and the description gives the purpose, output format, and usage context. It fully answers what an agent needs to know to use the tool correctly.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The schema defines zero parameters, so there is nothing to document. Baseline for 0 params is 4; the description adds no conflicting info and correctly focuses on the returned schema.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool returns 'The GraphQL schema for the collection, as SDL.' This identifies the resource (GraphQL schema) and format (SDL), and distinguishes it from sibling tools like graphql which executes queries, and search_notes/get_note which handle notes.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

It provides an explicit usage context: 'Call this before writing a non-trivial query with the graphql tool.' This tells the agent when to use it, though it does not mention exclusions or alternatives, hence not a 5.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

graphqlA

Run a GraphQL query against the collection's structure. Use this for questions the other tools cannot answer — which notes are most connected, what a cluster contains, which repositories ground the most claims, how two notes relate.

Read-only: no mutations, fragments, or variables. Inline argument values.

Examples: { notes(orderBy: degree, first: 5) { title degree moc { title } } } { notes(moc: "moc-faction-domain-model") { title summary } } { note(id: "demesne-limit") { title links { title } sources { claim url } } } { repositories { name citationCount noteCount } }

SCHEMA:

The zettelkasten as a graph. Read-only — queries only.

enum NoteType { concept moc } enum NoteOrder { title degree citations }

type Query { notes(type: NoteType, moc: ID, tag: String, repo: String, search: String, linkedTo: ID, orderBy: NoteOrder, first: Int): [Note!]! note(id: ID!): Note mocs: [Note!]! concepts(first: Int): [Note!]! tags: [Tag!]! repositories: [Repository!]! stats: Stats }

type Note { id: ID title: String type: NoteType summary: String tags: [String!]! updated: String path: String url: String moc: Note links(first: Int): [Note!]! backlinks(first: Int): [Note!]! neighbors(first: Int): [Note!]! linkCount: Int backlinkCount: Int degree: Int sources: [Source!]! sourceCount: Int repositories: [String!]! }

type Source { repo: String path: String ref: String shortRef: String lines: String claim: String url: String }

type Tag { name: String count: Int notes: [Note!]! }

type Repository { name: String url: String citationCount: Int noteCount: Int pinnedRefs: [String!]! notes: [Note!]! }

type Stats { noteCount: Int mocCount: Int conceptCount: Int citationCount: Int linkCount: Int repositoryCount: Int repositories: [String!]! updated: String }

ParametersJSON Schema

Name	Required	Description	Default
`query`	Yes	The GraphQL query document.

TDQS

A4.9/5.0

Behavior5/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations provided, the description carries full responsibility for behavioral disclosure. It clearly states 'Read-only' and 'no mutations, fragments, or variables,' plus it embeds the entire GraphQL schema, which reveals the full range of queries and return types. This is comprehensive transparency that outperforms typical tool descriptions.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is long due to the embedded schema, but the opening sentence is front-loaded and clear, and the structure (intro, constraints, examples, schema) is logical. Every section earns its place; it could be slightly more concise, but the length is justified by the complexity of a GraphQL API.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a tool with a single string parameter and no output schema, this description is exceptionally complete. It covers purpose, usage, constraints, and the complete query API. An agent can confidently construct valid queries and anticipate the shape of results based on the schema. There are no critical gaps.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters5/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The input schema only defines 'query' as a string. The description compensates richly by providing the complete GraphQL API schema and multiple examples of valid query strings. This gives the agent a deep understanding of how to formulate the query parameter, far exceeding the minimal schema description.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description opens with a clear verb+resource: 'Run a GraphQL query against the collection's structure.' It also distinguishes itself from sibling tools by explicitly stating 'Use this for questions the other tools cannot answer' and listing specific examples such as 'which notes are most connected' and 'which repositories ground the most claims.' This makes the tool's purpose unambiguous and well-differentiated.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines5/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description gives explicit guidance on when to use this tool versus alternatives: 'Use this for questions the other tools cannot answer.' It also provides constraints on usage: 'Read-only: no mutations, fragments, or variables. Inline argument values.' This tells the agent both the appropriate scenarios and the operational boundaries, going beyond simple context.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

list_mapsA

The structure of the collection: every Map of Content and the concept notes that call it home. Use this to orient before searching, or to answer 'what does this collection cover?'. Each concept note belongs to exactly one map.

ParametersJSON Schema

Name	Required	Description	Default
No parameters

TDQS

A3.8/5.0

Behavior3/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations, the description must convey behavioral traits. It discloses an important structural rule ('Each concept note belongs to exactly one map') and implies read-only behavior via the name and purpose. However, it does not describe return format, ordering, or other potential behavior, leaving some gaps for a tool with no annotation support.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Three sentences, each contributing distinct value: what the tool shows, when to use it, and a constraint on the data. The first sentence is slightly awkward grammatically but not wasteful. Overall, concise and well-structured.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a parameterless listing tool, the description is quite complete: it explains the output (maps and their concept notes), the intended usage scenario, and a key data rule. However, it lacks explicit mention of the return format (e.g., list vs. tree) and any pagination or limits, which keeps it from a perfect score.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The input schema is empty (0 parameters), so the baseline is 4. The description correctly focuses on the tool's purpose and output rather than parameters, which are nonexistent.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool's function: listing every Map of Content and the concept notes that call it home, effectively providing an overview of the collection's structure. It distinguishes from sibling tools like search_notes and get_note by focusing on the overall map-level structure rather than individual notes.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Explicitly states when to use: 'orient before searching' or to answer 'what does this collection cover?'. This gives clear context for when this listing tool is appropriate, though it does not explicitly name alternatives or exclusion criteria.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

search_notesA

Full-text search across the DPC Zettelkasten — a knowledge base describing how the Dan's Plugins Community Minecraft plugins work (Medieval Factions and the repositories around it). Start here when you have a topic rather than a note id. Returns matching notes with summaries; follow up with get_note for the full text and its citations. Every claim in this collection is grounded in a file in a Dans-Plugins repository, pinned at a commit SHA. When you use a note, cite its sources rather than presenting the claim as your own knowledge — the permalinks are what make the answer checkable.

ParametersJSON Schema

Name	Required	Description
`type`	No	Restrict to concept notes or Maps of Content.
`limit`	No	Maximum results (default 10).
`query`	Yes	Words to look for in titles, summaries, and bodies.

TDQS

A4.3/5.0

Behavior4/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations, the description carries the burden of behavioral disclosure. It states the return type ('matching notes with summaries') and adds critical context about the knowledge base's grounding in pinned repository files and the need to cite permalinks. However, it does not explain query semantics (e.g., case sensitivity, fuzzy matching) or error behavior, leaving some gaps.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is concise and front-loaded with the primary purpose. Each sentence serves a distinct role: purpose, usage, return behavior, data provenance, and citation requirement. It is slightly longer than necessary but all content earns its place, so a 4 is suitable.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the tool's moderate complexity and lack of output schema, the description covers the key contextual elements: what it searches, what it returns (summaries), how to proceed (get_note), and why results are reliable (SHA-pinned sources). It does not describe pagination/sorting, but the limit parameter schema covers the former. A 4 reflects solid coverage without being exhaustive.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100%, so the schema already fully describes all three parameters. The description adds minimal extra meaning for the query parameter ('topic rather than a note id') but does not enhance the type or limit parameters. The baseline of 3 is appropriate given the high schema coverage.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description opens with a specific verb and resource: 'Full-text search across the DPC Zettelkasten.' It clearly distinguishes the tool from siblings by stating 'Start here when you have a topic rather than a note id' and explicitly naming get_note as the follow-up tool, making the differentiation explicit.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines5/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description provides explicit when-to-use guidance ('Start here when you have a topic rather than a note id') and names an alternative (get_note) with follow-up direction. It also sets expectations for how to use the results (cite sources), which is actionable guidance for the agent.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Install Server

RayrunBuild, deploy, and operate MCP servers without becoming an infrastructure team.ray.runAd

TDQS

A4.2/5.0

Disambiguation5/5

Each tool serves a distinct purpose: searching, fetching by ID, listing maps, retrieving citations, running raw queries, and getting the schema. The overlap between graphql and the other tools is explicitly framed as a fallback for advanced questions, preventing confusion.

Naming Consistency4/5

Most tools follow the verb_noun pattern: search_notes, get_note, list_maps, get_citations, get_schema. The sole exception is 'graphql', which is a single noun rather than verb_noun, but it's an accepted name for a query tool and doesn't break the overall consistency.

Tool Count5/5

Six tools is well-scoped for a knowledge-base server. Each tool covers a distinct access pattern, and there are no redundant or missing utilities that would bloat or thin the interface.

Completeness4/5

The server covers the core workflows: searching, retrieving, browsing structure, verifying citations, and advanced graph queries. The graphql tool fills most gaps (e.g., listing all notes, aggregations), though a dedicated 'list all notes' tool would be a minor convenience.

Maintenance

ActivityMaintained

ResponsivenessSyncing

Resources

GitHub Repository

Need Help?

Related Servers

Unclaimed servers have limited discoverability.

Looking for Admin?

If you are the server author, to access and configure the admin panel.

Related MCP Connectors

RepoFold
dev.repofold
A cited wiki of your GitHub repo: search, read pages, find symbols and ask, with line citations.
Version Control Documentation Access Search
2
Forums
io.github.basehub-ai
Ask any GitHub repository a question. Get source-backed answers.
Search Version Control Developer Tools
336
KeepFlash Agent Access
io.github.dante-is-shipping
Search, read, cite, create, and safely update a user's private KeepFlash knowledge library.
Note Taking Knowledge & Memory Search
1
Hive Intelligence MCP A
xyz.hiveintelligence
Evidence-backed crypto due diligence with sources, freshness, and a runtime receipt on every call.
Blockchain Cryptocurrency Web3 & Decentralized Tech
8218

Related MCP Servers

knowledgebased
RAG Systems Knowledge & Memory
devkanro
A
license
A
quality
D
maintenance
Provides semantic search and a tag-based knowledge graph for any project, auto-discovering local markdown knowledge bases with YAML frontmatter.
Updated 4 months ago (2026-04-27 07:02 UTC)
10
14
MIT
harness-health-engineering
Health & Wellness RAG Systems Knowledge & Memory
cryptoyoginya
A
license
Not graded
quality
B
maintenance
Enables querying a local health knowledge base with hybrid RAG (vector + FTS5) and exploring backlinks between notes.
Updated 2 months ago (2026-07-03 20:58 UTC)
MIT
RAG Code Search Agent
RAG Systems Code Analysis Search
pratishank05
A
license
Not graded
quality
C
maintenance
Enables natural language search over indexed codebases with source citations and incremental indexing.
Updated 2 months ago (2026-07-07 18:59 UTC)
MIT
ResearchBrain MCP Server
Research & Data RAG Systems Documentation Access
cacity
A
license
Not graded
quality
A
maintenance
Enables MCP clients to interact with a local-first research knowledge workbench, supporting literature search, evidence-grounded Q&A, and reference export.
Updated 21 hours ago (2026-09-03 01:11 UTC)
2
AGPL 3.0

Latest Blog Posts

Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)
By Om-Shree-0709 on July 25, 2026.
mcp
Agent Identity
OAuth 2.1
Your AI Chatbot Just Exposed Your CEO's Salary to an Intern
By Om-Shree-0709 on July 2, 2026.
Agent Identity
MCP Security
OAuth Delegation
Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)
By Om-Shree-0709 on June 30, 2026.
Agentic Ai
Prompt Injection
WebAssembly

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/Dans-Plugins/dpc-mcp-server'

If you have feedback or need assistance with the MCP directory API, please join our Discord server

DPC MCP Server

Install

Claude Code

Claude Desktop, or any client using mcpServers

Over HTTP

In a container

Tools

The GraphQL tool

Where the data comes from

One schema, not two

No dependencies

Support

Contributing

License

Available Tools

The zettelkasten as a graph. Read-only — queries only.

Maintenance

Resources

Looking for Admin?

Related MCP Connectors

Related MCP Servers

Latest Blog Posts

MCP directory API

Claude Desktop, or any client using `mcpServers`