This MCP server connects Claude to Warcraft III .w3x/.w3m map files, enabling direct editing via natural language. Capabilities include:
Read & Inspect Maps
Get a full map overview (name, players, units, doodads, triggers, etc.)
Read map metadata: name, author, description, players, size, script language
Browse and read any internal file in the map archive
Inspect object data (units, items, abilities, buffs, destructables, doodads, upgrades)
View placed units and doodads, terrain, regions, cameras, sounds, triggers, and imports
Read the JASS/Lua map script and string table (names, tooltips, quest text)
Edit Units & Doodads
Place, move, modify, or delete preplaced units and items
Add, modify, or remove doodads/destructables (trees, rocks, etc.)
Manage Map Elements
Add, modify, or delete regions and cameras
Set string table entries (names, tooltips, quest text)
Replace any internal file (e.g., swap models or textures)
Edit Object Data & Scripts
Modify stats for units, items, abilities, buffs, destructables, doodads, and upgrades
Create new custom objects derived from existing base types
Replace the entire map script or splice in custom JASS/Lua code via triggers that survive editor re-saves
Launch & Test
Open the modified map in the Warcraft III World Editor
Launch it directly in Warcraft III for playtesting
Safety: Edits are saved to a separate .edited.w3x copy by default, preserving the original unless you explicitly request an overwrite.
Click on "Deploy Server".
Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state.
In the chat, type @ followed by the MCP server name and your instructions, e.g., "@Warcraft 3 MCP Server Add a footman for Player 1 in the center of the map."
That's it! The server will respond to your query, and you can continue using it as needed.
Here is a step-by-step guide with screenshots.
Edit your Warcraft III maps by just talking to Claude.
This is an MCP server that connects Claude to your Warcraft III
.w3x / .w3m map files. Once it's set up, you can say things like:
"Add a footman for Player 1 in the middle of the map." "Double the hit points of every grunt." "Add a trigger that spawns 5 wolves every 30 seconds, then open the map in the editor." "Create a GUI trigger that makes footmen kill grunts on their first attack."
…and Claude makes the change directly in your map file.
How it works in one line: Warcraft's World Editor has no plugin/automation system, so this edits the map file directly. Your change is really in the map — open it in the World Editor or play it and it's there.
Download and install Node.js 18 or newer from nodejs.org.
(To check if you already have it, open a terminal and run node --version.)
Open a terminal (Command Prompt, PowerShell, or Terminal) and run:
git clone https://github.com/YElwiddi/warcraft-3-mcp-server.git
cd warcraft-3-mcp-server
npm install
npm run buildThat's it — the server is now built into the dist folder.
Pick whichever you use:
Claude Code (the CLI) — run this one command (use the full path to the folder you just built):
claude mcp add wc3 --scope user -- node "/full/path/to/warcraft-3-mcp-server/dist/index.js"Claude Desktop (the app) — open Settings → Developer → Edit Config, and add a wc3
entry under mcpServers (keep any servers you already have):
{
"mcpServers": {
"wc3": {
"command": "node",
"args": ["C:/full/path/to/warcraft-3-mcp-server/dist/index.js"]
}
}
}Close and reopen Claude Code / Claude Desktop so it loads the new tools. You're done!
💡 Tip: Use forward slashes
/in the path even on Windows, e.g.C:/Users/You/warcraft-3-mcp-server/dist/index.js.
Related MCP server: blender-mcp
Just ask Claude in plain English and give it the full path to your map. For example:
"Use wc3 to give me an overview of
C:\Users\Me\Desktop\MyMap.w3x."
By default, edits are saved to a copy next to your map (MyMap.edited.w3x) so your original is
safe. Tell Claude "overwrite the original" if you want it to edit the file in place.
Tool | What it does |
| A quick summary of the whole map (great starting point) |
| Map name, author, players, size |
| List or read any file inside the map |
| Read units / items / abilities / etc. and their stats |
| What's placed on the map |
| The map's script (JASS / Lua) |
| Text strings (names, tooltips, quest text) |
| Regions, cameras, sounds |
| Terrain summary (size, tiles, height) |
| GUI triggers in full (events, conditions, actions) and imported files |
Tool | What it does |
| Add, move, or remove units |
| Add, move, or remove doodads/trees/etc. |
| Manage regions |
| Manage cameras |
| Change unit/item/ability stats |
| Change text strings |
| Replace the script or any internal file |
| Create or edit real GUI triggers (visible in the Trigger Editor, survive saves) |
Tool | What it does |
| Make a custom unit/item/ability based on an existing one |
| Add game logic that runs immediately, survives editor re-saves, and shows up editable in the Trigger Editor |
Tool | What it does |
| Open the map in the Warcraft III World Editor |
| Launch the map in Warcraft III to play it |
Claude can read and edit the real GUI trigger tree — the same triggers you see in the Trigger Editor (F4).
"Change that trigger's ability from War Drums to Bash." "Create a GUI trigger that makes footmen kill grunts on their first attack."
Ask for a trigger…
…and it's a real trigger, right there in the Trigger Editor:
What to know:
Changes are written to the editor's own trigger data (war3map.wtg), so they show up in
the Trigger Editor and survive your saves.
Safe by design: before any write, the server proves it can rebuild your map's triggers byte-for-byte. If it can't, it refuses to touch them.
After a GUI change, open the map and Save once — that's when the editor compiles triggers into the playable script. Then playtest.
As with all edits: close the map in the editor first, reopen after.
Your originals are safe — edits save to a .edited copy unless you ask to overwrite.
Triggers / new logic: wc3_set_durable_script stores your JASS/Lua in war3map.wct (the
editor's own trigger storage) and mirrors it into the map script — so it runs immediately
and survives editor re-saves, appearing in the Trigger Editor where you can edit it later.
For an auto-running trigger, create one custom-text trigger in the editor first (e.g. name it
MCPDurable) and save once; the header slot (slot:"header") needs no setup.
Very large or protected maps may have a few parts that can't be read; Claude will tell you which part and keep working on the rest.
This is not affiliated with Blizzard Entertainment. Warcraft III is a trademark of Blizzard. This tool only reads/writes your own map files.
MIT — free and open source. Do whatever you like with it.
Add a predefined camera at target (x,y). Unspecified fields use World Editor defaults (distance 1650, aoa 304, fov 70, rotation 90). Usable from JASS as gg_cam_. Saves the map.
| Name | Required | Description | Default |
|---|---|---|---|
| mapPath | Yes | Absolute path to the .w3x/.w3m map file | |
| x | Yes | ||
| y | Yes | ||
| name | No | ||
| rotation | No | ||
| aoa | No | Angle of attack (degrees) | |
| distance | No | ||
| fov | No | Field of view (degrees) | |
| offsetZ | No | ||
| roll | No | ||
| outPath | No | Output map path. Defaults to "<map>.edited.<ext>" beside the source; pass the source path to overwrite in place. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Despite no annotations, the description reveals that unspecified fields use defaults, the camera is accessible via JASS, and the map is saved. However, it omits details about overwrite behavior, error handling, or permissions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is three concise sentences, each adding essential information: action, defaults, and side effects. No redundant text.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with 11 parameters, no output schema, and no annotations, the description provides basic context but lacks details on naming rules, coordinate system, and possible errors, making it moderately complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With only 36% schema coverage, the description clarifies the meaning of x, y, and provides defaults for distance, aoa, fov, and rotation. It does not explain other parameters like offsetZ, roll, or outPath beyond their names.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'Add' and the resource 'predefined camera at target (x,y)', distinguishing it from sibling tools like wc3_delete_camera and wc3_read_cameras.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
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 description implies usage for adding cameras but lacks conditions, prerequisites, or exclusion criteria.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Add a rectangular region defined by world-coordinate bounds (left/right/bottom/top). Returns the region with its assigned id (usable from JASS as gg_rct_). Saves the map.
| Name | Required | Description | Default |
|---|---|---|---|
| mapPath | Yes | Absolute path to the .w3x/.w3m map file | |
| left | Yes | ||
| right | Yes | ||
| bottom | Yes | ||
| top | Yes | ||
| name | No | ||
| weatherEffect | No | 4-char weather code, e.g. "RAhr"; omit for none | |
| ambientSound | No | ||
| color | No | [r,g,b] 0-255 editor tint | |
| outPath | No | Output map path. Defaults to "<map>.edited.<ext>" beside the source; pass the source path to overwrite in place. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description mentions the side effect 'Saves the map' but does not detail potential overwriting behavior (e.g., if outPath is not provided, it defaults to an edited file). With no annotations, the description carries the full burden but lacks depth on save behavior and safety.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences with no redundancy. First sentence states purpose and parameter semantics; second covers return value and side effect. Each sentence adds value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With 10 parameters, no output schema, and no annotations, the description should provide more context about parameters like weatherEffect, color, and outPath. It is insufficient for a tool of this complexity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 40%. The description adds meaning for left/right/bottom/top (world-coordinate bounds) and name (JASS usage) but ignores mapPath, weatherEffect, ambientSound, color, and outPath. It does not compensate for the low schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool adds a rectangular region with world-coordinate bounds and returns an assigned ID. It distinguishes from siblings like wc3_modify_region and wc3_delete_region by specifying 'add' and mentioning the return of a new region ID.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for adding new regions but does not explicitly state when to use this tool versus alternatives like wc3_modify_region or wc3_read_regions. No exclusions or prerequisites are mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Splice custom JASS/Lua into the map script and optionally wire it to run at map init. code is one or more complete function definitions; set entryFunction to the name of a zero-arg function in code to have it called during initialization. This is the reliable way to make the map DO something new in-game. Note: if the map has a GUI trigger tree and is re-saved in the World Editor, regenerated script may overwrite this; for pure custom-script maps it is fully durable. Saves the map.
| Name | Required | Description | Default |
|---|---|---|---|
| mapPath | Yes | Absolute path to the .w3x/.w3m map file | |
| code | Yes | Complete JASS/Lua function definition(s) to add | |
| entryFunction | No | Name of a zero-arg function in `code` to call at map init; omit to only append | |
| outPath | No | Output map path. Defaults to "<map>.edited.<ext>" beside the source; pass the source path to overwrite in place. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It discloses that the tool saves the map (a side effect), and notes the overwrite risk with GUI maps. However, it does not mention whether previous triggers are preserved, what happens on error, or any permission requirements. The behavioral detail is adequate but not exhaustive.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise: three sentences with no redundancy. The first sentence states the core action, the second explains key parameters, and the third adds a critical caveat. Every sentence earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description covers the main purpose and parameters, and warns about GUI maps. However, it does not describe the return value (e.g., success/failure message) or error handling. Given the tool's complexity (4 params, no output schema), a bit more detail about outcomes would improve completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
All four parameters are covered in the schema (100% coverage), but the description adds meaningful context: 'code' is 'complete function definitions', entryFunction must be a 'zero-arg function' name, and outPath defaults to a specific pattern. This enriches the schema beyond mere definitions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses specific verbs ('splice', 'wire', 'call') and clearly identifies the resource ('JASS/Lua into map script'). It distinguishes itself from sibling tools like wc3_write_script by focusing on incremental insertion with an optional entry point. The phrase 'reliable way to make the map DO something new in-game' reinforces its unique value.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explains when to use this tool (to add custom script and optionally run at init) and provides a caveat about GUI maps potentially overwriting changes. It implicitly contrasts with the full-script replacement sister tool wc3_write_script. However, it does not explicitly list alternatives or state exclusion criteria (e.g., 'don't use if you need to modify existing triggers').
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Create a custom object (unit/item/ability/buff/destructable/doodad/upgrade) derived from a base type, setting any fields. newId is a fresh 4-char code (e.g. "x000"); baseId is the 4-char code to copy (e.g. "hfoo"). fields are { id (4-char field code), type, value, level?, column? }. Saves the map.
| Name | Required | Description | Default |
|---|---|---|---|
| mapPath | Yes | Absolute path to the .w3x/.w3m map file | |
| kind | Yes | ||
| baseId | Yes | Base type to derive from, e.g. "hfoo" | |
| newId | Yes | New 4-char id for the custom object, e.g. "x000" | |
| fields | Yes | Field overrides for the new object | |
| outPath | No | Output map path. Defaults to "<map>.edited.<ext>" beside the source; pass the source path to overwrite in place. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden. It states 'Saves the map' but does not disclose mutation behavior (e.g., whether it modifies the input file or creates a new one by default), potential for errors, or permission requirements. The behavioral impact is under-explained.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences, front-loading the purpose and then providing key parameter details. It is efficient but could be slightly better structured (e.g., separating purpose from parameter examples).
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a 6-parameter tool with no output schema, the description covers the main action and parameter semantics but lacks details on error handling, return value, or what 'Saves the map' means precisely (e.g., in-place vs. new file). Completeness is adequate but not thorough.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is high (83%), and the description adds value by explaining the newId/baseId pattern with examples ('x000', 'hfoo') and detailing the fields array structure (id, type, value, optional level/column). This clarifies usage beyond the schema descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it creates a custom object derived from a base type, listing all possible kinds (unit/item/ability/buff/destructable/doodad/upgrade). This differentiates it from sibling tools like wc3_place_unit (placement on map) or wc3_write_objects (bulk writing).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for creating new object definitions from base types, but it does not explicitly state when to use this tool versus alternatives like wc3_place_unit (for placing units) or wc3_write_objects (for bulk updates). No exclusions or prerequisites are provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Remove the camera(s) matched by name or index. Saves the map.
| Name | Required | Description | Default |
|---|---|---|---|
| mapPath | Yes | Absolute path to the .w3x/.w3m map file | |
| select | Yes | Which camera(s) to delete — provide name or index | |
| outPath | No | Output map path. Defaults to "<map>.edited.<ext>" beside the source; pass the source path to overwrite in place. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden. It states 'Saves the map' but omits other behavioral traits like irreversibility, write permissions needed, or that existing cameras may be required. The destructive nature is implied but not fully disclosed.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, 12 words, front-loaded purpose, no wasted information. Highly concise and clear.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a mutation tool with no output schema and no annotations, the description lacks important context: it doesn't mention irreversibility, validation of mapPath, or that the tool modifies the file. The agent may not have enough information to use it safely.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the description adds little beyond what is already in the schema. It confirms selection by name or index but does not clarify behavior if both are provided. Adequate but not enhancing.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb 'Remove' and resource 'camera', and defines matching criteria (name or index). It distinguishes from sibling tools like wc3_add_camera and wc3_read_cameras effectively.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
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 vs alternatives (e.g., wc3_read_cameras for viewing, wc3_add_camera for adding). No usage context or prerequisites are given.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Remove the doodad(s) matched by editorId, index, or type. Saves the map.
| Name | Required | Description | Default |
|---|---|---|---|
| mapPath | Yes | Absolute path to the .w3x/.w3m map file | |
| select | Yes | Which doodad(s) — provide one of editorId/index/type | |
| outPath | No | Output map path. Defaults to "<map>.edited.<ext>" beside the source; pass the source path to overwrite in place. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Without annotations, the description carries full burden. It states 'Saves the map' but does not disclose irreversibility, error handling, or behavior when no doodad matches. No mention of return format or side effects beyond saving.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two concise sentences with no redundant words. The action and criteria are front-loaded, making it easy to scan.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite low complexity, the description lacks detail on return values, error conditions, selection behavior when multiple doodads match, and prerequisites. A more complete description would include these for a destructive tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the description adds minimal value beyond restating the select parameter's purpose. It does not clarify constraints like the nested object structure or default behavior for outPath, but the schema covers that.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action (Remove), the resource (doodad(s)), and the matching criteria (editorId, index, or type). It distinguishes from siblings like wc3_modify_doodad and wc3_delete_unit, and includes a side effect (saves the map).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
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 over alternatives like wc3_modify_doodad or wc3_place_doodad. The description implies usage for deletion but does not state when not to use it or mention prerequisites.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Remove the region(s) matched by id, name, or index. Saves the map.
| Name | Required | Description | Default |
|---|---|---|---|
| mapPath | Yes | Absolute path to the .w3x/.w3m map file | |
| select | Yes | Which region(s) to delete — provide one of id/name/index | |
| outPath | No | Output map path. Defaults to "<map>.edited.<ext>" beside the source; pass the source path to overwrite in place. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It mentions that the tool saves the map (side effect) but does not disclose permissions, return value, or behavior when no match is found. Minimal transparency beyond the basic action.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two concise sentences front-loaded with verb and resource. Every word is necessary; no redundancy or filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has no output schema and no annotations. The description is adequate but leaves ambiguity about whether multiple regions can be deleted simultaneously (the select object allows only one criterion). Lacks details on outPath behavior (handled by schema) and return value.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so parameters are already documented. The description adds the behavioral note 'Saves the map' but does not enhance understanding of parameters beyond what the schema provides. Baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states the tool removes regions matched by id, name, or index, and it distinguishes from related sibling tools like wc3_modify_region (modify) and wc3_add_region (add).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for deleting regions but does not explicitly state when to use this tool versus alternatives like wc3_modify_region or wc3_delete_camera. No when-not or conditional guidance is provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Remove the unit(s) matched by select from war3mapUnits.doo. Saves to outPath, or ".edited." beside the source (pass the source path to overwrite in place).
| Name | Required | Description | Default |
|---|---|---|---|
| mapPath | Yes | Absolute path to the source .w3x/.w3m map file | |
| select | Yes | Which unit(s) to target — provide at least one field; `type` can match many | |
| outPath | No | Output map path. Defaults to "<map>.edited.<ext>". |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Without annotations, the description carries full burden. It discloses that units are removed from war3mapUnits.doo and saved to outPath or a default. However, it lacks details on side effects (e.g., irreversibility) and prerequisites (e.g., map must exist).
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences with no waste. The purpose is front-loaded, and each sentence adds essential information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with 3 parameters and no output schema, the description is fairly complete. It explains the deletion target, saving behavior, and override option. Minor gaps: no mention of irreversibility or error conditions.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema covers all parameters, and the description adds value by explaining the select object's usage ('provide at least one field; `type` can match many') and the default behavior for outPath. This exceeds the baseline of 3.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Remove the unit(s) matched by `select` from war3mapUnits.doo', providing a specific verb and resource. It distinguishes from sibling tools like wc3_delete_doodad by specifying units.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for deleting units but does not explicitly state when to use this tool versus alternatives or provide exclusions. The context from sibling tools and name provides some guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List preplaced doodads/destructables in war3map.doo with index, editorId, type code, position, angle, scale, variation, life. Optionally filter by type. Use index/editorId with wc3_modify_doodad / wc3_delete_doodad.
| Name | Required | Description | Default |
|---|---|---|---|
| mapPath | Yes | Absolute path to the .w3x/.w3m map file | |
| type | No | Only list this 4-char type code |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden. It discloses the tool lists preplaced doodads without mutation. It could mention read-only nature and error handling, but the listed output fields provide good transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences efficiently cover purpose, output, and follow-up actions. No fluff, each sentence earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema, the description lists all returned fields (index, editorId, type code, etc.), making it complete enough for a listing tool. It could explicitly mention the output format (e.g., list of objects), but the listed fields suffice.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, but the description adds meaning by explaining the 'type' parameter is a 4-char type code and listing the output fields, which aids agent understanding beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool lists preplaced doodads/destructables with specific attributes and optional filtering. It distinguishes from siblings like wc3_list_units by specifying the resource (war3map.doo) and attributes.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly tells the agent to use the returned index/editorId with wc3_modify_doodad or wc3_delete_doodad, providing clear integration context. It doesn't explicitly state when not to use, but the use case is implied.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List the internal files inside a Warcraft III .w3x/.w3m map archive.
| Name | Required | Description | Default |
|---|---|---|---|
| mapPath | Yes | Absolute path to the .w3x/.w3m map file |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations exist, so the description must carry the full burden. 'List' implies read-only behavior, and no destructive action is mentioned. However, it does not explicitly state that the tool does not modify the map or any other behavioral traits such as permissions or 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.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, concise sentence that conveys the tool's purpose without unnecessary words. It is front-loaded with the essential information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has no output schema, yet the description does not specify the format or structure of the returned list (e.g., full paths, file names, sizes). For a listing operation, this information is crucial for the agent to process the result correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% for the single parameter 'mapPath', which is thoroughly described in the schema. The tool description adds no additional meaning beyond what the schema already provides, so the baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'List the internal files inside a Warcraft III .w3x/.w3m map archive' using a specific verb and resource, and the tool name 'wc3_list_files' aligns perfectly. It distinguishes from siblings like 'wc3_read_file' which operate on individual files.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description does not explicitly guide when to use this tool vs alternatives. A user can infer it is for listing all files before reading specific ones, but no when-not-to-use 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.
List the preplaced units and items in war3mapUnits.doo with their index, creationNumber, type code, owner, position and facing. Use the index/creationNumber with wc3_modify_unit or wc3_delete_unit.
| Name | Required | Description | Default |
|---|---|---|---|
| mapPath | Yes | Absolute path to the .w3x/.w3m map file |
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 describes what the tool returns but does not explicitly state that it is read-only or non-destructive. For a simple list tool, the omission is minor, but ideally it would clarify there are no 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.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise, consisting of two sentences. The first sentence states the purpose and the second provides usage guidance. No extraneous information, perfectly front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple list tool with one parameter and no output schema, the description is remarkably complete. It specifies the exact file, the fields returned, and how to use the results with other tools. No additional information is needed for effective use.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
There is only one required parameter (mapPath) with a clear schema description. The description does not add additional meaning beyond what the schema already provides. With 100% schema coverage, the baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool lists preplaced units and items from war3mapUnits.doo, listing specific fields (index, creationNumber, type code, owner, position, facing). It distinguishes itself from sibling tools like wc3_list_doodads and references related tools wc3_modify_unit and wc3_delete_unit.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly tells the user to use the returned index/creationNumber with wc3_modify_unit or wc3_delete_unit, providing clear chaining guidance. It does not explicitly state when not to use this tool, but for a list operation, the context is clear enough.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Parse war3map.w3i: map name, author, description, players, playable area, script language, flags, etc.
| Name | Required | Description | Default |
|---|---|---|---|
| mapPath | Yes | Absolute path to the .w3x/.w3m map file |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description should disclose behavioral traits. It states the tool parses a specific file and lists returned data, but does not mention error conditions (e.g., invalid file), read-only nature, or format of output. Basic transparency is achieved but lacks depth.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence that directly conveys the action and the key outputs. No extraneous words; it is optimally concise for the complexity of the tool.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given one parameter, no output schema, and no annotations, the description adequately covers the tool's purpose and outputs. It lacks details on output format and error handling, but for a simple read-only tool, it provides sufficient context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% for mapPath, so baseline is 3. The description adds meaning by explaining that the tool extracts metadata from war3map.w3i, giving context to what the single parameter leads to. This goes beyond the schema's path description.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: to parse the war3map.w3i file and extract specific metadata fields like map name, author, description, etc. It uses the specific verb 'Parse' and identifies the exact resource, making it distinct from siblings like wc3_read_file.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
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 such as wc3_read_file or wc3_read_objects. There is no mention of prerequisites, context, or exclusions, leaving the agent without decision support.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Change fields on the doodad(s) matched by editorId, index, or type. Saves the map.
| Name | Required | Description | Default |
|---|---|---|---|
| mapPath | Yes | Absolute path to the .w3x/.w3m map file | |
| select | Yes | Which doodad(s) — provide one of editorId/index/type (type can match many) | |
| set | Yes | Fields to change on every matched doodad | |
| outPath | No | Output map path. Defaults to "<map>.edited.<ext>" beside the source; pass the source path to overwrite in place. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description must fully disclose behavioral traits. It only states that the tool 'Saves the map,' which is important for a mutation tool, but it does not mention potential side effects (e.g., overwriting backups, required permissions, error handling when doodads are not found, or concurrency issues). This is insufficient for an agent to fully understand the tool's impact.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence of 14 words that front-loads the action and key matching criteria. Every word earns its place, and there is no redundancy or filler. Ideal conciseness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has 4 parameters, nested objects, and 100% schema coverage, but no output schema. The description does not mention what the tool returns (if anything) or how the agent should expect the result (e.g., confirmation message, error on failure). For a mutation tool with side effects, this gap in completeness is noticeable.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already documents each parameter. The description adds a brief summary linking select criteria to action but does not explain the meaning of individual fields in the 'set' object (e.g., x, y, z, angle, scale, variation, life). Baseline is 3, and the description provides marginal extra value.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Change fields') and the resource ('doodad(s)'), and specifies the matching criteria (editorId, index, or type). It also notes the map-saving side effect, all in one concise sentence. This distinguishes it from sibling tools like wc3_delete_doodad or wc3_place_doodad.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for modifying existing doodads but provides no explicit guidance on when to use this tool versus alternatives (e.g., deleting and re-placing, or using wc3_write_objects). No exclusions or prerequisites are mentioned, leaving the agent to infer context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Change bounds/name/weather/sound/color on the region(s) matched by id, name, or index. Saves the map.
| Name | Required | Description | Default |
|---|---|---|---|
| mapPath | Yes | Absolute path to the .w3x/.w3m map file | |
| select | Yes | Which region(s) to change — provide one of id/name/index | |
| set | Yes | Fields to change | |
| outPath | No | Output map path. Defaults to "<map>.edited.<ext>" beside the source; pass the source path to overwrite in place. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Without annotations, the description correctly notes that the tool saves the map, a key behavioral trait. However, it does not disclose potential side effects like irreversible changes or permission needs, leaving gaps for a mutation tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences, front-loads the core action, and contains no unnecessary words. Every part contributes to understanding.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
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 is adequate but minimal. It covers the main purpose and mentions saving but lacks details on error handling, multi-region behavior, or value constraints beyond the schema.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so baseline is 3. The description enumerates the modifiable fields and selection criteria but adds little beyond what the schema already describes for each parameter.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it modifies region properties (bounds, name, weather, sound, color) and saves the map, distinguishing it from sibling tools like add_region, delete_region, and list_regions.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explains what the tool does but does not explicitly state when to use it versus alternatives or mention prerequisites like map path validity. It implies usage for modifying existing regions but lacks direct guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Change fields on the unit(s) matched by select — move them, re-own them, rescale, re-face, swap type, or set HP/mana. Saves to outPath, or ".edited." beside the source (pass the source path to overwrite in place).
| Name | Required | Description | Default |
|---|---|---|---|
| mapPath | Yes | Absolute path to the source .w3x/.w3m map file | |
| select | Yes | Which unit(s) to target — provide at least one field; `type` can match many | |
| set | Yes | Fields to change on every matched unit | |
| outPath | No | Output map path. Defaults to "<map>.edited.<ext>". |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Discloses output behavior (saves to outPath or default edited file, can overwrite in place). No annotations exist, so description carries full burden. Could mention error handling or irreversible changes, but current text is adequate.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, first covers purpose and operations, second covers output. Front-loaded, no wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Description covers main behavior and output. With no output schema, a note on return value would help. Missing edge cases or error conditions, but overall sufficient for the tool's complexity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, baseline 3. Description adds value by summarizing the types of changes (move, re-own, etc.) beyond the schema's per-field descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it modifies placed units with specific operations (move, re-own, rescale, etc.). It distinguishes from siblings like wc3_modify_doodad and wc3_delete_unit by focusing on unit fields.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Usage is implied (modify existing units), but no explicit when-to-use or when-not-to-use compared to alternatives like wc3_place_unit or wc3_delete_unit. No context for prerequisites.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Launch the Warcraft III World Editor on the given map so the user can see/verify the edits. (The World Editor has no automation API; this just opens the edited file.) Pass exePath to override auto-detection.
| Name | Required | Description | Default |
|---|---|---|---|
| mapPath | Yes | Absolute path to the .w3x/.w3m map file | |
| exePath | No | Path to World Editor.exe |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Discloses no automation API and that it merely opens the file. Missing details on system requirements (Warcraft III must be installed), error handling if map or exe not found, and side effects (launches external process).
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two efficient sentences. Front-loaded with action and purpose, followed by contextual caveat and parameter guidance. No fluff.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
No output schema. Adequate for a launch tool but could mention prerequisites (map existence, editor installation) and post-launch behavior. Missing how to verify success or failure.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema covers both parameters. Description adds value by explaining exePath overrides auto-detection, which is not obvious from schema alone.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Clear verb 'Launch', specific resource 'Warcraft III World Editor', and purpose 'so the user can see/verify the edits'. Distinguishes from siblings like wc3_test_map (test in game) and other editing tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Implies use for visual verification but no explicit when-not-to-use or comparison with alternatives like wc3_test_map. Only guidance is 'pass exePath to override auto-detection'.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
One-call snapshot of the map: info (name/author/players), file count, script language, terrain summary, placed unit/doodad counts, custom-object counts, and the names of regions/cameras/sounds plus a trigger summary. Use this first to orient on an unfamiliar map.
| Name | Required | Description | Default |
|---|---|---|---|
| mapPath | Yes | Absolute path to the .w3x/.w3m map file |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description must convey behavior. It describes the tool as a read-only snapshot, implying no side effects, but does not explicitly state that it does not modify the map or any requirements (e.g., map must exist). The description gives a good sense of output but lacks explicit behavioral guarantees.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise, consisting of two sentences. The first sentence efficiently lists the output categories in a structured manner, and the second provides usage guidance. Every sentence adds value without redundancy. Minor improvement could be formatting with line breaks for readability, but it's largely effective.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's purpose as a high-level overview and the absence of an output schema, the description adequately explains what the tool returns by listing ten distinct categories of information. This coverage allows an agent to understand the tool's scope and decide if it fits the context. It complements the more granular sibling tools.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema provides complete documentation for the single parameter (mapPath) with 100% coverage. The tool description does not add additional semantic detail beyond what the schema already states, so it meets the baseline for a well-documented parameter. No further explanation is needed.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The tool name and description immediately convey it provides a comprehensive map overview. The phrase 'One-call snapshot' and the detailed list of included data (info, file count, script language, terrain, placements, custom objects, regions, cameras, sounds, triggers) clearly define the tool's purpose. It distinguishes itself from sibling tools that focus on individual aspects or modifications.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The explicit instruction 'Use this first to orient on an unfamiliar map' provides clear guidance on when to use this tool. It implies that more specific tools should follow this initial overview, though it doesn't explicitly state when not to use it or suggest alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Add a doodad/destructable at (x,y). Type is a 4-char code, e.g. "LTlt" (a tree) or "ATtr" (a rock). Saves the map.
| Name | Required | Description | Default |
|---|---|---|---|
| mapPath | Yes | Absolute path to the .w3x/.w3m map file | |
| type | Yes | 4-char doodad/destructable code | |
| x | Yes | ||
| y | Yes | ||
| z | No | ||
| angle | No | Facing in degrees; default 270 | |
| scale | No | ||
| variation | No | ||
| life | No | Life as a percent; default 100 | |
| outPath | No | Output map path. Defaults to "<map>.edited.<ext>" beside the source; pass the source path to overwrite in place. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description bears full responsibility for behavioral disclosure. It only states 'saves the map' but omits important traits like whether placement overwrites existing doodads, validates type codes, or requires the map to be loaded. This is insufficient for a mutation tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise: two short sentences that immediately convey the action and key details. No filler, every word earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has 10 parameters, no output schema, and no annotations, the description is too sparse. It lacks critical context such as behavior when z or scale are omitted, the effect of variation and life, or whether the map is saved synchronously. An agent would need more detail to use this tool confidently.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 50% (5 of 10 parameters described). The description adds examples for the 'type' parameter and clarifies that x,y are coordinates, but does not explain z, scale, variation, or angle beyond the schema. It provides moderate added value, meeting the baseline for this coverage level.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool adds a doodad/destructable at coordinates (x,y), provides example type codes 'LTlt' and 'ATtr', and notes it saves the map. This distinguishes it from sibling tools like wc3_place_unit and wc3_delete_doodad.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description offers no explicit guidance on when to use this tool versus alternatives like wc3_place_unit or wc3_modify_doodad. No conditions, prerequisites, or exclusions are mentioned, leaving the agent to infer usage context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Add a preplaced unit or item to the map at world coordinates (x, y). The type is a 4-char raw code, e.g. "ugho" (Ghoul), "hfoo" (Footman), or an item code. Saves to outPath, or ".edited." beside the source (pass the source path to overwrite in place).
| Name | Required | Description | Default |
|---|---|---|---|
| mapPath | Yes | Absolute path to the source .w3x/.w3m map file | |
| type | Yes | 4-char unit/item type code, e.g. "ugho" | |
| x | Yes | World X coordinate | |
| y | Yes | World Y coordinate | |
| z | No | World Z (height); default 0 | |
| facing | No | Facing angle in degrees; default 270 | |
| player | No | Owner: 0-based player slot (0 = Player 1/Red). Default 0 | |
| scale | No | Uniform scale; default 1 | |
| variation | No | Model variation; default 0 | |
| hitpointsPercent | No | HP as a percent, or -1 for default | |
| manaPercent | No | Mana as a percent, or -1 for default | |
| skin | No | Reforged skin code; defaults to `type` | |
| outPath | No | Output map path. Defaults to "<map>.edited.<ext>". |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Given no annotations, the description fairly conveys the tool is additive and outputs to a path, with overwrite behavior. Does not detail side effects like map modification limits or permissions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, no redundancy, efficiently communicates core function and key parameter details.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Adequate for a tool with many parameters; schema fills details. Could mention typical use cases or prerequisites like map file existence, but overall sufficient.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, baseline is 3. Description adds value by explaining type code format and outPath overwrite, but does not elaborate on other parameters like z, facing, or player.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it adds a preplaced unit/item to a map at coordinates, with examples of type codes ('ugho', 'hfoo'), distinguishing it from siblings like wc3_place_doodad or wc3_create_object.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides usage note on overwriting source path and default output path, but lacks explicit guidance on when to use this tool over alternatives like wc3_modify_unit or wc3_create_object.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List predefined cameras (war3map.w3c) — name, target, rotation, angle of attack, distance, fov, etc.
| Name | Required | Description | Default |
|---|---|---|---|
| mapPath | Yes | Absolute path to the .w3x/.w3m map file |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. It implies read-only behavior by stating 'List', but does not disclose potential error conditions, permissions, or that it returns a list. Adequate for a simple read tool but could be more explicit.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
One concise sentence with no wasted words, front-loaded with the key action and data fields.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple read tool with one parameter and no output schema, the description is complete: it specifies what is read and what fields are included. Could mention the return format, but not essential.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the description adds no parameter information beyond what the schema already provides. The description does not mention the mapPath parameter, but the schema's description is sufficient.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool lists predefined cameras from a specific file and enumerates the data fields (name, target, rotation, etc.), distinguishing it from sibling tools like wc3_add_camera or wc3_delete_camera.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
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, though the purpose is clear from context and sibling names. A brief note about when to read vs. add/delete cameras would improve this dimension.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Extract one internal file as text (utf8) or base64.
| Name | Required | Description | Default |
|---|---|---|---|
| mapPath | Yes | Absolute path to the .w3x/.w3m map file | |
| internalName | Yes | Internal archive path, e.g. "war3map.w3i" | |
| encoding | No | How to return the bytes | base64 |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description should disclose behavioral traits. It does not state that this is a read-only operation, nor does it mention any side effects, error conditions, or limitations. The only behavior mentioned is the encoding format.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
A single sentence that is efficiently front-loaded with the verb 'Extract' and the resource 'internal file'. Every word is necessary; no wasted text.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
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 is too minimal. It does not explain what happens on success/failure, the format of the output (e.g., base64 string or decoded text), or constraints like file size. For a file-reading tool, this lacks essential context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 100% description coverage, so the schema already documents each parameter. The description adds only that the output is text (utf8) or base64, which aligns with the encoding enum. This is baseline value; no extra semantic depth beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it extracts one internal file as text or base64, which conveys the core action. The tool name 'wc3_read_file' matches, and it is distinct from siblings like 'wc3_list_files' which lists files, but no explicit differentiation is given.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
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. With many sibling tools for reading different aspects (script, strings, terrain, etc.), the description does not help the agent choose correctly.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List custom imported files declared in war3map.imp (models, textures, sounds, …). Their bytes are reachable via wc3_read_file / wc3_replace_file.
| Name | Required | Description | Default |
|---|---|---|---|
| mapPath | Yes | Absolute path to the .w3x/.w3m map file |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so the description must cover behavioral traits. It indicates read-only listing behavior but does not disclose error cases, performance implications, or permission requirements. The mention of 'custom imported files' implies non-destructive, but more detail is needed.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences, front-loaded with purpose and a useful follow-up on related tools. Every sentence adds value, no fluff.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema, the description could clarify the output format (e.g., list of file paths or names). It mentions 'list' and references related tools, which partially compensates. However, the output nature is ambiguous, leaving a minor gap.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 100% coverage with a single parameter 'mapPath' fully described. The description adds no extra meaning beyond the schema, meeting the baseline expectation but not exceeding it.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool lists custom imported files from war3map.imp, specifying types like models, textures, sounds. It distinguishes from siblings by mentioning file bytes are accessible via wc3_read_file/wc3_replace_file, implying this tool is for listing only.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description informs that imported file bytes are reachable via wc3_read_file/wc3_replace_file, guiding the agent to use those tools after listing. However, it does not explicitly state when not to use this tool or list alternative tools beyond the referenced ones.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Read an object-data table as JSON. "kind" is one of units/items/abilities/buffs/destructables/doodads/upgrades. Returns a { original, custom } modification table.
| Name | Required | Description | Default |
|---|---|---|---|
| mapPath | Yes | Absolute path to the .w3x/.w3m map file | |
| kind | Yes | Which object-data table to read |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden. It discloses the return format as '{ original, custom } modification table', which is helpful. However, it does not mention side effects (likely none), error conditions, or any required permissions. For a read operation, this is adequate but not exhaustive.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise with two sentences. The first sentence states the core purpose, and the second clarifies the 'kind' parameter and return format. No extraneous information, and the structure is front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has only 2 parameters and no output schema, the description is fairly complete. It explains what data is read and the return structure. Missing are details like supported file formats (though schema mentions .w3x/.w3m) and whether the operation is safe for simultaneous access. Overall, it is sufficient for a simple read tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so baseline is 3. The description adds minimal value beyond the schema: it repeats the enum values for 'kind' but provides no additional context for 'mapPath' (e.g., file existence requirements). The description does not compensate for any gaps.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Read an object-data table as JSON', specifying the verb and resource. It also enumerates the valid values for the 'kind' parameter (units/items/abilities/buffs/destructables/doodads/upgrades), making the tool's scope unambiguous and distinct from sibling tools like wc3_read_placements.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no explicit guidance on when to use this tool over alternatives or any exclusions. While the purpose is clear, it does not mention situations where this tool should not be used or contrast it with similar reading tools like wc3_read_script or wc3_read_terrain.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Read what is placed on the map in the World Editor: preplaced units/items (war3mapUnits.doo) and doodads/destructables (war3map.doo). Returns { units: [...], doodads: [...] } with type code, position, angle, owner, etc.
| Name | Required | Description | Default |
|---|---|---|---|
| mapPath | Yes | Absolute path to the .w3x/.w3m map file |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden. It discloses the return format and references specific file names (war3mapUnits.doo, war3map.doo), providing good behavioral context. It does not mention error handling or performance, but these are not critical.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences with no fluff: the first states the purpose, the second details the return structure. Every word earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given a single parameter and no output schema, the description adequately explains what is read and the return format. Could mention potential errors or map size limits, but not required for typical use.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 100% coverage with a clear description for mapPath. The tool description does not add additional meaning beyond the schema, so baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb 'Read' and identifies the resource as 'placed units & doodads', clearly distinguishing it from sibling tools like wc3_list_units or wc3_list_doodads by mentioning both combined.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies use when inspecting preplaced map objects, but does not explicitly mention when to use this versus sibling read tools like wc3_list_units or wc3_list_doodads, leaving some ambiguity.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List the rectangular regions (war3map.w3r) — name, id, rect bounds, weather, ambient sound, color.
| Name | Required | Description | Default |
|---|---|---|---|
| mapPath | Yes | Absolute path to the .w3x/.w3m map file |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full responsibility for behavioral disclosure. It correctly implies a read-only operation ('list'), but fails to mention any prerequisites, side effects, or response characteristics beyond the listed fields.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence that efficiently conveys the tool's purpose and the data it returns. It is slightly dense but not wasteful.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
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 output schema), the description adequately covers what the tool does and what information it produces. It is complete enough for an experienced user.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema fully describes the single required parameter (mapPath) with 100% coverage. The description adds no additional semantic value for that parameter, so a baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool lists rectangular regions and enumerates the fields returned (name, id, rect bounds, weather, ambient sound, color). This distinguishes it from sibling tools like wc3_add_region or wc3_modify_region, but does not explicitly emphasize the read-only nature.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
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 alternatives. There are many sibling tools for reading other map components, but the description offers no context for choosing this particular one.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Read the map script (war3map.j JASS or war3map.lua).
| Name | Required | Description | Default |
|---|---|---|---|
| mapPath | Yes | Absolute path to the .w3x/.w3m map file |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It only says 'Read' but does not mention return format, size limits, error handling, or whether the operation is safe. The agent has no insight into what happens when reading the script.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single short sentence with no wasted words. However, it could be slightly more informative without losing conciseness, potentially including output details.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite the simplicity of the tool (one parameter, no output schema), the description lacks essential context such as what the tool returns (the script content) or any error conditions. It is not fully complete for an agent to use without additional assumptions.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% for the single parameter 'mapPath'. The tool description does not add any additional meaning beyond the schema; it simply restates the action. Baseline 3 is appropriate as the schema already documents the parameter sufficiently.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action (Read) and the resource (map script), and specifies the script files (war3map.j JASS or war3map.lua). It distinguishes from siblings like wc3_read_file and wc3_read_triggers by targeting the main script file.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
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 vs alternatives such as wc3_read_file for general files or wc3_read_triggers for triggers. No context on prerequisites or conditions is given.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List sound definitions (war3map.w3s) — variable name, file path, and playback settings.
| Name | Required | Description | Default |
|---|---|---|---|
| mapPath | Yes | Absolute path to the .w3x/.w3m map file |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Without annotations, the description carries the full burden. It discloses the read-only nature, the file accessed, and the specific information returned. However, it does not mention behavior on missing files or error handling, which would improve transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence that is front-loaded with the action and resource. No irrelevant information, and every word is necessary.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple read tool with one required parameter and no output schema, the description covers the essential information: what file, what data fields. It is sufficient for an agent to understand the tool's purpose and output.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 100% coverage with a clear parameter description. The tool description adds no additional meaning beyond the schema, so the baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description explicitly states it lists sound definitions from war3map.w3s, specifying the included fields (variable name, file path, playback settings). This clearly distinguishes it from sibling read tools like wc3_read_cameras or wc3_read_objects.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit when-to-use or when-not-to-use guidance is given. The implication is to use this tool when you need to read sound definitions, but no alternatives or exclusions are mentioned. For a straightforward read tool, this is adequate but not exceptional.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Read war3map.wts as a { id: text } map. Many map fields are stored as TRIGSTR_### references into this table (map/unit names, quest text, tooltips, …).
| Name | Required | Description | Default |
|---|---|---|---|
| mapPath | Yes | Absolute path to the .w3x/.w3m map file |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It correctly indicates a read operation and describes the output format. It does not mention any destructive behavior, rate limits, or authentication needs, but for a simple read tool, the transparency is adequate.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise: two sentences, no wasted words. It front-loads the purpose and immediately provides valuable context about TRIGSTR references.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
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 output schema, no annotations), the description covers the purpose and output format adequately. It explains why the tool exists (resolving TRIGSTR references), though it could detail the return structure slightly more.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% (one parameter documented in schema). The description does not add additional parameter meaning beyond the schema's 'Absolute path to the map file', so baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool reads war3map.wts and returns a map of id to text, distinguishing it from siblings like wc3_set_string which writes. It also explains the context of TRIGSTR references, making the purpose specific and clear.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
While the description implies usage for resolving TRIGSTR references, it does not explicitly state when to use this tool instead of alternatives, nor does it provide any 'when not to use' guidance. Lacks explicit exclusions 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.
Summarize war3map.w3e: tileset, ground/cliff tileset list, tilepoint dimensions, world size, and height/water ranges.
| Name | Required | Description | Default |
|---|---|---|---|
| mapPath | Yes | Absolute path to the .w3x/.w3m map file |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The name and description indicate a read-only operation ('read', 'summarize'), so no destructive hint needed. No annotations exist, but the description effectively communicates safety. Could add detail on permissions or map path requirements, but not critical.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Single sentence, front-loaded with 'summarize', no wasted words. Each element listed is essential for understanding output.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Lists specific output attributes, which is adequate for a summarization tool without an output schema. Could mention that the map file must be valid, but the required parameter implies that.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema has 100% description coverage for the single parameter (mapPath). The description does not add further parameter detail, but the baseline is appropriate since the schema already documents it.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it summarizes the war3map.w3e terrain file and lists specific attributes (tileset, ground/cliff tileset list, tilepoint dimensions, world size, height/water ranges). This distinguishes it from sibling read tools that target other files.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies it should be used for reading terrain data, and sibling tools cover other resources (cameras, regions, etc.), providing clear context. No explicit when-not-to-use or alternative guidance, but the context is sufficient for differentiation.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Inspect the GUI trigger tree (war3map.wtg): categories, variables, and per-trigger metadata (name, enabled, comment, action count). GUI triggers compile to the map script — to change behavior reliably, edit the script (wc3_add_trigger).
| Name | Required | Description | Default |
|---|---|---|---|
| mapPath | Yes | Absolute path to the .w3x/.w3m map file |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Without annotations, the description carries the burden of behavioral disclosure. It implies read-only through 'inspect' and contrasts with editing via wc3_add_trigger, but does not explicitly state it has no side effects. However, the language is clear enough that an agent would understand it is a read operation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description consists of two concise sentences. The first explains the tool's function and what it reads, and the second provides usage guidance. No unnecessary words or redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the simplicity of the tool (1 param, no output schema), the description is mostly complete. It explains the internal file, the kind of data returned, and the relationship to scripting. However, it does not describe the output format or structure, which might leave slight ambiguity for an agent expecting a specific JSON shape.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema already provides a full description for the single parameter mapPath ('Absolute path to the .w3x/.w3m map file'), covering 100% of parameters. The description adds no additional parameter-level information, so the baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it inspects the GUI trigger tree and lists the specific metadata it reads (categories, variables, per-trigger name, enabled, comment, action count). It uses a specific verb 'inspect' and resource 'trigger tree', distinguishing it from siblings like wc3_read_script (reads script) and wc3_add_trigger (edits script).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly states when to use this tool vs. alternatives: 'GUI triggers compile to the map script — to change behavior reliably, edit the script (wc3_add_trigger).' This provides clear guidance that this tool is for inspection only, while wc3_add_trigger is for modifications.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Replace (or add) an internal file from a file on disk, then save. Useful for swapping models/textures/imports.
| Name | Required | Description | Default |
|---|---|---|---|
| mapPath | Yes | Absolute path to the source .w3x/.w3m map file | |
| internalName | Yes | Internal archive path to write, e.g. "war3map.j" | |
| srcPath | Yes | Path to the file on disk whose bytes will be written | |
| outPath | No | Output map path. Defaults to "<map>.edited.w3x". |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full weight. It states the basic operation (replace/add from disk and save) but omits critical behavioral details such as whether existing files are overwritten, handling of missing paths, side effects on map integrity, or any authentication/permission requirements.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise with two short sentences that convey the core purpose. Every word is meaningful, and the structure front-loads the action and primary use case.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description is incomplete for a 4-parameter mutation tool. It fails to explain default behavior for outPath, error conditions (e.g., if mapPath does not exist), confirmation of success, or any side effects on the map file. The absence of an output schema increases the need for such detail.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with all four parameters having descriptions. The description adds minimal extra context by framing the operation as 'replace or add' and mentioning the use case, but does not explain defaults (e.g., outPath default) or format constraints beyond the schema. Baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action (replace or add) and the resource (internal file in a WC3 map). It explicitly mentions the use case of swapping models/textures/imports, which distinguishes it from reading-oriented siblings like wc3_read_file.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives a vague usage hint ('useful for swapping models/textures/imports') but does not specify when to avoid this tool or mention alternative tools. No explicit guidance on prerequisites or when not to use.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Set the text of a TRIGSTR entry by numeric id (the ### in TRIGSTR_###), or omit id to append a new entry and get back its TRIGSTR_### token. Saves the map.
| Name | Required | Description | Default |
|---|---|---|---|
| mapPath | Yes | Absolute path to the .w3x/.w3m map file | |
| id | No | TRIGSTR numeric id to overwrite; omit to append a new one | |
| value | Yes | The text to store | |
| outPath | No | Output map path. Defaults to "<map>.edited.<ext>" beside the source; pass the source path to overwrite in place. |
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: saving the map and the two modes of operation (update vs append with token return). However, it lacks details on side effects, permissions, or error conditions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two concise sentences with no extraneous information. The first sentence front-loads the action and key detail about id.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description covers the main functionality and modes. However, it does not describe the return value for updates (only for append), and lacks details about output path defaults and potential errors. Still, it is fairly complete for a tool with no output schema.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so baseline is 3. The description adds value by explaining that omitting 'id' appends a new entry and returns a token, which is beyond the schema's description. This justifies a score of 4.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'set', the resource 'TRIGSTR entry', and explains both updating by numeric id and appending. It distinguishes from sibling tools that read or modify other map components.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context on when to use the tool (to modify string-table entries) but does not explicitly mention when not to use it or compare with alternatives. Sibling tools are listed but not contrasted.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Launch Warcraft III running the given map (windowed by default) so the change can be played immediately. Pass exePath to override auto-detection, or windowed=false for fullscreen.
| Name | Required | Description | Default |
|---|---|---|---|
| mapPath | Yes | Absolute path to the .w3x/.w3m map file | |
| exePath | No | Path to Warcraft III.exe | |
| windowed | No | Run windowed (default true) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must fully disclose behavior. It fails to mention whether the tool blocks until the game closes, what happens if Warcraft III is already running, or error handling (e.g., missing exe). This omission is significant for a launch command.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences containing all essential information without extraneous text. Each sentence earns its place: first states the main action, second clarifies parameter usage.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with 3 parameters and no output schema, the description explains the primary function and two optional parameters. However, it lacks important behavioral context (blocking, error conditions) that would be needed for safe invocation, leaving it minimally adequate.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, but the description adds value by explaining the purpose of optional parameters (exePath for override, windowed for fullscreen) and the default windowed mode, which goes beyond the schema's basic descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action 'Launch Warcraft III running the given map' with a specific verb and resource. It distinguishes itself from sibling tools which are mostly editing or reading operations, making it the only test/run tool.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides context for when to use (to play changes immediately) and mentions optional parameters to override default behavior. It does not explicitly state when not to use or list alternatives, but the sibling set makes it clear this is the only tool for launching the map.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Write an object-data table back into the map and save. Pass the same { original, custom } shape returned by wc3_read_objects. Saves to outPath, or ".edited.w3x" beside the source if omitted (pass the source path to overwrite in place).
| Name | Required | Description | Default |
|---|---|---|---|
| mapPath | Yes | Absolute path to the source .w3x/.w3m map file | |
| kind | Yes | Which object-data table to write | |
| data | Yes | The object modification table ({ original, custom }) | |
| outPath | No | Output map path. Defaults to "<map>.edited.w3x". |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden. It discloses the write-and-save behavior, default output path, and overwrite capability. It does not detail error conditions or side effects (e.g., file locking), but the core behavior is clear.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, no filler. The key information (purpose, data shape requirement, output behavior) is front-loaded and each sentence contributes directly to understanding.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given 4 parameters, 100% schema coverage, no output schema, and sibling tools, the description covers the essential aspects: what the tool writes, the required data format, and output location. It does not mention return values or error cases, but for a write tool completeness is high.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, baseline 3. The description adds value by explaining that data must match the shape from wc3_read_objects and clarifies the outPath default and overwrite behavior, exceeding the schema's static definitions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Write') and resource ('object-data table') with clear action ('back into the map and save'). It distinguishes from sibling tools like wc3_read_objects and wc3_write_script by specifying the data domain and the required shape.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description advises to pass the same shape returned by wc3_read_objects, implying a read-modify-write workflow. It also explains default outPath behavior. It lacks explicit 'when not to use' but provides sufficient context for correct invocation.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Replace the map script (war3map.j / war3map.lua) and save. Saves to outPath, or ".edited.w3x" beside the source if omitted.
| Name | Required | Description | Default |
|---|---|---|---|
| mapPath | Yes | Absolute path to the source .w3x/.w3m map file | |
| content | Yes | New script source text | |
| outPath | No | Output map path. Defaults to "<map>.edited.w3x". |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided. Description indicates replacement behavior and output path default, but lacks details on side effects, error handling, or permissions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences are concise and front-loaded with the main verb 'Replace', covering essential information without waste.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no annotations or output schema, the description is fairly complete, explaining purpose and output default. Could mention error behavior.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so description adds little beyond schema. The default behavior for outPath is explained, but not significantly more.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool replaces the map script (war3map.j/lua) and saves, specifying the output default. It distinguishes from siblings like wc3_read_script.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use versus alternatives or prerequisites. The description only states what it does, not when to choose it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
v1.0.0wc3_add_camerawc3_add_regionwc3_add_triggerwc3_create_objectwc3_delete_camerawc3_delete_doodadwc3_delete_regionwc3_delete_unitwc3_list_doodadswc3_list_fileswc3_list_unitswc3_map_infowc3_modify_doodadwc3_modify_regionwc3_modify_unitwc3_open_in_editorwc3_overviewwc3_place_doodadwc3_place_unitwc3_read_cameraswc3_read_filewc3_read_importswc3_read_objectswc3_read_placementswc3_read_regionswc3_read_scriptwc3_read_soundswc3_read_stringswc3_read_terrainwc3_read_triggerswc3_replace_filewc3_set_stringwc3_test_mapwc3_write_objectswc3_write_scriptScored across 35 tools
Each tool targets a unique resource and action (e.g., add_camera, delete_unit, read_terrain). Overlaps like list_doodads vs read_placements are clarified by descriptions focusing on different use cases (listing for modification vs comprehensive snapshot). No two tools serve the same purpose.
All tools follow a consistent verb_noun pattern with the 'wc3_' prefix (e.g., add_camera, delete_doodad, read_script). No mixing of conventions (camelCase, etc.), making the pattern predictable and easy to understand.
With 35 tools, this exceeds the 25+ threshold for 'too many' per the rubric. While the complex domain of Warcraft III map editing justifies many tools, the count is still high and could be streamlined. Some tools could be merged (e.g., list_* and read_* could be combined).
The tool set covers most major aspects: CRUD for units, doodads, regions, cameras, objects; script and trigger management; file handling; and testing/editor integration. Minor gaps exist (no terrain modification, no import management, no map info update), but these do not break core workflows.
Teamfight Tactics data & AI coaching for Claude and ChatGPT — 19 tools, built-in Riot key.
Generate and edit images and create short videos inside Claude. Prepaid credits, no subscription.
Create projects, nodes, and tasks in UluP Spaces by conversation with Claude.
Read, edit, publish, and preview your pepita websites from Claude.
