crabsmadethis/d2r-horadric-tools

by crabsmadethis

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
Disambiguation5/5
Each tool has a clear, distinct purpose. The naming with category prefixes (chargen, lookup, mod, save) and specific actions prevents ambiguity. For example, d2r_chargen_build and d2r_save_inspect operate on different resources, and lookups are split by item type.
Naming Consistency5/5
All tools follow the consistent pattern 'd2r_<category>_<action>', using snake_case uniformly. There are no mixed conventions (e.g., camelCase) or irregular formats.
Tool Count5/5
23 tools cover the full modding lifecycle—character generation, lookups, mod building/deploying, and save file inspection—without being excessive. Each tool seems justified for its role.
Completeness5/5
The tool set covers the main workflows: chargen (build, import, validate), lookups (all item types), mod management (extract, build, deploy, clean, update, diff, audit), and save operations (inspect, scan, diff, list items). No obvious gaps for the intended domain.
Average 3.8/5 across 23 of 23 tools scored. Lowest: 2/5.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 2 commits in the last 12 weeks
- Last stable release on May 20, 2026
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI is passing
This repository is licensed under MIT License.
This repository includes a README.md file.
Tools from this server were used 2 times in the last 30 days.
This repository includes a glama.json configuration file.
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.
View related servers

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

Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description bears full responsibility for behavioral disclosure. It mentions a multi-step pipeline but gives no details on side effects, permissions, or what gets modified. For a tool that likely performs destructive operations, this is insufficient.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely short (one sentence), but it does not convey necessary information. Conciseness should pack meaningful content into few words; here, it under-specifies the tool, making it unhelpful.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema, no annotations, and the complexity of a multi-step pipeline, the description is grossly incomplete. It does not explain the order of operations, return value, or how the pipeline affects the mod, leaving major gaps for the agent.
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 input schema has three parameters with 0% description coverage, yet the description offers no explanation of their purpose or effects. The parameters 'warn_conflicts', 'no_regen', and 'game_dir' are completely unexplained, failing to add any value beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states 'Full recovery pipeline: extract → build → deploy', which indicates a composite operation. However, the verb 'update' in the name is not directly mapped to the pipeline, and it does not clearly specify what is being recovered. While it distinguishes itself from individual sibling tools by being a combination, it lacks specificity.
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 guidance is provided on when to use this tool versus the individual extract, build, and deploy tools. The description does not mention prerequisites, context, or alternatives, leaving the agent without direction.
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, description must carry burden of behavioral disclosure. It implies a read-only comparison but does not explicitly state non-destructiveness, permission requirements, or any side effects. Lacks details about the comparison process.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, concise and front-loaded. However, it sacrifices necessary details for brevity, leaving out parameter explanations and behavioral context.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given two optional parameters, no output schema, and no annotations, the description is severely incomplete. It does not explain what 'vanilla/ vs build/ tables' refers to, the format of returned file list, or how parameters affect behavior.
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?
Description does not mention either parameter ('file' or 'summary'). With 0% schema coverage, the description fails to add any meaning beyond bare schema. Agent will not know how to use the parameters correctly.
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?
Description clearly states action 'compare' and resources 'vanilla/ vs build/ tables', and output 'list of changed files'. It is specific and easily understood, but does not differentiate from 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 Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives like d2r_mod_build or d2r_save_diff. No context on prerequisites or intended workflow.
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 provided, and the description only states the action without revealing behavioral traits such as side effects (e.g., file creation), permissions needed, or idempotency. The mention of 'into build/' implies file output but lacks specificity.
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?
Extremely concise single sentence with no wasted words. However, it could be slightly expanded to improve completeness without losing conciseness.
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?
Given 3 optional parameters and no output schema, the description is too minimal. It fails to explain concepts like overlays/scripts, the structure of build/, or return value. Sibling tools provide context but the description itself is incomplete.
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 has 3 parameters with 0% documented in description. The description adds no meaning beyond schema field names. Agent gets no help on what these parameters do or how to set them.
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 the verb 'Build' and the resource 'mod' with inputs (vanilla, overlays, scripts) and output destination (build/). Distinguishes from sibling tools like d2r_mod_clean and d2r_mod_deploy.
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 guidance on when to use this tool versus alternatives, no prerequisites or conditions mentioned. Relies solely on the tool name to imply usage.
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 provided, so the description bears the full burden for behavioral disclosure. While 'compare' implies a read-only operation, the description does not explicitly state that the tool makes no changes. It also fails to describe what 'structural differences' entail (e.g., specific sections compared) or the output format, leaving the agent without key behavioral information.
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, consisting of two sentences plus parameter docs. It front-loads the core action and avoids any extraneous information. Every word serves a purpose, making it easy for an agent to parse quickly.
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?
Given the lack of annotations and output schema, the description is notably incomplete. It does not describe the return format, error behavior (e.g., missing files, identical saves), or limitations. For a diff tool, the agent needs this context to correctly use and interpret results.
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%, yet the description adds only minimal semantic value: 'path_a: First save (treated as "before")' and 'path_b: Second save (treated as "after")'. It does not clarify file path expectations (absolute vs. relative, existence requirements) or any constraints, so the description insufficiently compensates for the sparse schema.
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: comparing two .d2s files and returning structural differences. It specifies the resource type (.d2s files) and the action (compare/diff). However, it does not explicitly differentiate from sibling save tools like d2r_save_inspect or d2r_save_scan, which could cause ambiguity.
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?
The description provides ordering guidance (path_a is 'before', path_b is 'after') but offers no information about when to use this tool versus alternatives (e.g., when a simple scan vs. diff is needed). It lacks explicit usage context or exclusions.
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 behavioral traits. It mentions CASC injection but does not explain what that entails, whether deployment is destructive, or what side effects occur (e.g., overwrite, backup). The flags are not described.
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 a single, front-loaded sentence that conveys the core purpose efficiently. It could benefit from a list of flags, but it is not overly verbose.
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?
Given 6 parameters, no output schema, and no annotations, the description lacks details on return values, prerequisites, error conditions, and the effect of each flag. It is insufficient for a complex deployment tool.
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 only mentions 'by default' regarding CASC injection, but does not explain individual parameters like 'force', 'no_casc', 'no_build', etc. Agents must guess from parameter names.
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 'Build + deploy mod to the game mod folder', specifying the verb and resource. It also mentions 'runs CASC injection by default', which distinguishes it from siblings like d2r_mod_build (build only) and d2r_mod_undeploy (reverse).
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 guidance on when to use this tool vs alternatives (e.g., d2r_mod_build for build only). The description implies default behavior but does not explain when to set specific flags or avoid this tool.
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 provided, so the description carries full burden. It does not disclose side effects like whether files are overwritten, whether the operation is safe to repeat, or any permissions required. This lack of transparency is a significant gap for a data extraction 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 a single, efficient sentence with no unnecessary words. It is front-loaded with the verb and resource, making it easy to parse quickly.
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?
Given the tool's simplicity (one optional parameter, no output schema), the description fails to clarify the purpose of 'game_dir' or what 'vanilla/' means. It does not mention return values or effects, leaving the agent without full context for invocation.
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 description coverage is 0%, meaning the description adds no information about the 'game_dir' parameter. The parameter has no enumeration or defaults explained, and the description offers no hint about its purpose, leaving the agent to guess.
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 a specific action ('Extract vanilla data from CASC archive into vanilla/') and distinguishes itself from sibling tools like d2r_mod_build or d2r_mod_audit by focusing on extraction rather than building or auditing.
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?
The description provides no guidance on when to use this tool versus alternatives (e.g., d2r_mod_clean or d2r_mod_build). There is no mention of prerequisites, workflow positioning, or cases where extraction should be skipped.
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?
The description mentions writing markdown reports to a directory, but does not disclose whether the tool is read-only, destructive, or the exact output format. With no annotations provided, the description should cover more behavioral traits.
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 very concise: one sentence for purpose and a clear Args list. Every sentence adds value, with no redundant information.
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?
Given no output schema and no annotations, the description should provide more context about return values, side effects (e.g., file creation), and prerequisites (e.g., mod must be extracted). It only covers basic parameter usage.
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 description adds meaning to all 4 parameters (skills, items, audit_all, output_dir) beyond the schema, including defaults and the override behavior of audit_all. However, it lacks details like allowed values for output_dir or error handling.
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 states it audits vanilla skills and items and writes markdown reports. This is a clear specific verb and resource. However, it could be more explicit about what 'audit' entails to distinguish from sibling mod tools.
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 guidance on when to use this tool versus alternatives like d2r_mod_diff or d2r_mod_build. There is no mention of prerequisites or context, leaving the agent to infer usage.
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?
No annotations present. Description explains the primary behavior (validation) and the yaml_only flag (skips dry-run and scanner). Does not disclose side effects (likely none), API requirements, or return format, but adequate for a simple validation 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?
Extremely concise: only two sentences plus bullet-point args. No redundant information. Front-loaded with core purpose.
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 no output schema and no annotations, the description should clarify return values. It does not mention what the tool outputs (e.g., validation results, success/failure). For a validation tool, this is a gap. Parameters are well-described, but output is omitted.
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%, so description must carry parameter information. It explains that name resolves to 'chars/<name>.yaml' and that yaml_only skips the dry-run build and scanner pass. This adds meaningful context beyond the schema.
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?
Description clearly states 'Validate a character YAML' with optional dry-run build. It specifies the resource (character YAML) and action, distinguishing it from siblings like d2r_chargen_build or d2r_chargen_list. However, it does not explicitly contrast with these siblings.
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 guidance on when to use this tool versus alternatives like d2r_chargen_build. The description only explains parameters, not usage context or prerequisites.
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 provided, so the description carries the full burden. It only states basic behavior (lookup, substring matching) but omits critical details like read-only nature, error handling (e.g., no match found), or any side effects. This is insufficient for safe agent decision-making.
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 fairly concise at two sentences plus an args line, with the main purpose front-loaded. It could be more structured (e.g., bullet points) but remains efficient.
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 (one parameter) and presence of an output schema, the description sufficiently covers the input and high-level output ('Returns runes, valid bases, stats'). It does not need to elaborate further for a straightforward lookup.
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 one parameter 'query' with anyOf string/integer and no description. The description compensates by explaining that strings represent runeword names (with substring support) and integers represent numeric IDs, providing essential semantics beyond 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 verb 'look up' and the resource 'D2R runeword', with specifics like by name or numeric ID and substring matching. It differentiates from sibling lookup tools (e.g., d2r_lookup_item_base, d2r_lookup_skill) by specifying the resource.
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 explains what the tool does but provides no guidance on when to use it versus alternatives like other lookup tools. Without explicit usage context, an agent must infer from the tool name alone.
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 provided, so the description carries full burden. It only states it lists names from files, but does not mention permissions, side effects, or output format, leaving significant gaps.
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?
Single sentence, no wasted words. Front-loaded with action and target.
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, no-parameter list tool, the description is mostly complete. However, it does not specify the exact format of the output (e.g., just names or full paths), leaving minor ambiguity.
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?
There are zero parameters, and schema coverage is 100%. The description adds value by specifying the source ('chars/*.yaml'), which is not in the schema. Baseline for 0 params is 4.
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 resource ('character names defined in chars/*.yaml'), clearly distinguishing it from siblings like d2r_chargen_build or d2r_chargen_import.
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?
No explicit guidance on when to use this tool versus alternatives. The purpose is implied (simple listing), but no exclusions or context for 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.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It reveals that the tool reads a live save from a specific path (<SAVES>/<name>.d2s) and mentions the force parameter for overwriting. However, it does not explain the behavior when force is false (likely an error), error handling, or other side effects.
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 very concise, with a clear one-line purpose followed by a structured Args section. Every sentence is informative and there is no clutter.
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 import tool with 2 parameters and no output schema or annotations, the description covers the essential workflow: what is imported, from where, and the optional overwrite flag. It could mention the output format (yaml file), but overall is quite complete.
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?
With 0% schema description coverage, the description adds crucial meaning: 'name' is explained as reading a live save at a specific path, and 'force' is described as overwriting an existing file. This clarifies both parameters beyond the bare schema types.
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 action 'Import a server-synced .d2s save into chars/<name>.yaml' with specific verb and resource. It distinguishes from sibling chargen tools like d2r_chargen_build, d2r_chargen_list, and d2r_chargen_validate, which handle other chargen operations.
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 for importing .d2s saves into yaml format, but does not explicitly state when to use this tool versus alternatives. No exclusion conditions 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 detail behavior. It mentions substring matching and return fields (dimensions, requirements, sockets), which is helpful. However, it lacks clarity on case sensitivity, exact vs substring behavior for codes, and what happens when no match is found. These are gaps for a lookup 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 concise and well-structured, starting with the purpose, then search method, return info, and args section. Every sentence adds value without unnecessary fluff.
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 (one parameter, output schema exists), the description covers the core aspects: what it looks up, how to query, and what it returns. It could mention error handling or edge cases, but it's largely complete for agent use.
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 only has a 'Query' title with 0% coverage, so the description compensates by explaining the parameter format: '3-character item code (e.g. 'hax') or item name' and gives an example. This adds significant meaning beyond the schema, though it could clarify that codes expect exact match.
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 purpose: 'Look up a D2R base item by 3-char code or name.' This specific verb-resource combination distinguishes it from sibling lookup tools that target different entities like runewords, skills, or uniques.
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?
While the description implies usage for base items (by naming them), it does not explicitly state when to use this tool over alternatives or provide exclusions. For example, it doesn't say 'Use this for base items, use d2r_lookup_runeword for runewords.' The context from sibling names helps but is not explicit.
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?
No annotations exist, so description carries burden. It discloses data source (skills.py), return fields (skill ID and class), and matching behavior (substring). Lacks details on side effects, auth, or rate limits, but adequate for a read-only lookup.
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?
Extremely concise—two sentences plus bullet for args. No fluff, front-loaded with purpose. Every sentence 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?
Output schema exists, so return value explanation is unnecessary. Description covers data source, input flexibility, and matched output fields. Sibling tools are similar, making this sufficiently complete.
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%, but description adds meaning: explains query can be skill name, substring, or numeric ID. Also states what is returned, compensating for schema's lack of 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 clearly states the verb 'look up' and resource 'D2R skill', distinguishes from sibling tools like d2r_lookup_item_base and d2r_lookup_runeword by specifying the domain (skills).
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?
Provides no explicit when-to-use or when-not-to-use guidance. The mention of substring matching implies usage flexibility, but no comparison with other lookup tools or exclusion criteria.
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 full behavioral disclosure. It states the tool searches a specific data source, returns item info and set membership, and supports substring matching. This adequately describes the read-only, non-destructive nature. No contradictions or missing key behaviors.
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 very concise: two short paragraphs. The first states the purpose, and the second adds usage details. Every sentence provides necessary information without redundancy. Front-loaded with the core action.
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 simple interface (one parameter, output schema exists), the description sufficiently covers what the tool does, what input it expects, and what it returns. It doesn't need to detail the output schema since that is provided separately. Slight improvement could mention additional output details, but it's complete enough.
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 has no descriptions (0% coverage), so the description must compensate. It explains the 'query' parameter accepts 'Item name (or substring) or numeric set item ID', adding significant meaning beyond the schema's anyOf type. This clearly instructs how to use the parameter.
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 'Look up a D2R set item by name or numeric ID', specifying the exact action and resource. It distinguishes from sibling lookup tools (e.g., d2r_lookup_item_base, d2r_lookup_unique) by focusing on set items, adding details about searching 'set_items.py data' and returning 'item info + set membership'.
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 for set item lookups via the name and context, and distinguishes from siblings by specifying 'set item'. However, it does not explicitly state when to use or avoid this tool, nor does it compare to alternatives like other lookup tools. Usage is clear but not exhaustive.
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?
No annotations provided, so description carries full burden. Mentions data source ('item_stat_cost.py') and return type ('encoding info'). Lacks disclosure of error handling or edge cases, but is adequate for a lookup 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?
Three concise sentences, each with essential info: purpose, data source, return value, parameter details. No fluff.
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 a simple tool with one param and output schema, the description covers purpose, parameter semantics, and return value. Minor gap: no example queries or mention of case sensitivity.
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 0% description coverage, but description fully explains the single parameter 'query' as accepting stat ID, canonical name, or alias. Adds meaning beyond schema type (anyOf string/integer).
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?
Description states a specific verb ('Look up') and resource ('D2R stat') with clear query methods (ID, canonical name, alias). Differentiates from sibling lookup tools which target other entities (items, runewords, skills, etc.).
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?
Describes when to use (lookup stat by various identifiers) and what it returns. Does not explicitly state when not to use or contrast with siblings, but the context of stat vs other entities is implied.
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?
No annotations are provided, so the description must carry the full burden. It implies a read-only operation (listing items on disk), but does not explicitly state that it does not modify data or discuss any side effects, permissions, or rate limits.
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 with two sentences for the purpose and a bulleted argument list. Every sentence adds value, and there is no verbosity.
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 covers the core functionality and parameters. However, it does not describe the return format (e.g., list of item names, properties), which would be helpful given the lack of an output schema.
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 has 0% description coverage, so the description must compensate. It does so effectively: explaining that 'path' can be an absolute path or a bare character name, and clarifying that 'location' filters by specific areas or can be null for all items.
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 verb ('List') and resource ('items on disk in a .d2s save'), with optional filtering by location. This distinguishes it from sibling tools like d2r_save_diff or d2r_save_scan.
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 specifies that filtering is optional and lists possible location values (equipped, inventory, cube, stash, merc_equipped, or None). While it doesn't explicitly state when not to use this tool or provide alternative tool names, the context from sibling tools makes the purpose clear.
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, but description transparently explains it is a read-only lookup returning item info+stats, with substring matching. No mention of destructive actions, but clear safe usage.
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?
Extremely concise: 3 sentences plus Args section. Front-loaded with purpose. Every sentence adds value without 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?
Simple tool with one parameter, well-described. Output schema exists, so return values are covered. No missing context for an effective lookup.
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?
Despite 0% schema coverage, description enriches the parameter 'query' by explaining it can be name or numeric UID, supports substring matching, and gives an example ('harlequin' finds Harlequin Crest).
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?
Description clearly states it looks up D2R unique items by name or UID, specifies data source (unique_items.py), and mentions substring matching. Distinguished from siblings like d2r_lookup_runeword and d2r_lookup_set_item.
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 clear context on how to use (name or UID, substring matching). Implicitly separates from siblings by focusing on uniques, but no explicit when-not-to-use or alternative tool mentions.
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?
Describes actions: removes mod directory (or keeps with keep_mod=True) and unregisters launch options. Without annotations, this adequately discloses behavior. Could mention side effects like requiring game not running, but still strong.
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?
Four sentences with clear docstring structure. No unnecessary words; each sentence adds value.
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?
Covers purpose, parameters, and usage scenarios. No output schema, but return value is implicit (success/failure). Could mention prerequisites like mod being deployed, but not critical.
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?
Both parameters are explained beyond schema: keep_mod controls whether to leave mod on disk, and game_dir overrides auto-detected path. With 0% schema coverage, description fully compensates.
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?
Description clearly states verb 'Revert' and resource 'deployed D2R mod' to restore vanilla state. Distinguishes from sibling tools like d2r_mod_deploy and d2r_mod_build by focusing on undoing a deployment.
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: 'to roll back a deploy without rebuilding, or before switching to a different mod.' No explicit when-not-to-use, but context makes alternatives obvious.
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 are provided, so the description carries full burden. It explains the output structure (checksum/size status, item counts, errors), the condition for error status, and path resolution logic. It does not explicitly state read-only, but it is implied; still clear enough.
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 well-structured: first sentence states purpose, then output details, then parameter explanation. No redundant sentences; every sentence adds value.
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 has only one parameter, no output schema, and no annotations, the description covers behavior, return structure, an important rule, and parameter semantics completely. It is sufficient for an agent to use correctly.
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 single parameter 'path' has no description in the input schema, so the description adds crucial meaning: it accepts absolute paths or bare character names resolved against Steam saves dir. This fully compensates for the 0% schema description 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 clearly states the tool runs d2rdoctor scanner on a .d2s save file and returns structured results. Among siblings like d2r_save_diff or d2r_save_inspect, this tool is uniquely about scanning for issues, making its purpose distinct.
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 includes a deployment-blocker rule ('never deploy a save that this tool flags as error'), providing a strong use case. However, it does not explicitly compare to alternative save tools or state when not to use it, missing some guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description fully discloses behavioral traits: enforces CLAUDE.md rules, backs up live save, builds to temp, runs scanner, promotes only on success. It warns about the 'force' parameter discarding server progress and states that live save is untouched on failure.
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: four sentences plus parameter bullets. It front-loads the main purpose, and every sentence adds value—no unnecessary words 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?
Given no output schema, the description covers the tool's behavior (deployment process, safety, parameters) well. It lacks explicit mention of the return value, but the outcome (successful promotion or not) is implied.
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 coverage is 0%, so the description must explain parameters. It does so thoroughly: 'name' requires an existing file, 'phase' defaults to full deploy (4), 'force' skips freshness gate with a warning. This adds meaning beyond the schema titles.
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 purpose: 'Build and deploy a character to the live saves directory.' It uses specific verbs and resources, and distinguishes from sibling tools (e.g., import, list, validate) by focusing on deployment.
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 context on when to use the tool (e.g., deploying a character to live saves) and explains the safety process (backup, temp build, scanner). However, it does not explicitly mention when not to use it or provide alternatives among sibling tools.
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?
Discloses that it does not perform validation ('No scanner pass'), which is a key behavioral trait. No annotations exist, so description carries full burden and adds relevant context about limitations.
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 sentences and a brief argument list; every word is informative. Front-loaded with the core purpose, 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?
For a simple tool with one parameter, no output schema, and no annotations, the description fully covers what it does, usage guidance, and parameter semantics. An agent can confidently select and invoke 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 description adds meaning to the single 'path' parameter beyond the schema: explains it expects an absolute path or a bare character name. This compensates for 0% schema description 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 describes 'Summarize a .d2s save' with specific fields (class, level, stats, progression, merc). Distinguishes from sibling tools like d2r_save_scan and d2r_save_list_items.
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 states when not to use ('No scanner pass') and provides alternative ('use d2r_save_scan for validation'). Also explains the argument format (absolute path or character name).
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 states the search uses substring match across all item names, returns up to 20 results tagged by type, which are key behavioral traits. However, it omits details like case sensitivity, empty result behavior, or ordering. Still, it provides a reasonable overview for a search 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 concise (two sentences plus an Args section). It is front-loaded with the main purpose, then usage guidance, then parameter details. Every sentence adds value without 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?
Given the tool's simplicity (one string input, output described by schema), the description covers the essentials: scope, matching, result limit, and tagging. The existence of an output schema offloads return-value details, and the description aligns well with expected behavior.
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 single parameter 'query' is described as 'search term (substring match across all item names)', adding critical meaning beyond the schema's generic 'string' type. The schema coverage is 0%, so the description fully compensates, clarifying how the parameter is used.
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 identifies the tool's purpose: 'Search across ALL D2R item types: uniques, sets, runewords, bases.' It explicitly enumerates the types, and the name 'd2r_search' contrast with specific lookup siblings like 'd2r_lookup_unique' and 'd2r_lookup_runeword', making the scope obvious.
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 contains explicit guidance: 'Use this when you don't know what type of item you're looking for.' This directly tells the agent when to prefer this tool over the type-specific lookups. It also mentions the result limit (20) and tagging, providing clear context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Discloses exactly what is deleted (build/ directory and chargen data) and what is not touched (deployed D2R install). No annotations provided, so description carries full burden.
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?
Three concise sentences, no wasted words, front-loaded with key action.
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 no parameters and no output schema, the description provides full context: purpose, scope, and prerequisite actions.
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?
No parameters, schema coverage is 100% (none needed). Baseline 4 for zero parameters. Description does not need to add param info.
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 it wipes local mod build artifacts (build/ directory and chargen data). Distinguishes from sibling tools like d2r_mod_undeploy.
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 says when to use (start from clean slate) and when not (does not touch deployed install, suggests undeploy first for reverting game).
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:

[![d2r-horadric-tools MCP server](https://glama.ai/mcp/servers/crabsmadethis/d2r-horadric-tools/badges/card.svg)](https://glama.ai/mcp/servers/crabsmadethis/d2r-horadric-tools)

Score Badge

Copy to your README.md:

[![d2r-horadric-tools MCP server](https://glama.ai/mcp/servers/crabsmadethis/d2r-horadric-tools/badges/score.svg)](https://glama.ai/mcp/servers/crabsmadethis/d2r-horadric-tools)

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/crabsmadethis/d2r-horadric-tools'

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