Loading ToolBench
MCP server for the DPC Zettelkasten — query the Dan's Plugins Community knowledge graph and read the commit-pinned citations behind every claim.
Six tools with complete input schemas and strong descriptions (avg 180 chars, well above 10-char minimum). All tools follow verb_noun naming (search_, get_, list_). Schemas properly typed with enums and constraints. However, output schemas are not explicitly documented in the source code, only inferred from handler implementations. Error handling is minimal (basic validation only, no recovery guidance). No tool annotations (readOnlyHint, etc.). The collection is read-only, which simplifies security, but descriptions could better explain when to use each tool vs. alternatives (e.g., graphql vs. search_notes).
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.
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.
The GraphQL schema as SDL. Use this to understand what queries are possible, or to generate a query for graphql.
Query the knowledge graph directly with GraphQL. The schema is embedded in this description. Every claim returned 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.
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.
Output schemas not documented in source code. Handlers return structured objects (brief(), full(), sources array) but no explicit schema definitions visible. LLMs cannot plan downstream calls without knowing return field names and types.
No tool annotations (readOnlyHint, destructiveHint, idempotentHint). All six tools are read-only and idempotent, but this is not declared in the tool definitions. Agents cannot infer safety properties without explicit hints.
Error handling lacks recovery guidance. Validation errors (e.g., 'query must be a non-empty string') are thrown but do not suggest next steps. No categorization of errors as retryable, user-fixable, or fatal.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-23 | C | 65 | 2026-07-28+ | v2 |
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.
list_maps description (Dockerfile source) is vague: 'The structure of the collection: every Map of Content and the concept notes that call it home.' Does not explain when to call it vs. search_notes or graphql, or what the return structure contains.
graphql tool description embeds schema inline ('The schema is embedded in this description') but the actual schema is not visible in the provided source. Agents cannot write valid queries without seeing the schema structure.