clausewitz-mcp
Server Configuration
Describes the environment variables required to run the server.
| Name | Required | Description | Default |
|---|---|---|---|
No arguments | |||
Instructions
Guidance the server publishes about itself, which clients place ahead of the tool catalog so the model reads it before choosing anything.
This server publishes no instructions, or was last inspected before Glama recorded them.
Capabilities
Features and capabilities supported by this server
Protocol revision2025-11-25
| Capability | Details |
|---|---|
| tools | {
"listChanged": true
} |
| logging | {} |
| prompts | {
"listChanged": false
} |
| resources | {
"subscribe": false,
"listChanged": false
} |
| extensions | {
"io.modelcontextprotocol/ui": {}
} |
| experimental | {} |
Tools
Functions exposed to the LLM to take actions
| Name | Description |
|---|---|
| set_workspaceA | Point the server at a vanilla game tree, optional mod trees, and an optional script_docs dump, then index everything. game_root: the game's install directory (the one containing |
| workspace_statusB | What is currently indexed, and whether script_docs are loaded. |
| docs_reportA | Show which script_docs files were ingested and how many entries came out of each. Use this to sanity-check the dump was parsed sensibly — an entry count of 1 for a large file means the split heuristics missed. |
| lookup_scriptA | Look up a trigger, effect, scope, event target or modifier in the game's own generated documentation. Returns the raw doc entry verbatim, including supported scopes and targets. This is the authoritative source for what exists in this build. Prefer it over recalled knowledge for anything you are about to write. |
| search_script_docsA | Substring search across script_docs names and bodies. Use when you know roughly what you want ('prestige', 'add flag') but not the exact name. kind: trigger, effect, scope, event_target, modifier, on_action, data_type. |
| find_definitionA | Find where a named game object is defined (a religion, a building, a scripted effect, an event). Searches vanilla and every loaded mod. category: optional path filter, e.g. 'common/religions' or 'events'. |
| search_definitionsC | Substring search over every defined object name in the indexed tree. |
| find_usagesA | Find where a name is actually used across the tree — the fastest way to get real, working examples of a pattern before writing your own. |
| read_blockA | Read one block out of a script file instead of the whole thing. file: path relative to the game/mod script root, e.g. 'common/religions/00_religion.txt'. key_path: keys to walk into, e.g. ['catholic'] or ['my_event', 'trigger']. source: 'vanilla' or a mod directory name, when the same path exists in both. |
| list_categoriesB | List the script directories in the indexed tree with definition counts — a map of where things live, e.g. 'common/religions': 12. |
| lookup_localisationA | Resolve a localisation key to its text, file and line. |
| parse_scriptA | Syntax-check a snippet of Clausewitz script without writing it to disk. Call this on anything you are about to write. Returns exact line/column for every problem, and the top-level keys the parser saw so you can confirm the structure came out the way you intended. |
| validate_modA | Run validation over the loaded mod(s). checks: any of syntax, encoding, duplicates, localisation, unknown_script,
shadowing. Defaults to all. |
Prompts
Interactive templates invoked by user choice
| Name | Description |
|---|---|
No prompts | |
Resources
Contextual data attached and managed by the client
| Name | Description |
|---|---|
No resources | |
TDQS
Scored across 13 tools
Tools are mostly distinct, targeting separate concerns: reading blocks, listing categories, localisation lookup, parsing, validation, definition lookup, substring search on definitions or docs, usage search, and workspace management. The pairings find/search and lookup/search are distinguished by exact vs. substring and game objects vs. script_docs, though they could still be confused by an agent without careful reading.
Names predominantly follow a verb_noun pattern with snake_case (read_block, find_definition, set_workspace). The exceptions are docs_report and workspace_status, which are noun-first compounds, creating a minor inconsistency but not enough to cause confusion.
13 tools is well within the sweet spot for a domain-specific server. Each tool addresses a distinct need—setup, indexing, search, reading, validation, and documentation—without redundancy or bloat.
The surface covers the core workflow of a Clausewitz modding assistant: workspace setup, indexing, searching definitions/usages, reading script blocks, looking up docs, validating syntax and mods, and checking docs ingestion. Minor gaps include the absence of a whole-file read or a file-write tool, but those fall outside the server's read/validate role.