DPC MCP Server
OfficialServer Configuration
Describes the environment variables required to run the server.
| Name | Required | Description | Default |
|---|---|---|---|
| DPC_ZK_PATH | No | Path to a dpc-zettelkasten checkout; uses its site/dataset.json and lib/zk-graphql.js | |
| DPC_ZK_ENGINE | No | Path to a specific zk-graphql.js | |
| DPC_ZK_DATASET | No | Path to a specific dataset.json |
Capabilities
Features and capabilities supported by this server
| Capability | Details |
|---|---|
| tools | {} |
| resources | {} |
Tools
Functions exposed to the LLM to take actions
| Name | Description |
|---|---|
| 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. |
| 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. |
| 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. |
| 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. |
| 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 } |
| get_schemaA | The GraphQL schema for the collection, as SDL. Call this before writing a non-trivial query with the graphql tool. |
Prompts
Interactive templates invoked by user choice
| Name | Description |
|---|---|
No prompts | |
Resources
Contextual data attached and managed by the client
| Name | Description |
|---|---|
| Approval Request | The consent step for the three diplomatic changes that bind two factions — war, alliance, and vassalisation. |
| Claimed Chunk | Territory is recorded one 16×16 Minecraft chunk at a time, as a row pointing from world coordinates to a faction. |
| Currencies | An expansion letting factions mint physical local currencies as item stacks, and the reference example of a modern Medieval Factions expansion. |
| Dan's Plugin Manager | A plugin that installs other DPC plugins from in-game or the console, pulling releases straight from GitHub. |
| dansplugins.com | The community's Next.js website — plugin directory, guides, and player accounts — backed by a separate dpc-api service. |
| Demesne Limit | The rule binding land to power — a faction may hold at most one chunk per point of faction power. |
| DPC API Faction Sync | A running server can push its faction roster to the community API on a timer — the one code path where a Minecraft server writes to shared public data. |
| DPC Conventions | The repository that writes the organization's standards down, using Medieval Factions as the worked example throughout. |
| DPC Minecraft Server | An infrastructure-as-code Spigot server that pins a curated set of DPC plugin jars into a Docker image, each toggleable by environment variable. |
| Expansion Plugin | A plugin that hard-depends on Medieval Factions and extends the simulation — declaring the dependency in plugin.yml and reusing the flagship's identifiers, events, and permission model. |
| Faction | The central record of the simulation — a named group of players with land, roles, diplomacy, and a power score. |
| Faction Events | The plugin fires cancellable Bukkit events for every meaningful faction change, and derives which to fire by diffing the record it is about to save. |
| Faction Flag | Per-faction toggles that change how the simulation treats a faction — land access for allies, friendly fire, mob protection, and map colour. |
| Faction Permission | The individually grantable capabilities inside a faction, each with a default and a type. |
| Faction Power | A faction's live strength — the sum of its members' power plus a conditional vassal contribution — and the cap on how much land it may hold. |
| Faction Relationship | Diplomacy is stored as directed edges between factions, typed as ally, at war, vassal, or liege. |
| Faction Role | A named bundle of permission overrides that a faction assigns to its members. |
| Fiefs | An expansion adding sub-factions inside a faction — and the clearest surviving example of the pre-version-5 integration style. |
| Gate | A faction-owned wall of blocks that opens and closes when a redstone trigger block is powered. |
| jOOQ Persistence | Storage is jOOQ over a Hikari pool, with Flyway migrations and a configurable SQL dialect — H2 by default, MySQL or PostgreSQL optionally. |
| Law | Numbered lines of text a faction publishes to its members — enforced socially, not mechanically. |
| Legacy Data Migration | Version 4's flat JSON files are backed up and read once into the database, behind a deliberate server shutdown that forces the operator to configure storage first. |
| Locked Block | Per-player protection on a single block, with an explicit accessor list — independent of faction land ownership. |
| Mailboxes | A standalone plugin giving players persistent in-game mail with item attachments, and the delivery backend Medieval Factions prefers for offline notifications. |
| Main Thread Safety | Bukkit state may only be read on the server's main thread, so anything doing I/O snapshots first and sends afterwards. |
| Map Integration | Claimed territory is drawn on web maps through a one-method interface with a Dynmap implementation, wired only when the optional plugin is present. |
| Medieval Factions | The flagship plugin — a Kotlin Spigot plugin simulating sovereign nations, and the reference implementation every DPC convention points at. |
| Conventions and Process | The standards every DPC repository is held to — documentation layout, testing, CI, and release automation. |
| Dan's Plugins Community | The root map — an index of the six Maps of Content, and through them every concept note in the collection. |
| Faction Domain Model | Guided path through the nouns of the simulation — factions, power, land, and the relationships between them. |
| Medieval Factions Map | Mid-level map of the flagship — routes to the domain model and the architecture, and names the seams other software attaches to. |
| Plugin Architecture | How the flagship is layered — services over repositories over jOOQ — and the cross-cutting concerns that shape every feature. |
| Plugin Ecosystem | The plugins around the flagship — the shared library, the official expansions, and the plugins Medieval Factions talks to at runtime. |
| Web and Infrastructure | The community website, the containerised Minecraft server, and the data path that connects a live game server to the public site. |
| Notification | A one-method interface for reaching an offline player, with implementations chosen at startup based on which plugins are installed. |
| Optimistic Locking | Every mutable record carries a version column; a write that does not match the version it read is rejected rather than silently overwriting. |
| Player Power | The per-player scalar that accrues with time online and is lost on death, and which sums into a faction's strength. |
| Ponder | The community's shared Java/Kotlin library — a multi-module Gradle build providing command abstraction, caching, and Bukkit helpers. |
| Release Automation | Creating a GitHub Release triggers a workflow that builds the plugin and attaches the jar, so every release has a reproducible artifact. |
| Repository Pattern | Each domain record gets a storage-agnostic interface plus a jOOQ implementation, so services never name a database. |
| Service Layer | Services own in-memory state, enforce the rules, fire events, and return typed failures — commands and listeners talk only to them. |
| Testing and CI | Gradle for unit tests with Bukkit mocked out, plus a Docker Compose Spigot server for anything that cannot be isolated. |
| Two-Tier Documentation | Reference documents live in the repository and are versioned with the code; narrative and community content lives in the GitHub wiki. |
| Value Class Identifier | Every record's id is a Kotlin inline value class wrapping a UUID string, making identifiers type-safe at compile time and free at runtime. |
| Vassalage | The feudal hierarchy — a liege draws power from its vassals, but only while its own members remain strong. |
Latest Blog Posts
- Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)By Om-Shree-0709 on .mcpAgent IdentityOAuth 2.1
- Your AI Chatbot Just Exposed Your CEO's Salary to an InternBy Om-Shree-0709 on .Agent IdentityMCP SecurityOAuth Delegation
- Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)By Om-Shree-0709 on .Agentic AiPrompt InjectionWebAssembly
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