clausewitz-mcp

by jacklenzotti

Overview Schema Related Servers Score Discussions

Python

Local

Server Quality Checklist

Profile completionA complete profile improves this server's visibility in search results.

Latest release: v0.1.0
Disambiguation4/5
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.
Naming Consistency4/5
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.
Tool Count5/5
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.
Completeness4/5
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.
Average 4/5 across 13 of 13 tools scored. Lowest: 2.9/5.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- No commit activity data available
- No stable releases found
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI status not available
This repository is licensed under MIT License.
This repository includes a README.md file.
No tool usage detected in the last 30 days. Usage tracking helps demonstrate server value.
Tip: use the "Try in Browser" feature on the server page to seed initial usage.
Add a glama.json file to provide metadata about your server.
If you are the author, simply .
If the server belongs to an organization, first add glama.json to the root of your repository:
```
{
  "$schema": "https://glama.ai/mcp/schemas/server.json",
  "maintainers": [
    "your-github-username"
  ]
}
```
Then . Browse examples.
Add related servers to improve discoverability.

How to sync the server with GitHub?

Servers are automatically synced at least once per day, but you can also sync manually at any time to instantly update the server profile.

To manually sync the server, click the "Sync Server" button in the MCP server admin interface.

How is the quality score calculated?

The overall quality score combines two components: Tool Definition Quality (70%) and Server Coherence (30%).

Tool Definition Quality measures how well each tool describes itself to AI agents. Every tool is scored 1–5 across six dimensions: Purpose Clarity (25%), Usage Guidelines (20%), Behavioral Transparency (20%), Parameter Semantics (15%), Conciseness & Structure (10%), and Contextual Completeness (10%). The server-level definition quality score is calculated as 60% mean TDQS + 40% minimum TDQS, so a single poorly described tool pulls the score down.

Server Coherence evaluates how well the tools work together as a set, scoring four dimensions equally: Disambiguation (can agents tell tools apart?), Naming Consistency, Tool Count Appropriateness, and Completeness (are there gaps in the tool surface?).

Tiers are derived from the overall score: A (≥3.5), B (≥3.0), C (≥2.0), D (≥1.0), F (<1.0). B and above is considered passing.

Tool Scores

Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description discloses the search mode (substring) and scope (defined object names in the indexed tree), which adds some behavioral context. However, with no annotations, it omits important traits such as read-only safety, case sensitivity, result handling, and the effect of category or limit.
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 a single, tightly worded sentence that front-loads the core purpose. There is no filler or redundant repetition.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a search tool with three parameters and no annotations, the description is too terse. It leaves parameter behavior, filtering, and search specifics unclear, although the presence of an output schema reduces the need to explain return values.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0% and the description does not mention any of the three parameters. The 'query' parameter is self-evident by name, but 'limit' and 'category' semantics are entirely undocumented, and the description fails to compensate for the lack of schema descriptions.
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 identifies the tool as a substring search over every defined object name in the indexed tree. It is specific in scope but does not explicitly distinguish itself from sibling tools like find_definition or search_script_docs.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no guidance on when to use this tool versus alternatives. The usage context is only implied by the description, and no exclusions or alternative tool mentions are provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must disclose all behavioral traits. It reveals the output format (map with counts) but omits how the `filter` parameter affects results, whether results are sorted, or any other behavioral nuances. This leaves significant gaps for a tool with a parameter.
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 a single, information-dense sentence with a concrete example. Every word earns its place, and it avoids repetition or irrelevant details.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is simple and the description captures its core listing behavior, but the unexplained filter parameter and lack of usage guidance reduce completeness. The presence of an output schema helps, but doesn't compensate for the parameter ambiguity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has a single `filter` parameter with 0% description coverage, and the tool description does not mention it at all. This is a critical omission; the agent cannot know what `filter` accepts or how it modifies the output.
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 'list' and clearly names the resource 'script directories in the indexed tree' with output details ('map of where things live'), making its purpose obvious and distinct from the search-oriented sibling tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description does not explicitly state when to use this tool versus alternatives, nor does it mention exclusions. However, the function itself implies a directory-overview use case, and its uniqueness among siblings provides an implied context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are present, so the description carries the full burden of behavioral disclosure. It only states what information is returned, not whether the operation is read-only or side-effect free. For a status tool, read-only behavior is implied but not explicitly disclosed.
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 a single short sentence that directly states the tool's function without unnecessary words. It is front-loaded and easy for an agent to parse.
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 status tool with an output schema, the description sufficiently identifies the two key pieces of information returned: indexed content and script_docs load status. It doesn't specify output format, but the output schema covers that. Slight ambiguity about what 'currently indexed' includes could be clarified, but overall it is adequate.
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 tool accepts no parameters, and the input schema already documents this completely (100% coverage). The description adds no parameter details, but none are needed; the baseline for zero-parameter tools is 4.
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 identifies the tool as reporting workspace indexing status and whether script_docs are loaded. It lacks an explicit verb like 'get' or 'show', but it differentiates from sibling tools such as set_workspace or docs_report by specifying the exact state information returned.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit guidance is given on when to use this tool versus alternatives like docs_report or set_workspace. The phrasing implies a status-checking use case, but there are no exclusions or alternative recommendations.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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 usefully reveals that the search covers vanilla and every loaded mod, and that category is an optional path filter. It does not mention edge cases, output structure, or error behavior, but given the presence of an output schema, the description provides moderate transparency.
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 concise and front-loaded: two sentences deliver the core purpose and scope, followed by a brief parameter note. Every sentence adds value without redundancy.
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 simple two-parameter tool with an output schema, the description is mostly complete. It covers purpose, scope, object types, and the category parameter. Missing sibling differentiation and explicit error/return behavior slightly reduce completeness, but the tool is likely straightforward enough that current coverage suffices.
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 0%, so the description must compensate. It explains 'category' with examples ('common/religions' or 'events') and implies that 'name' refers to the named object from the first sentence. This is helpful but not exhaustive; the name parameter lacks an explicit format or example.
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 purpose: 'Find where a named game object is defined' and provides concrete examples (religion, building, scripted effect, event). It also specifies scope ('searches vanilla and every loaded mod'), but does not explicitly contrast with sibling tools like search_definitions or find_usages.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Usage is implied: you would use this tool when you need to locate the definition file for a game object. However, no explicit guidance is given about when to prefer this over search_definitions or other siblings, and no exclusions or alternative recommendations are provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must carry behavioral disclosure. It communicates that the operation is read-only and scoped to usage occurrences, but it omits details such as pagination behavior, whether limit applies to results, or any performance/cost implications. The phrase 'fastest way' is a performance claim but unverified. This is adequate but not rich.
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 a single, front-loaded sentence with no fluff. Every phrase earns its place: 'actually used' clarifies scope, and the second clause gives a compelling reason to use the tool. It is highly concise and well-structured.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity and the presence of an output schema, the description covers the core purpose but misses important contextual details: it does not mention the limit parameter, give explicit guidance on when to prefer this over sibling tools like search_definitions, or describe what 'working examples' look like. It is minimally complete but lacks polish.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description should compensate. It clarifies that 'name' is the identifier to find usages for, but it does not explain the 'limit' parameter at all (e.g., maximum number of results, default behavior). The name parameter is inferable, but limit semantics are left entirely to schema defaults, which is insufficient.
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 finds where a name is used across the tree, with a specific verb ('find') and resource ('name'). It distinguishes itself from sibling tools like find_definition by focusing on usages rather than definitions, and 'across the tree' gives scope.
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 gives strong contextual guidance: 'the fastest way to get real, working examples of a pattern before writing your own' implies using this tool when you want to see existing usage examples. However, it does not explicitly name alternatives or state when not to use it, so it stops short of a 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden. It clearly states the tool resolves to text, file and line, indicating a read-only lookup. However, it does not disclose behavior for missing keys, return format details, or any potential side effects. For a simple lookup, this is adequate but not rich.
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 a single, focused sentence with no redundancy. It front-loads the verb and resource, and every word adds value. This is exemplary conciseness.
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 tool is simple: one required parameter, an output schema exists, and the description names the three return fields (text, file, line). It is complete for its core purpose. It doesn't mention edge cases or alternatives, but given the simplicity and existing output schema, the description is sufficiently 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?
Schema description coverage is 0%, so the description must compensate. The term 'localisation key' adds meaning beyond the schema's bare 'key' parameter, indicating the expected input format and domain. However, it doesn't elaborate on formatting, case sensitivity, or examples, so it only partially compensates for the missing schema descriptions.
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 'Resolve' with a clear resource ('localisation key') and specifies the output ('text, file and line'). This distinguishes it from sibling tools like lookup_script (which likely resolves script references) and search_definitions, making the tool's unique purpose immediately clear.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage: when you have a localisation key and want its text and location. However, it gives no explicit guidance on when to use this tool versus siblings like lookup_script or search_definitions, nor does it mention any exclusions or prerequisites. The context is straightforward but the guidance is not explicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the transparency burden. It discloses the return format ('raw doc entry verbatim, including supported scopes and targets') and states it is authoritative. It does not mention error behavior or side effects, but for a read-only lookup this is acceptable.
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, front-loaded with the action and resource, and every sentence earns its place. It is concise and well-structured with no superfluous text.
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 simplicity and the presence of an output schema, the description adequately covers purpose, usage, and return format. It lacks explicit error scenarios and parameter details, but these are secondary to the core function and are partially covered by the schema.
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 description coverage is 0%, so the description must compensate. It lists the categories (trigger, effect, scope, event target, modifier) which imply the 'kind' parameter values, and 'name' is implied as the identifier. However, it does not explicitly map these to parameter names, leaving some ambiguity.
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 performs a lookup for specific game elements (triggers, effects, scopes, etc.) in the game's generated documentation. It distinguishes itself from sibling tools like lookup_localisation and search_definitions by specifying the exact resource types and the authoritative nature of the documentation.
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 provides a clear usage guideline: 'Prefer it over recalled knowledge for anything you are about to write.' This tells the agent when to use this tool as a verification step. It does not explicitly name alternative tools or exclusions, but the context is strong.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It explains the core behavior and source disambiguation, but does not disclose what happens when key_path is omitted or when the desired block is not found. The read-only nature is implied but not explicitly stated, and edge-case behavior is absent.
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 extremely concise: a one-sentence purpose followed by three parameter lines, each with a brief explanation and example. Every sentence earns its place, with no fluff or repetition.
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 relatively simple read tool, the description covers all parameters and the primary use case. It leverages the existence of an output schema, so no return-value explanation is needed. Minor gaps exist around edge cases (e.g., null key_path), but overall it is adequately complete.
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?
Schema description coverage is 0%, so the description fully compensates. It provides meaningful explanations and examples for all three parameters: file path, key_path walk, and source disambiguation. This adds significant value beyond the bare type/default information in the input 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 opens with a specific verb+resource: 'Read one block out of a script file'. The phrase 'instead of the whole thing' differentiates it from tools that parse entire files, making its scope clear and distinguishing it from siblings like parse_script.
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 implies use cases by saying 'instead of the whole thing', suggesting this tool is for when only a single block is needed. The 'source' parameter is explained with an explicit conditional ('when the same path exists in both'), giving clear context. However, it doesn't explicitly name alternative tools or state when not to use this tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the behavioral burden. It discloses that the search is substring-based and covers both names and bodies, which is meaningful behavioral information. It also lists accepted kind values, clarifying input constraints. As a search tool, no side effects are expected, and the description adequately conveys the operation.
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 highly concise, using two short sentences and a list. It front-loads the core purpose, then provides usage guidance and parameter enumeration. Every sentence earns its place with no redundant information.
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?
An output schema exists, so return formats are covered. The description explains the tool's purpose, provides usage context, and lists valid kind values. Given the tool's simplicity (3 parameters, no nested objects), this is sufficient for accurate selection and invocation, though it could mention workspace context like other sibling tools do.
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?
Schema coverage is 0%, and the description compensates by enumerating the exact allowed values for the 'kind' parameter: trigger, effect, scope, event_target, modifier, on_action, data_type. This adds substantial meaning beyond the schema's plain string type. It does not elaborate on 'limit' or 'query' semantics, though query is self-explanatory and limit has a default in the 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 performs 'Substring search across script_docs names and bodies,' specifying the action (search), the resource (script_docs), and the scope (names and bodies). This distinguishes it from sibling tools like find_definition or search_definitions, which are likely exact or definition-focused.
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 provides explicit guidance on when to use: 'Use when you know roughly what you want... but not the exact name.' It gives concrete examples ('prestige', 'add flag') and implies this is for fuzzy/partial searches. However, it does not explicitly name alternative tools for exact searches, so it lacks a clear when-not-to-use statement.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden. It explains that the tool reports per-file ingestion counts and adds interpretive context ('an entry count of 1 for a large file means the split heuristics missed'). It does not discuss side effects or permissions, but the read-only nature is implied and appropriate for a reporting tool.
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 with no filler. The first sentence states the core function and output; the second sentence explains the practical use case and provides diagnostic guidance. Every sentence earns its place.
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 parameters) and has an output schema, so the description only needs to convey purpose and interpretation. It does both effectively, including a concrete sanity-check example. No important context is missing for an agent to select and invoke this 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 tool has zero parameters, so there is no parameter detail to add. The description correctly omits parameter explanations, and the schema is fully covered vacuously. Baseline 4 applies for a zero-parameter tool.
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 ('Show') and names the exact resource ('script_docs files') and output ('how many entries came out of each'). It clearly distinguishes this tool from sibling search/parse tools by focusing on ingestion reporting rather than content access.
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 tells when to use the tool: 'Use this to sanity-check the dump was parsed sensibly.' It provides a concrete example of what to look for, making the intended use case clear, though it does not explicitly name alternatives or when not to use it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/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 explicitly states the tool does not write to disk (non-destructive), returns exact line/column for every problem, and returns top-level keys for structural confirmation. This goes beyond a basic description but does not cover potential limitations like performance or workspace dependencies.
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 extremely concise—two sentences—and front-loads the core action ('Syntax-check a snippet'). Every sentence earns its place: the first states what and how, the second gives usage guidance and explains return values. No wasted words.
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?
Given the tool's simplicity (one parameter, no annotations, output schema present), the description is thorough. It covers what the tool does, when to use it, that it is side-effect-free, and what it returns (line/column and top-level keys). The output schema would provide the exact return structure, so the description does not need to repeat it.
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 has 0% description coverage for the 'text' parameter, so the description must compensate. It does by clarifying that 'text' is the Clausewitz script snippet to be checked, and 'Call this on anything you are about to write' reinforces the parameter's purpose. It does not specify constraints, but for a single string parameter this is adequate.
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's function with a specific verb and resource: 'Syntax-check a snippet of Clausewitz script'. It distinguishes itself from siblings by focusing on syntax-checking without writing to disk, which no other sibling tool does. The added detail about returning line/column and top-level keys further clarifies its unique purpose.
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 provides explicit when-to-use guidance: 'Call this on anything you are about to write.' This is clear and actionable, but it does not mention alternatives or when not to use the tool. However, the context implies it is the go-to tool for pre-writing snippet validation, making the guidance effective.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It discloses key behaviors: docs_dir being 'strongly recommended; several checks are skipped without it,' mod_roots precedence ('later entries win'), and game override for auto-detection. It does not mention potential side effects like whether indexing creates cache files or modifies workspace state, but it provides substantial behavioral context beyond a minimal statement.
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 efficiently structured: a one-sentence lead followed by clear parameter explanations. There is no redundant text, and each parameter explanation adds unique value. The formatting with indentation improves readability without padding.
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 setup tool with four parameters and no annotations, this description is highly complete. It explains the purpose, all parameters with domain meaning, and a critical caveat (docs_dir impact). Since an output schema exists, return values do not need to be described. The tool is complex, and the description covers all essential operational aspects.
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 schema has 0% description coverage, so the description must compensate. It does so excellently: game_root specifies the install directory with a note about common/ or game/ layouts, mod_roots explains load order and precedence, docs_dir identifies the script_docs output and its importance, and game lists allowed values. This goes far beyond the bare schema and gives the agent actionable guidance.
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's function: 'Point the server at a vanilla game tree, optional mod trees, and an optional script_docs dump, then index everything.' The verb 'point' and the resource list (game tree, mod trees, docs dump) make the purpose specific and differentiate it from sibling tools like read_block or search_script_docs, which operate on an already-set-up workspace.
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 implies this is the initialization/setup tool, as it says 'point the server at' and 'then index everything,' which is clearly a prerequisite for using the read/search/validate tools. However, it does not explicitly mention when not to use it or name alternative tools, so it falls short of a 5 but provides clear context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries the burden. It discloses that checks default to all, and that unknown_script is skipped if script_docs not loaded 'rather than guessed at', revealing non-failure behavior. However, it does not explicitly state whether validation is read-only or may produce side effects, nor response behavior (but output schema exists).
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 tight sentences; first states the main action, second gives parameter details and default. No filler.
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 one-parameter validation tool, the description covers the main action, allowed check types, defaults, and conditional behavior. Output schema handles return structure. No significant 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?
Schema has no description for 'checks', but the description lists all acceptable values (syntax, encoding, duplicates, localisation, unknown_script, shadowing) and explains default null means all. It also gives a caveat for unknown_script, fully compensating for zero 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?
Clearly states 'Run validation over the loaded mod(s)', identifying a specific action and resource. The checks list further specifies scope. Distinct from sibling tools which are read/search operations.
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?
Provides context on when to use: validates loaded mods with configurable checks. Notes the default behavior and the special requirement for unknown_script (needs script_docs loaded), giving conditional guidance. Does not explicitly name alternatives, but sibling tools are all distinct in purpose.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

GitHub Badge

Glama performs regular codebase and documentation scans to:

Confirm that the MCP server is working as expected.
Confirm that there are no obvious security issues.
Evaluate tool definition quality.

Our badge communicates server capabilities, safety, and installation instructions.

Card Badge

Copy to your README.md:

[![clausewitz-mcp MCP server](https://glama.ai/mcp/servers/jacklenzotti/clausewitz-mcp/badges/card.svg)](https://glama.ai/mcp/servers/jacklenzotti/clausewitz-mcp)

Score Badge

Copy to your README.md:

[![clausewitz-mcp MCP server](https://glama.ai/mcp/servers/jacklenzotti/clausewitz-mcp/badges/score.svg)](https://glama.ai/mcp/servers/jacklenzotti/clausewitz-mcp)

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/jacklenzotti/clausewitz-mcp'

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