rpgmaker-mz-mcp
Server Quality Checklist
Latest release: v1.3.0
- Disambiguation4/5
Most tools have a clear, distinct purpose: create/update/get/set/search/build prefix each explicitly names the resource or command type. However, overlaps exist within the simplified skill creators (create_skill vs create_damage_skill/healing_skill/buff_skill/state_skill) and event creators (create_map_event vs create_npc/create_chest/create_transfer), making selection slightly ambiguous despite detailed descriptions.
Naming Consistency4/5The vast majority follow snake_case verb_noun conventions (create_actor, update_map, get_map_events, build_show_text). A few outliers like object_tiles, batch_create, and next_free_id break the pattern, but they are rare and the intent remains clear.
Tool Count1/5With 119 tools, this is an extreme mismatch for an MCP server. Even for the broad domain of RPG Maker MZ, the surface is overwhelming and far exceeds the 50+ threshold defined as extreme. This will make it difficult for an agent to select the right tool efficiently.
Completeness3/5The tool surface is very comprehensive: CRUD for most database entities, map and tile editing, event command builders, validation, and system settings are all covered. However, there is no delete operation for actors, items, skills, troops, etc. (only maps and map events), and animations are absent. These are notable gaps for a full lifecycle.
Average 4.2/5 across 119 of 119 tools scored. Lowest: 2.1/5.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 110 commits in the last 12 weeks
- Last stable release on
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI is passing
This repository is licensed under MIT License.
This repository includes a README.md file.
No tool usage detected in the last 30 days. Usage tracking helps demonstrate server value.
Tip: use the "Try in Browser" feature on the server page to seed initial usage.
Add a glama.json file to provide metadata about your server.
If you are the author, simply .
If the server belongs to an organization, first add
glama.jsonto the root of your repository:{ "$schema": "https://glama.ai/mcp/schemas/server.json", "maintainers": [ "your-github-username" ] }Then . Browse examples.
Add related servers to improve discoverability.
How to sync the server with GitHub?
Servers are automatically synced at least once per day, but you can also sync manually at any time to instantly update the server profile.
To manually sync the server, click the "Sync Server" button in the MCP server admin interface.
How is the quality score calculated?
The overall quality score combines two components: Tool Definition Quality (70%) and Server Coherence (30%).
Tool Definition Quality measures how well each tool describes itself to AI agents. Every tool is scored 1–5 across six dimensions: Purpose Clarity (25%), Usage Guidelines (20%), Behavioral Transparency (20%), Parameter Semantics (15%), Conciseness & Structure (10%), and Contextual Completeness (10%). The server-level definition quality score is calculated as 60% mean TDQS + 40% minimum TDQS, so a single poorly described tool pulls the score down.
Server Coherence evaluates how well the tools work together as a set, scoring four dimensions equally: Disambiguation (can agents tell tools apart?), Naming Consistency, Tool Count Appropriateness, and Completeness (are there gaps in the tool surface?).
Tiers are derived from the overall score: A (≥3.5), B (≥3.0), C (≥2.0), D (≥1.0), F (<1.0). B and above is considered passing.
Tool Scores
- Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations are absent, so the description carries full responsibility for behavioral disclosure, but it provides none. It does not mention whether the operation has side effects, requires auth, or returns any specific structure, making it impossible for an agent to infer expected behavior beyond the generic 'get' verb.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely short, but this is under-specification rather than effective conciseness. It provides no useful content and fails to earn its place, akin to a placeholder rather than a meaningful tool description.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given 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, so the description must clarify what 'system data' means and what the tool returns. It does not, leaving the agent to guess the resource scope and return format, which is inadequate for confident invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has zero parameters and 100% schema description coverage, so the schema fully documents the invocation. With no parameters to explain, the description is not required to provide additional parameter semantics, meriting the baseline score of 4.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Get system data' is a tautology of the tool name, restating 'get_system' without adding specificity. It fails to clarify what 'system data' refers to (e.g., game settings, variables, or metadata) or how it differs from sibling getters like get_terms or get_project.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does 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. With many sibling get_* tools, the description offers no context, prerequisites, or exclusions, leaving the agent without direction.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are present, so the description must carry the behavioral disclosure burden. It only states 'Create a buff skill (simplified)' and omits side effects, write behavior, validation, or the existence of a dryRun preview mode. This is a significant gap for a creation tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single short sentence, which is commendable for brevity, but it leans toward under-specification. 'Simplified' hints at a reduced feature set without explaining what is omitted, making the sentence less informative than it could be while staying concise.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With 7 parameters, no annotations, and no output schema, a one-line description is insufficient. The agent learns the core purpose but lacks context about return values, side effects, and how this simplified version relates to the full create_skill tool. More behavioral and usage context is needed.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, with every parameter (including buffType, scope, and dryRun) having a concise description in the input schema. The description text adds no additional parameter semantics, so the baseline of 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
Description specifies 'Create a buff skill' with a clear verb and resource, distinguishing it from sibling skill creators like create_damage_skill, create_healing_skill, and create_state_skill. The 'simplified' qualifier adds differentiation but is vague about what simplification entails.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does 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 such as create_skill or other skill-type creators. There is no mention of prerequisites, suitability, 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.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. The verb 'update' implies mutation, but it does not disclose that changes are persisted, how dryRun works, what happens on invalid skillId, or any side effects. This is a significant gap 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.
Conciseness3/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence with no wasted words. However, it is under-specified and does not include essential usage or behavioral information, making it not optimally sized for the tool's complexity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has 3 parameters, including a dryRun flag and a nested updates object, but no annotations or output schema. The description does not explain the update semantics, the purpose of dryRun, or what the return value is, leaving the context incomplete for an agent to use effectively.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, with clear descriptions for dryRun, skillId, and updates. The description adds no extra parameter semantics, but the baseline 3 is appropriate since the schema already explains each parameter meaningfully.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action (update) and resource (skill's properties), making it distinct from sibling tools that update other resources. However, 'properties' is vague and does not specify which attributes can be updated, so it falls short of a fully specific purpose statement.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does 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 like create_skill or search_skills, and it does not mention how dryRun fits into a workflow. No context is given for selecting this tool over other update_* siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description must disclose behavioral characteristics but only says 'Create a damage-dealing skill (simplified)'. It does not mention whether this writes to disk, requires permissions, or how it differs from other skill-creation tools. The inclusion of 'simplified' is a hint but not an explanation of side effects or constraints.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, concise sentence with no redundant words. However, it is under-specified, making it efficient but not fully informative. It earns a 4 because it is front-loaded and free of fluff.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with 7 parameters, no output schema, and no annotations, the description is too sparse. It lacks any mention of return values, side effects, or the relationship to other skill creation tools. The schema covers parameter meanings, but the tool-level context is insufficient for an agent to fully understand when and how to use it.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema already provides descriptions for all 7 parameters (100% coverage), so the baseline is 3. The description adds no additional parameter semantics beyond what the schema already documents, and it does not mention that 'dryRun' allows previewing changes, which is only in the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's function with a specific verb ('Create') and resource ('damage-dealing skill'). The word 'simplified' hints at a specialized variant, distinguishing it from sibling tools like create_skill or create_healing_skill, though it doesn't name them explicitly.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does 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 such as create_skill or create_healing_skill. The description neither mentions prerequisites nor offers exclusions, leaving the agent to infer usage from the tool name alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full responsibility for behavioral disclosure. It does not mention that the tool writes to disk, creates a skill in the project, or what 'simplified' means. The dryRun parameter hints at write behavior, but the description itself adds no transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence with no wasted words. It earns its place by indicating the tool's purpose, though it could be more informative without becoming bloated.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a create tool with no output schema and many sibling creation tools, the description is too minimal. It does not explain the tool's role in the project, the meaning of 'simplified', or how it relates to create_skill. The schema provides some context, but the description alone is insufficient.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has 100% parameter description coverage, so the baseline is 3. The description adds no extra semantic meaning beyond what the schema already provides, such as examples or relationships between parameters.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Create a healing skill (simplified)' clearly states the verb and resource, and 'healing' distinguishes it from sibling tools like create_damage_skill or create_buff_skill. However, 'simplified' is vague and does not clarify what simplification entails.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives no guidance on when to use this tool versus alternatives such as create_skill or create_damage_skill. No context, 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.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the burden of disclosing behavior. It only says 'update' without covering merge semantics, permissions, reversibility, or response shape. This is minimal but not misleading.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
A single, front-loaded sentence with no filler. It is appropriately concise for the minimal information conveyed.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with a dynamic nested 'updates' object and no output schema, the description is insufficient. It doesn't explain valid properties, partial vs. full replacement, or return values, leaving significant gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema covers all three parameters (actorId, updates, dryRun) with 100% description coverage, giving a baseline of 3. The description adds no parameter details and does not clarify the format of the 'updates' object beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly identifies the tool as updating an actor's properties with a specific verb and resource. It distinguishes from sibling update tools by naming 'actor', though it doesn't list what properties are updatable.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does 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 like create_actor or update_enemy. There is no context about use cases, prerequisites, or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must explain the mutation's safety profile. It only says 'Update', which implies a write, but doesn't disclose whether the dryRun parameter supports previews, whether the change is persisted immediately, or what the return value is. This is a significant gap for a no-annotation 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.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, succinct sentence with no fluff. It is easily scannable and front-loaded. While under-specified, the conciseness itself is strong.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the 4-parameter, mutation-focused tool with no annotations and no output schema, the description is incomplete. It omits mention of the dryRun preview option, what happens on success, and any caveats about map validity. The schema covers parameters, but the description leaves the agent without a full picture of the tool's behavior.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool description adds no parameter semantics beyond the schema. However, the input schema thoroughly describes all four parameters, including the dryRun parameter's preview behavior, so the baseline of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description uses the specific verb 'Update' and identifies the resource 'game starting position'. This differentiates it from read-only sibling tools like get_starting_position, but the exact semantics of what constitutes a 'starting position' (map and tile) are left to the schema.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does 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 is no mention of prerequisites (e.g., map must exist) or when to prefer get_starting_position or set_map_tile. The description gives zero usage context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden of behavioral disclosure. It only restates the delete action without mentioning irreversibility, side effects on references, validation behavior, or what the dryRun parameter does. This leaves significant uncertainty 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.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence that gets straight to the point. There is no filler or repetition, making it highly concise and well-structured for an API reference.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Lacking an output schema and annotations, the description should provide expected return values, error conditions, or usage notes. It only states the basic action, leaving the agent uninformed about what happens after deletion or how dryRun affects the operation, making it incomplete for a tool with no other context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema provides complete descriptions for all three parameters (mapId, eventId, dryRun), covering 100% of the parameter semantics. The description adds no additional meaning beyond what the schema already gives, 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.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Delete'), the resource ('an event'), and the scope ('from a map'), with the identifier 'by ID'. This distinguishes it from sibling tools like create_map_event, update_map_event, and get_map_event, which cover other operations on the same resource.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does 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, no prerequisites, and no mention of the dryRun parameter's purpose or implications. The description is purely declarative and offers no context for decision-making.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden for behavioral disclosure, but it only repeats the verb 'update' without explaining side effects, persistence, validation, or the dryRun preview behavior. There is no contradiction, but the description adds no behavioral context beyond the schema.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, short sentence with zero extraneous words. It is front-loaded with the action and target, making it maximally concise and easy to parse.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple update tool with no annotations and no output schema, the description is insufficiently complete. It does not mention the dryRun option (even though the schema does), nor does it clarify the distinction from similar tools like update_title_screen. The agent gets no context about return values or side effects.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, with clear descriptions for 'title' and 'dryRun', so the baseline is 3. The tool description itself adds no parameter information, but the schema already provides adequate semantics.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Update the game title' uses a specific verb ('update') and resource ('game title'), clearly distinguishing it from sibling tools like update_title_screen or update_actor. It directly states what the tool does in a concise, unambiguous way.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does 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. The description does not mention any context, prerequisites, or exclusions, leaving the agent to infer usage solely from the tool name.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must carry the burden of behavioral disclosure. It only says 'Get', which implies a read operation, but it does not specify return format, error handling, or side effects. This is insufficient for an agent to understand what happens if the event is not found or what exactly is returned.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, six-word sentence with no unnecessary words. It is immediately clear and appropriately sized for a simple get operation.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With two well-documented parameters and a clear purpose, the tool is invocable. However, there is no output schema and no mention of return values or error behavior, leaving some gaps. It is adequate but not rich, especially given no annotations.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema fully documents both parameters (mapId and eventId) with descriptions and types, achieving 100% schema coverage. The description adds no additional parameter semantics, so the baseline of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'Get' and the resource 'specific event from a map', making it easy to understand. It distinguishes itself from sibling tools like get_map_events (plural) and search_map_events by indicating a single, specific event retrieval.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no context on when to use this tool versus alternatives like get_map_events or search_map_events. It does not mention any exclusions or related tools, leaving the agent to infer usage solely from the tool name.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden of behavioral disclosure. The verb 'get' strongly implies a read-only, non-destructive operation, which is a key behavioral trait, but the description does not explicitly state safety, return format, or any side effects. It's adequate but lacks detail.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence with no filler or redundancy. Every word contributes to the core meaning, making it maximally concise.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has no output schema, the description is the only source for understanding return values. It states the tool gets information about all maps, but doesn't enumerate what that information is (e.g., name, dimensions, events). For a 0-param, get-all tool, it's minimally sufficient but leaves the agent guessing about the result structure.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, so the schema trivially covers 100% of parameter semantics. The baseline for 0-param tools is 4, and the description adds no parameter-related ambiguity.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Get information about all maps' uses a clear verb (get) and resource (all maps), and the 'all maps' scope distinguishes it from sibling tools like get_map (singular). However, 'information' is vague and doesn't specify what fields or details are returned, so it's not maximally specific.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
No usage guidance is provided. The description doesn't state when to use this tool versus alternatives like get_map, get_map_dimensions, or get_map_region, nor does it mention any exclusions or prerequisites. It's a one-liner with no contextual direction.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the burden. It discloses the key behavior of shallow merging, which indicates updates are merged rather than replacing the whole record. However, it does not disclose what happens if the armor ID does not exist, whether changes are reversible, or any error behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence of under 15 words, front-loading the core purpose and adding the key merge behavior without any filler. Every word contributes.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description covers the essential purpose and merge behavior, and the schema documents all parameters. However, given it is a mutation tool with no annotations, it lacks important context such as error handling, idempotency, or what happens if the armor is missing. The dryRun parameter is mentioned in the schema but no behavioral context is provided beyond that.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, and each parameter already has a description. The description adds meaningful context by noting 'shallow merge', which clarifies how the 'updates' object is applied – it merges fields rather than replacing the entire record. This goes beyond the schema's generic 'Object containing armor properties to update'.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description states a clear verb and resource: 'Update an armor's properties'. The parenthetical 'shallow merge into the existing record' adds specific behavior. However, it does not explicitly distinguish from sibling tools like update_actor or create_armor, though the resource is obvious from the name.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does 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. It does not mention prerequisites, such as the armor needing to exist, or contrast with create_armor. The usage context is only implied by the tool name and description.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, and the description only states the action without disclosing return format, ordering, pagination, or error behavior. For a read operation, it provides minimal behavioral context beyond what the name already conveys.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence with no redundant words. It communicates the essential purpose efficiently.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple single-parameter getter with no output schema, the description is minimally viable. It identifies the tool and required input, but lacks details on return structure, edge cases, or related tool distinctions that would make it fully self-contained.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% with mapId described as 'The ID of the map'. The tool description adds no additional meaning beyond the schema, so the baseline of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Get all events from a specific map' uses a specific verb ('Get'), names the resource ('all events'), and the scope ('from a specific map'). It clearly distinguishes from sibling tools like get_map_event (singular) and search_map_events (filtered search).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies the use case (retrieving all events for a given map) but does not explicitly mention alternatives or when not to use it. There is no reference to get_map_event for a single event or search_map_events for filtered queries, leaving usage guidance implicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must disclose behavioral traits. It only states that events are searched by name; it does not reveal whether the operation is read-only, how results are returned (full objects vs. summaries), case sensitivity, pagination, or limits. This is a significant gap for a search tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence with no filler or redundant information. It efficiently conveys the tool's core function without wasting words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple two-parameter search tool with clear schema descriptions, the description is minimally adequate. However, there is no output schema and no mention of return value structure or result behavior, which would be necessary for full completeness. It lacks richer context that would help an agent understand expected responses.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, and both parameters (mapId and searchTerm) have clear descriptions in the schema. The tool description adds no additional meaning beyond the schema, so the baseline of 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('search'), identifies the resource ('events on a map'), and specifies the search criterion ('by name'). This clearly distinguishes it from sibling tools like get_map_events (which lists all events) and get_map_event (which fetches a single event).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for finding events by name but does not explicitly state when to use this vs. alternatives, nor does it mention exclusions. There is no direct comparison with get_map_events or search_troops, leaving the agent to infer the appropriate context from the tool name and description.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It adds a key behavioral trait—'shallow merge'—indicating that existing properties not included in the update remain unchanged. However, it doesn't disclose potential side effects, permissions, reversibility, or return values, leaving some gaps.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence that front-loads the core purpose ('Update a weapon's properties') and adds a valuable behavioral detail. Every word earns its place, with no redundancy or filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple update tool with 3 parameters, the description covers the essential operation and merge behavior. However, with no output schema or annotations, it does not explain what the tool returns or any side effects. The parameter schema fills in some gaps, but the description alone is not fully complete for safe invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the parameters are already well documented. The description does not add additional parameter-specific semantics, but the 'shallow merge' qualifier indirectly clarifies how the 'updates' parameter is applied. This meets the baseline without exceeding it.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Update a weapon's properties' with a specific verb and resource, distinguishing it from sibling update tools (e.g., update_actor, update_item). The addition of 'shallow merge into the existing record' further clarifies the exact behavior, making the purpose precise and unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does 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. It doesn't mention prerequisites, exclusion criteria, or contrast with sibling tools like create_weapon or update_item. The usage is implied by the name and description, but no explicit context or alternatives are given.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full responsibility for behavioral disclosure. It only states 'Get the game title' without mentioning return format, whether it reads from current project state, or any side effects. Minimal behavioral insight is offered.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single short sentence, directly front-loaded with the verb and resource. No redundant or unnecessary words are present.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (no parameters, no nested objects), the description is mostly sufficient. It could explicitly mention that the return value is the game title string, but the name and verb already imply this. It is complete for a low-complexity getter.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, so there is no parameter semantics to explain. The description adds no parameter information, but the baseline for 0 params is 4, and there is nothing missing.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'get' and the resource 'game title', making it unambiguous what the tool does. It distinguishes from siblings like update_game_title, which is a different operation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no guidance on when to use this tool versus alternatives, such as get_title_screen or get_system. No context or exclusions are provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the transparency burden. It discloses error behavior for missing record references (codes 21/22, 43, 44), which is useful, but it does not mention that the tool writes to disk, requires a loaded project, or what side effects creation entails.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences with no filler. The first sentence defines the action; the second provides a compact, highly specific error mapping. Every part earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given 12 parameters and no output schema, the description is modest. It adds error-handling context but does not explain return values (e.g., new skill ID), prerequisites, or typical usage flows. The rich schema compensates for parameter detail, but broader context is missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 100% description coverage for all 12 parameters. The description adds no additional meaning to the parameters; it only refers to effects indirectly via the error message. Schema descriptions already handle parameter semantics.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description states 'Create a new skill with custom properties' with a specific verb and resource. The phrase 'custom properties' distinguishes this generic creator from specialized siblings like create_healing_skill and create_damage_skill.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies this is the general-purpose skill creation tool, but it does not explicitly name alternatives or state when to use this over specialized creators. No exclusions or comparative guidance is provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It reveals that the search matches on name or nickname fields, which is useful, but it does not state whether the search is partial or exact, case-sensitive, or what the return format is, nor does it explicitly confirm a read-only operation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise: a single sentence of six words that front-loads the verb and resource. No wasted words, and it efficiently conveys the key distinguishing detail without unnecessary elaboration.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple one-parameter search tool with no output schema or annotations, the description is minimally adequate but leaves gaps. It tells what is searched (actors by name/nickname) but does not specify the result type, behavior (e.g., partial vs. exact match), or any limits, which are important for an agent to fully trust the invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema covers the single parameter searchTerm with a generic description, but the tool description adds specific meaning by indicating that the term is matched against 'name or nickname.' This enriches the schema description and clarifies the parameter's semantic role beyond the generic 'search term to find actors.'
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb 'Search' with a clear resource 'actors' and adds the modifier 'by name or nickname', which tells exactly what the tool does. It clearly distinguishes from sibling tools like create_actor or update_actor by focusing on searching.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage when looking up actors by their name or nickname, but it does not provide explicit guidance on when to use this tool versus alternatives such as search_enemies or search_items. It also does not mention any exclusions or prerequisites.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It discloses only the search fields, but does not state the return format (e.g., item entries, IDs), pagination, case sensitivity, or behavior when no matches are found.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence that is front-loaded and contains no redundant words. It communicates the core purpose efficiently.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple one-parameter search tool, the description covers the essential search behavior, but the lack of any output schema or return-value explanation leaves a noticeable gap. An agent must infer what the tool returns.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema description ('The search term to find items') is generic, while the tool description adds that the search term is matched against both name and description. This adds meaningful semantics beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'Search' with resource 'items' and the specific search fields ('by name or description'). This distinguishes it from sibling search tools such as search_enemies and search_skills.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
Usage is implied: use this tool when you need to find items by name or description. However, there is no explicit guidance on when to prefer this over other search tools, nor any mention of exclusions or alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It mentions the length constraint but does not disclose error behavior on mismatch, whether dryRun is supported, permanence, or what the response looks like. For a mutation tool, this is a significant gap.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, well-structured sentence that front-loads the core purpose and packs in the essential paramId mapping and length constraint. No wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description covers the core purpose and critical constraint, but it omits mention of the dryRun parameter and any return value or error handling. While not overly complex, the lack of these details leaves it slightly incomplete for a mutation tool with no output schema.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already documents all parameters. The tool description repeats the paramId mapping and values length constraint that are already present in the schema, adding no extra semantic value beyond the baseline.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb ('Replace'), the resource ('one of a class's 8 parameter growth curves'), and its scope. It also provides the paramId mapping and a key constraint, making it easy to distinguish from sibling tools like update_class.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The context is clear: this tool is specifically for replacing parameter growth curves, and the constraint about matching curve length gives usage guidance. However, it does not explicitly name alternatives or provide when-not-to-use instructions, so it falls short of a 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It discloses a validation behavior ('must reference an existing actor') but does not mention side effects (e.g., overwrites current starting party), error handling for invalid ids, or the presence of the dryRun parameter that changes behavior. This is minimal disclosure 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.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, front-loaded with the primary purpose, and no unnecessary wording. Every clause earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple setter with two parameters, the description covers the core action and a key constraint. However, it omits return behavior (no output schema) and does not mention the optional dryRun parameter, which affects whether the tool writes to disk. This is adequate but has clear gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the baseline is 3. The tool description adds a meaningful constraint beyond the schema: every id must reference an existing actor. This is not present in the schema's partyMembers description, so it adds value.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Set'), the resource ('starting party'), and elaborates with 'actor ids the game begins with, in order.' It distinguishes from related tools like get_party and build_change_party_member by specifying this is the initial party, not a runtime change.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives an implicit usage context (game start) and a constraint (ids must reference existing actors), but it does not explicitly state when to use this tool versus alternatives like get_party or build_change_party_member. The constraint provides some guidance, but there are no when-not-to-use notes.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It discloses a significant behavioral trait: the write is refused and nothing is saved if the result is structurally invalid, with a force override. This adds meaningful safety context. However, it does not mention permissions, merge semantics, or default response format, though the schema partially addresses the latter.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence of 24 words, front-loaded with the purpose and including a critical behavioral caveat. Every word earns its place; no redundancy or filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Although schema coverage is high and the description discloses a key behavior, the tool has 6 parameters, no output schema, and no annotations. The description lacks usage guidance and does not explain the default response shape beyond what the schema's verbose parameter description hints at. It is minimally viable but leaves gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so baseline is 3. The description's mention of 'force: true' duplicates the schema's force parameter description rather than adding new meaning. No additional parameter semantics are provided beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the operation: 'Update a map event's properties' with a specific verb (update) and resource (map event properties). This distinguishes it from siblings like create_map_event (create) and get_map_event (read). The validation nuance doesn't obscure the core purpose.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does 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 versus alternatives such as create_map_event or add_event_command. It only implies usage through its purpose statement, without exclusions or situational context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the burden of behavioral disclosure. The phrase 'shallow merge into the existing record' reveals that the update is a merge, not a full replacement, which is valuable context. However, it omits other important traits such as required permissions, whether the operation is reversible, and what response is returned, so it is only partially transparent.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, concise sentence that is front-loaded with the verb and resource, followed by the key merge behavior. Every word earns its place, and there is no redundancy or verbose explanation.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description covers the core purpose and merge behavior, and the schema adequately documents all parameters. However, without an output schema or annotations, important context about return values, error behavior, and side effects is missing. For a simple update tool, this is adequate but not complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the baseline is 3. The description adds semantic value beyond the schema by clarifying that the 'updates' object is shallow-merged into the existing record, which is not stated in the parameter descriptions. This helps the agent understand how the updates parameter behaves.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly identifies the operation ('Update') and the target resource ('a state's properties'), and the parenthetical 'shallow merge into the existing record' adds precision about the update semantics. This distinguishes it from other update_* tools that target different resources (e.g., update_actor).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does 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. The description simply states what it does, leaving usage to be inferred from the name and sibling context, but it does not mention any alternatives or prerequisites.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It clearly indicates a read operation by using 'Get' and describes the return value, but it does not disclose potential error behavior (e.g., missing map) or confirm non-destructiveness explicitly. Adequate for a simple getter.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence that conveys the essential purpose without any wasted words. Structure is ideal for a simple getter.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description explains the return semantics (width and height in tiles), which is essential since there is no output schema. It lacks error handling details but is otherwise complete for a straightforward query tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% (mapId has a description). The tool description adds no additional parameter meaning beyond confirming the map reference, so it meets the baseline but does not elevate it.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly identifies the specific verb ('Get') and resource ('width and height of a map'), with the additional detail about units ('in tiles') that distinguishes it from other get_* tools that retrieve different map-related data.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies when to use the tool (when map dimensions are needed) but provides no explicit exclusion criteria or alternatives. Since the tool is simple and unique, this is acceptable but not exemplary.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden. The word 'Get' reasonably implies a read-only operation, and the scope 'all game switch names' is clear. However, it does not disclose any potential side effects, return format, or caveats, which would be relevant absent an output schema.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence with no extraneous content. It conveys the exact action and target without any filler, making it highly concise and well-structured.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with no parameters and no output schema, the description fully explains what the tool does. It doesn't detail the return structure, but for a simple listing of names, the absence is minor. Given the sibling context (e.g., set_switch_name), the function is easily understood.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema is empty, so there are zero parameters. Schema description coverage is effectively 100% (vacuously). The baseline for zero parameters is 4, and the description adds no parameter information because none exists; nothing more is needed.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Get all game switch names' uses a specific verb ('Get'), a specific resource ('game switch names'), and indicates the full scope ('all'). It clearly distinguishes this from sibling tools like set_switch_name (which writes a name) and get_variables (which gets a different resource).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no guidance on when to use this tool versus alternatives. It does not mention related tools like set_switch_name, nor any context where this tool is preferred. The description is purely declarative and provides no usage or exclusion criteria.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It discloses the case-insensitive behavior, which is useful, but lacks other behavioral details such as whether it performs substring matching, returns partial results, or has any side effects. For a search tool, this covers the key trait (case-insensitivity) but not the full behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence: 'Search troops by name (case-insensitive)'. Every word earns its place, providing the essential verb, object, and a key qualifier without superfluous content.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With only one parameter, no output schema, and a straightforward search operation, the description is largely complete. It clearly states the search target and matching behavior, though it does not specify the return format or any limits, which is acceptable given the simplicity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% for the single parameter 'searchTerm', which is described as 'The search term to find troops'. The description adds no additional meaning beyond the schema, meeting the baseline for high schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Search troops by name (case-insensitive)' uses a specific verb 'search' plus the resource 'troops' and the field 'name', clearly distinguishing it from sibling search tools like search_actors and search_enemies. It is concise and unambiguous about what the tool does.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies the tool is for finding troops by name, but it does not explicitly state when to prefer it over other search tools or provide alternative conditions. Sibling tools exist (search_actors, search_enemies), but no direct comparison or exclusion is given, so usage context is only implied.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the burden of disclosing behavioral traits, and it does so well by stating that writes are refused (nothing saved) on structural invalidity and that force: true overrides this. This goes beyond the obvious 'add' action and covers a key failure mode. However, it does not mention the success-side behavior, return format, or the dryRun/verbose preview features, which are only present in the schema.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is compact and front-loaded with the core action. Each sentence earns its place: the first states the purpose, the second explains the validation refusal behavior, and the third points to the force override. There is no wordy or redundant filler, making it easy to scan and act on.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description covers the essential validation behavior and force override, but it stops short of explaining the broader workflow: how to build a valid command object (sibling build_* tools), what the default response contains, or how dryRun/verbose affect the interaction. Given the absence of an output schema and the nested command structure, more contextual guidance would help an agent invoke the tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the baseline is 3; the description adds only marginal parameter meaning beyond the schema. It references force: true and the wrong-parameter-count criterion, but the schema already documents force and all other parameters thoroughly. The description does not clarify command construction (e.g., the relationship to build_* tools), leaving the command object semantics to the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with a specific verb and resource: 'Add a command to an event page.' This clearly states the tool's function and differentiates it from sibling tools like insert_event_commands or set_event_page by focusing on adding a single command to a specific event page. The validation/force caveat further clarifies the primary action without muddying the purpose.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies when to use the tool ('Add a command to an event page') and describes the validation gate, but it does not explicitly mention when not to use it or name alternatives among the many sibling tools. There is no guidance distinguishing it from insert_event_commands or noting that command objects should be constructed via build_* tools, leaving usage somewhat inferred rather than directed.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description discloses several important behaviors: only `name` is required with default values for class, level, equips, and traits; it allocates and returns the next unused actor id; and it includes a detailed caveat about the Hit Rate trait causing missed physical actions. This goes beyond a simple one-liner.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is three sentences, with the first establishing the core purpose and the second covering required fields, defaults, and return value. The final sentence is a dense but valuable caveat; no filler or repetition is present.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given 15 parameters and no output schema, the description provides a substantial amount of context: required field, defaults, return value, and a critical trait behavior warning. However, it omits details about several parameters (e.g., profile, faceName, characterIndex) and does not describe the response shape beyond the allocated id, leaving some gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is low (7%), so the description compensates by stating which fields are optional and what defaults apply ('class 1, level 1-99, five empty equip slots, no traits'). It also clarifies the traits behavior with the Hit Rate note, but it does not explain individual parameter formats for many fields, leaving some semantics to inference from names.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with a clear verb-object pair ('Create a new actor in data/Actors.json'), specifying both the action and the target file. It distinguishes itself from sibling creation tools (create_chest, create_enemy) and update_actor by focusing on the creation of actors.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description does not explicitly compare this tool to alternatives like update_actor, nor state when not to use it. Usage context is implied by the verb 'Create', but no exclusions or alternative references are provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the burden of behavioral disclosure. The verb 'get' implies a read-only operation, and the mention of 'names' clarifies the output scope, but it does not explicitly state non-mutating behavior or return format. This is adequate but not rich.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence with no wasted words. 'Get all game variable names' is concise yet informative, every word contributing to clarity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple getter with no parameters and no output schema, the description is sufficient. It clearly indicates the resource (game variable names) and the operation (get all), which fully defines the expected behavior. Additional return-format details are unnecessary for such a straightforward tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, so the schema is empty and there are no semantics to explain. Per the rubric, the baseline is 4 for 0 params, and the description does not need to add anything.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Get all game variable names' uses a specific verb ('get') and resource ('all game variable names'), clearly stating the tool's purpose. It is distinct from siblings like 'set_variable_name' and 'get_switches' by focusing on reading variable names.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does 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 'get_database' or 'get_switches'. There is no mention of exclusions, prerequisites, or typical use cases, leaving the agent without contextual direction.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full transparency burden. It does disclose a key behavioral trait: shallow merge into the existing record, which clarifies merge semantics. However, it omits other important traits for a mutation tool, such as permissions, irreversibility, side effects, or return values.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
One concise sentence, front-loaded with the action and scope, followed by a parenthetical that adds essential semantics. No filler or repetition; every word earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description adequately covers the core operation and merge behavior, and the schema documents all parameters. However, with no annotations and no output schema, it leaves gaps around return values, error handling, and broader usage context, making it minimally adequate rather than complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with clear per-parameter descriptions, so the baseline is 3. The description adds meaning by explaining 'shallow merge', which directly clarifies how the 'updates' parameter will be applied, exceeding what the schema provides for that key parameter.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it updates an item's properties, using the specific verb 'Update' and resource 'item's properties'. The parenthetical 'shallow merge into the existing record' adds precise scope and distinguishes it from replace-style tools or other update tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage when modifying existing item properties, but it does not explicitly mention alternatives (like create_item) or exclusion scenarios. No 'when not to use' guidance is provided, leaving the decision to the agent based on the tool's name and generic action.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden. It discloses key side effects: reparenting direct children to the parent (preventing subtree deletion) and not touching System.json. This goes beyond a simple 'delete' statement, though it omits irreversibility and 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.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences, front-loaded with the action, and every sentence adds value. It efficiently explains the deletion mechanics and the important exception about child reparenting without redundancy or fluff.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has only two parameters and no output schema, the description covers the main behaviors well. However, it does not mention return values on success/failure or error conditions (e.g., what if mapId doesn't exist). For a destructive operation this is a minor gap, but overall it provides sufficient context for most usage.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, with both parameters (mapId, dryRun) clearly described. The tool description adds no extra parameter-specific meaning beyond the schema, so the baseline of 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose with a specific verb ('Delete') and resource ('map'), and details exactly what happens: remove from MapInfos.json and delete the data file. It distinguishes itself from sibling tools like delete_map_event by focusing on the map node itself, not events on it.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage when deleting a map node, and notes it does not touch System.json, providing some boundary context. However, it gives no explicit alternatives or exclusions (e.g., 'use update_map_tree for restructuring'), so guidance on when not to use it is missing.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden of behavioral disclosure. It goes beyond a simple 'getter' by revealing the exact structure of the returned data: the arrays ('basic', 'commands', 'params') and the 'messages' map, including a hint of its contents (menu labels, system messages). This gives the agent clear expectations of what to receive, which is valuable for a read-only tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, well-structured sentence. It front-loads the primary action ('Get the game vocabulary/terms') and then immediately provides the specific components returned, with no filler or redundancies. Every word contributes to clarity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with no parameters, no annotations, and no output schema, the description provides a solid overview of what is returned. It explicitly names the array and map fields, making the tool's output predictable. However, it could mention potential error conditions (e.g., no game loaded) or note that it returns the full set of terms, but these are minor gaps for such a simple getter.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, so the baseline is 4. The description does not need to explain parameter semantics, and it correctly focuses on the return contents. This maximizes usefulness given the tool's simplicity.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool retrieves game vocabulary/terms, and lists the specific components: 'basic', 'commands', 'params' string arrays and the 'messages' map. This precise verb+resource+scope distinguishes it from sibling getters like get_system or get_game_title, which target different aspects of the project.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit guidance is provided regarding when to use this tool versus alternatives. There is no mention of a 'use set_term for editing' or 'see get_database for the full database'. The usage context is only implied by the getter nature of the tool, but the description does not clarify when to prefer it over similar retrieval tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description discloses the case-insensitive matching behavior, which goes beyond the simple schema parameter description. However, it does not mention return format, pagination, or behavior on no matches. Since no annotations are provided, the description carries a greater burden, but it only partially fulfills it.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence with no redundant or extraneous words. It efficiently conveys the core purpose and a key behavioral detail, exemplifying ideal conciseness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple tool with one parameter and no output schema, the description is sufficiently complete. It states the search target (enemies), the field (name), and the matching behavior (case-insensitive). While it does not explain the return structure, that is a minor gap for a basic search operation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 100% description coverage for the single parameter, but the tool description adds meaning by clarifying that the search is by name and is case-insensitive. This provides context beyond the schema's generic 'search term' description, enhancing the parameter's semantic understanding.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's function: 'Search enemies by name' identifies the verb (search), resource (enemies), and field (name). The added detail 'case-insensitive' distinguishes it from potential sibling search tools and provides a precise scope.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for searching enemies by name, but it does not explicitly mention when to use this tool over alternatives like search_troops or search_actors. No 'when not to use' or alternative tool references are provided, so the guidance is implied rather than explicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the burden of behavioral disclosure. It adds context by specifying the search targets (name or description), but does not disclose result behavior such as case sensitivity, partial matching, or return format. This is acceptable for a simple search but not overly transparent.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
One concise, front-loaded sentence that says exactly what the tool does with no filler or redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's low complexity (single parameter, no output schema), the description is nearly complete. It covers the search target and field scope; only missing details about return value structure, which is acceptable when no output schema exists.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema covers 100% of parameters, providing a baseline of 3. The description enriches the meaning of searchTerm by clarifying it matches against the skill's name or description, which goes beyond the schema's generic 'Search term'.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool searches for skills by name or description, using a specific verb and resource. It distinguishes itself from sibling search tools (search_actors, search_enemies, etc.) by explicitly targeting skills.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
Usage is implied: use when you need to find skills by name or description. However, there is no explicit guidance on when to prefer this over other search tools or any exclusions, so it stops at implied context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the burden of behavioral disclosure. It honestly notes raw engine integers and the lack of autotile/passability awareness, which is useful. But it does not disclose side effects like overwriting existing tiles, error behavior, or the difference between dryRun and actual writes, leaving some gaps.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, no fluff. The verb, target, coordinates, and layer bound are in the first sentence; the critical caveat about raw IDs and low-level behavior is in the second. Every word earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple setter with full schema coverage, the description covers the core semantics and key caveat. It doesn't explain return values or error conditions, but none are promised by the schema or output. Given the tool's low complexity, the description is nearly complete, only missing explicit alternative references.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the baseline is 3. The description reinforces key semantics (raw tile ID, layer range 0-5) but does not add significant detail beyond what the schema already provides. The dryRun property is only explained in the schema, not the description.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Set a single raw tile ID'), the resource (tile at x,y on a z-layer), and the scope (single, raw, 0-5). It distinguishes itself from bulk or high-level tools by explicitly calling itself a low-level primitive, separating it from siblings like paint_tiles and fill_area.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The context is clear: this is for setting a single raw tile without autotile/passability awareness, which implies it's not for bulk painting or high-level editing. However, it does not explicitly name alternative tools or state when not to use it, so it doesn't fully meet the bar for explicit exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden of explaining behavior. It does disclose that the tool returns updated terms and clarifies key semantics per category, but it does not explicitly warn that this is a mutating operation or mention the dryRun preview feature, leaving some behavioral context to the schema.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, no filler. The first sentence states the purpose directly, and the second packs essential key-format and return-value information into a compact, well-structured explanation.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple setter with no output schema and full parameter descriptions in the schema, the description adequately covers purpose, key semantics, and the return value. It lacks explicit warnings about side effects, but given the tool's simplicity and schema support, it is sufficiently complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the baseline is 3. The description's key-format explanation merely restates what the schema already says about the 'key' parameter; it adds no additional parameter meaning beyond the schema's own descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with 'Set one vocabulary term,' a specific verb and resource combination that clearly states the tool's function. The key-format explanation distinguishes it from related tools like get_terms and other setter tools, making its scope unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
It provides clear context for how the 'category' parameter affects the 'key' format, implying usage across different term groups. While it doesn't explicitly name alternatives like get_terms for reading, the setter vs. getter contrast is implicit and the category guidance is actionable.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It explicitly states 'Read-only: returns { command }', disclosing that the tool does not mutate project state and what it returns. This is a useful behavioral disclosure beyond the schema, though it could further note that it only builds the command without inserting it (already implied) and may not validate operand-value consistency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences with no wasted words. The first sentence delivers the core purpose and the second adds the key behavioral trait (read-only) and return shape. It is well front-loaded and easily scannable.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has a nested operand object with conditional fields, no output schema, and no annotations. The description covers the main purpose, return shape, and read-only nature, but does not explain the conditional requirements of the operand sub-parameters (e.g., which fields are required based on type) or show an example output command structure. This leaves some gaps for correct invocation, but the simplicity of the operation and clear schema descriptions keep it adequate.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% for all parameters, so the schema already documents operation (increase/decrease), operand type (constant/variable), value, and variableId. The description adds only a high-level summary ('increase or decrease party gold by a constant or variable amount') without clarifying conditional requirements (e.g., when type=variable, variableId is needed; when constant, value is needed). This matches the baseline of 3 for high schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool builds a specific Change Gold (125) event command, distinguishes it from the many other build_* tools (e.g., build_show_text, build_control_switch), and specifies its purpose of insertion via insert_event_commands. Verb 'build' plus resource 'Change Gold' gives a precise, unambiguous action.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly situates this tool in the pipeline with 'for insertion via insert_event_commands', telling the agent when to use it (to generate a command before inserting). It does not explicitly name alternatives or exclusions, but the build_* family context plus the specific resource makes the appropriate use case clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the burden. The verb 'Get' implies read-only behavior, and the return shape is disclosed, but there is no explicit statement about side effects or safety. For a simple getter, this is adequate but not highly transparent.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence with no redundant words. It efficiently conveys both purpose and return shape, making it highly concise and well-structured.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With 0 parameters and no output schema, the description fully covers the return value by explicitly listing mapId, x, and y. There is no additional complexity requiring more explanation, so the description is complete for this simple tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, earning a baseline of 4 per the rubric. The description focuses on the return value, which is appropriate since there are no parameters to explain.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's function with a specific verb ('Get') and resource ('game starting position'). It also provides the return shape ({ mapId, x, y }), which distinguishes it from the sibling tool 'update_starting_position'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
Usage is implied: the tool is a getter for the starting position. However, there is no explicit guidance on when to use this tool versus alternatives such as update_starting_position, nor any contextual notes about typical use cases.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It explains the meaning of each setting, including layering order (title2Name draws over title1Name), asset source (via list_assets), and the drawTitle flag. This provides valuable context beyond the bare tool name. It does not explicitly state side effects, but 'get' strongly implies read-only.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, information-dense sentence. It is front-loaded with 'Get the title screen settings' and uses parentheticals to organize additional context. No filler words, though the sentence is long and could be split for readability.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given 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 compensates by naming all returned settings and explaining their semantics. It covers what each field means and where values come from. While it doesn't specify the exact return format structure, it is sufficient for an agent to understand what will be returned.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, so the baseline of 4 applies. The description has no parameter information to provide, which is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly identifies the tool as retrieving the title screen settings and enumerates exactly which settings are included: title1Name/title2Name, titleBgm, and drawTitle. This specificity distinguishes it from sibling tools like update_title_screen (the setter) and get_game_title (a different setting).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The verb 'Get' implies this is for reading current title screen settings, and the sibling update_title_screen naturally serves as the write counterpart. However, the description does not explicitly state when to use this tool versus alternatives, nor does it mention any exclusions or prerequisites. Context is clear but not explicitly stated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden. It clearly states 'Read-only: returns { command }', disclosing that it doesn't mutate state and what the return value is. It also explains the initialize parameter's behavior (reset to initial state) for add operations. This is substantial but doesn't cover potential errors 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.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
Three sentences, all informative, no filler. Front-loaded with the core purpose, then adds necessary context. Every sentence earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with 4 params and no output schema, the description adequately explains the command type, usage context, and return format. It could be more detailed about the returned command structure, but it's sufficient for an agent to know what to expect.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so all parameters are already documented. The description adds a small clarification about initialize (add only) but largely repeats schema information, so it doesn't significantly go beyond the baseline.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool builds a Change Party Member (129) event command, specifying the verb 'Build' and the resource. It distinguishes from sibling tools by naming the event command ID and its purpose (add/remove actor from party).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
It says the command is 'for insertion via insert_event_commands', giving clear context for where the output goes. However, it doesn't explicitly state when not to use this tool or mention alternatives, so it stops short of a 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It explicitly states 'Read-only' and that it returns '{ command }', which are critical behavioral traits. It also adds the event command IDs (212/213) and character targeting context, but does not detail error behavior or side effects of the generated command when inserted.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences long, front-loaded with the core purpose, and every phrase adds value. It efficiently packs the command types, insertion context, characterId mapping, and read-only behavior without redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has 5 parameters and no output schema, but the description provides the essential context: it returns a command object for insertion, identifies the exact event commands, and explains characterId values. It does not detail the internal structure of the returned command, but for a builder that partners with insert_event_commands, this is sufficient.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so baseline is 3. The description mentions characterId semantics and the id's dual role, but these are already fully described in the schema. It adds no significant parameter-level meaning beyond what the structured schema already provides.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool builds a Show Animation (212) or Show Balloon Icon (213) event command for insertion via insert_event_commands, specifying the exact verbs and resources. It distinguishes itself from sibling builders by naming the specific event command types and their target character scope.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly mentions the intended use case ('for insertion via insert_event_commands') and clarifies the characterId semantics (player, this event, or event id). It implies the tool is for building these two specific command types among many sibling builders, though it does not name alternatives or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden of disclosing behavior. It explicitly states 'Read-only: returns { command },' which tells the agent this tool has no side effects and produces a command object for further use. This adds key behavioral context beyond the tool name.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, well-structured sentence with an em-dash clarifying the purpose, followed by a short note on return type. Every word adds value—no redundancy or irrelevant detail.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple builder tool with 3 params, no output schema, and no annotations, the description covers the key aspects: what it builds, how it will be used, its read-only nature, and the returned shape. It could elaborate on the command structure, but the provided information is sufficient for selection and invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% and each parameter already has a semantic description (e.g., actorId: 'The actor whose name is entered'). The description adds no extra meaning beyond the schema, so the baseline of 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's function: 'Build a Name Input Processing (303) event command for insertion via insert_event_commands — open the name-entry screen for an actor.' This identifies the specific verb (build), resource (Name Input Processing event command), and purpose, distinguishing it from other sibling builder tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The phrase 'for insertion via insert_event_commands' provides explicit context on how to use this tool: generate a command, then insert it. It does not list alternatives or exclusions, but the workflow is clearly implied. This counts as clear context without exclusions, meeting the '4' criterion.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the burden of behavioral disclosure and does well: it states the tool is read-only, returns a { command } object, and explains both show and erase behavior. It could add more about error handling or validation, but for a builder utility this is sufficient.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences, front-loaded with the primary purpose, and uses a compact semicolon structure to convey show vs. erase behavior. No redundant words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given 11 parameters and no output schema, the description covers the key context: insertion via insert_event_commands, read-only nature, return shape, and mode differences. It relies on the schema for parameter details, which is appropriate, though it omits broader context like example usage or constraints beyond schema.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does 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 a concise grouping of show-related parameters and clarifies that erase clears the slot, but it mostly restates per-parameter 'show:' hints already present in the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states that the tool builds Show Picture (231) or Erase Picture (235) event commands for insertion via insert_event_commands. It distinguishes from sibling build_* tools by specifying the exact command codes and listing the relevant parameters for show and erase.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear usage context by stating the output is meant for insert_event_commands and that it is read-only. It does not explicitly name alternative tools or when not to use this tool, but the purpose is unambiguous enough to guide selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Since no annotations are provided, the description carries the full burden. It openly discloses a key behavior: warns (never blocks) when the name is not a known audio asset for that channel. It also states the return shape ({ command, warnings? }). This is valuable beyond the schema and covers important edge-case behavior, but it does not mention other potential behaviors like validation of numeric ranges or interaction with the project state.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences, front-loaded with the core purpose, and every sentence earns its place. It includes essential behavioral details without padding, making it appropriately sized and well structured.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has six parameters and no output schema, but the description compensates by stating the return format ({ command, warnings? }) and the insertion pathway. It also notes the asset-checking behavior. Given that the schema covers all parameter semantics, the description is nearly complete for an AI agent to select and invoke the tool correctly, though it could mention prerequisite project state or validation of numeric fields.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema provides 100% parameter coverage with descriptions for all six parameters, so the baseline is 3. The description adds some context about kind values (BGM/BGS/ME/SE) and name checking, but these are also implied in the schema. It does not materially enhance parameter understanding beyond schema fields.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool builds a Play BGM/BGS/ME/SE event command for insertion via insert_event_commands. It specifies the resource (audio play command) and distinguishes it from sibling builder tools like build_show_text or build_conditional_branch by naming the exact command and insertion path.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context for when to use the tool: to build an audio play event command for later insertion. It mentions checking against list_assets, which implies a precondition, but does not explicitly state alternatives or when not to use it. This is clear context without exclusions, scoring a 4.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the burden of behavioral disclosure. It states 'Read-only: returns { command }', explains wait semantics, and differentiates parameterless vs parameterized effects. It does not discuss validation or error behavior, but the read-only and return-shape disclosure is solid.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two dense sentences, front-loaded with the core purpose, and every clause adds meaningful information—commands, parameters, wait behavior, and read-only status. No filler or redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Covers all effect types, parameter relevance, wait behavior, and the return shape ({ command }). Minor ambiguity: 'wait holds the event until it finishes' could be misread as applying to all kinds, whereas the schema restricts it to tint/flash/shake. Overall, it is complete enough for a builder tool with rich schema.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the baseline is 3. The description adds command codes and groups parameters by kind, but the schema already documents per-parameter applicability (e.g., tint/flash color arrays, shake power/speed). The added value is marginal, not enough to raise the score.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
Description uses a specific verb ('Build') and resource ('screen transition/effect event command'), enumerates the exact command kinds (fadeout/fadein/tint/flash/shake) with command codes, and explicitly mentions insertion via insert_event_commands, distinguishing it from other build_* sibling tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description clearly frames the tool as a builder for insert_event_commands and explains which parameters apply to which effect kind, giving strong contextual guidance. It does not explicitly state when not to use this tool or name alternatives, so it falls short of a 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden. It clearly states this is read-only and returns { commands }, and discloses the event structure (302 + one 605 row per extra good) and the effect of purchaseOnly. This is strong behavioral disclosure, though it could detail error handling or edge cases.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is three sentences: the first states purpose and output, the second explains pricing, the third covers purchaseOnly and read-only behavior. It is front-loaded and every sentence provides useful information without filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (nested goods array, multiple options), the description covers purpose, parameters, output shape, and the need to use insert_event_commands. It lacks an output schema but compensates by specifying the return value. It is complete enough for an agent to select and invoke correctly, though a bit more detail on exact command structure would elevate it.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so baseline is 3. The description adds slight context by explaining that `price` overrides the database price and that purchaseOnly hides the sell tab, but this largely echoes the schema. It does not add substantial new meaning beyond what the schema already provides.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb ('Build') and resource ('Shop Processing event-command sequence'), then clarifies it generates a 302 event plus one 605 row per good. This clearly distinguishes it from other build_* tools like build_battle_processing or build_show_text.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
It explicitly says the output is 'for insertion via insert_event_commands', giving clear usage context. It also explains how each good is priced and what purchaseOnly does, but does not mention alternative tools or when not to use it, so it lacks explicit exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the transparency burden. It explicitly states 'Read-only: returns { command }', disclosing a key behavioral trait beyond the tool's name. It also explains runtime resolution of variable IDs for mapId/x/y when designation='variable'. This is valuable, though it could disclose more about error handling or validation behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is only two sentences, front-loaded with the tool's primary purpose, and every clause adds information. It covers the main action, the insertion context, variable mode, and read-only behavior without waste.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a builder tool with 7 parameters and no output schema, the description adequately explains the tool's function, read-only nature, and variable-resolution mode. It identifies the returned object as { command }. It does not elaborate on all parameter defaults or edge cases, but the schema covers parameter details, and the description provides sufficient high-level context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the baseline is 3. The description adds a brief note that mapId/x/y are variable IDs resolved at runtime when designation is 'variable', which largely reiterates the schema. No additional parameter semantics are provided beyond what the schema already describes.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose with a specific verb ('Build') and resource ('Transfer Player (201) event command'), and it distinguishes itself from sibling build_* commands by specifying it moves the party to (x, y) on a map. It also mentions the intended downstream use ('insertion via insert_event_commands').
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context for when to use the tool: it builds a specific event command for later insertion. It also explains the variable designation behavior, which affects how parameters are interpreted. However, it does not explicitly mention alternatives or when not to use this tool, so it stops short of a 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description shoulders the transparency burden. It discloses side effects: writes a new file, registers in the map tree, allocates the next unused ID, and returns it. It also notes tiles are unpainted. This is clear about the persistent mutation and return value.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
Three concise sentences: action and side effects, return value, and follow-up guidance. Every sentence earns its place with no redundancy or fluff.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a creation tool with 6 parameters, no output schema, and no annotations, the description covers the essential context: what is created, where it's stored, what is returned, and what to do next. It doesn't explain defaults or all parameter relationships, but the schema handles those details.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the baseline of 3 applies. The description does not add parameter-specific semantics, but it does provide context (e.g., blank map implies no initial tiles, ID allocation). This is acceptable given the schema's thoroughness.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'Create a new blank map' with specific resources (data/MapNNN.json, MapInfos.json). It distinguishes itself from sibling map tools like update_map, delete_map, and resize_map by specifying creation and registration behavior.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides explicit follow-up workflow: 'Paint tiles afterward with paint_tiles/fill_area' and 'add events with create_map_event/create_npc.' This implies the tool is for initial map creation and guides subsequent steps. It lacks explicit 'when not to use' statements, but the context is strong.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations, so description carries burden. It discloses a key failure mode (throws on nonexistent stateId) and the dependency on States.json. However, it doesn't mention whether dryRun skips validation, what the return value is, or how new skills are allocated, leaving gaps in behavioral expectations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
Two concise sentences; first defines the tool's purpose with examples, second conveys critical dependency and error condition. No wasted words, front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a 7-parameter create tool with no annotations and no output schema, description is relatively complete. It clearly states purpose, primary failure mode, and prerequisites. It omits return value details and any notes on parameter interactions beyond stateId, but schema covers parameter descriptions. Given CRUD sibling family, this is adequate.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Input schema has 100% coverage for parameter descriptions, giving baseline 3. Description adds semantic constraint that stateId must refer to an existing state and throws otherwise, which is not in the schema. This enhances understanding of the stateId parameter beyond its type/range.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
Description uses specific verb 'Create' targeting 'state-inflicting skill' with examples (poison, sleep), distinguishing it from sibling create_skill, create_damage_skill, create_healing_skill, create_buff_skill. It clearly identifies the resource and purpose.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
States prerequisite: throws if stateId does not exist in States.json, and explicitly directs to create_state first. This provides when-to-use context and points to an alternative/related tool. However, it doesn't explicitly contrast with other skill creation tools, leaving some ambiguity for which skill type to choose.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the burden of behavioral disclosure. It discloses key behaviors like automatic autotiling and re-bordering, and mentions layer defaults. However, it omits mutation aspects (overwriting existing tiles) and does not mention the dryRun preview capability or return behavior. This is a moderate disclosure.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is compact (two sentences) and front-loads the core action, followed by behavior and layer guidance. Every sentence adds value without redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with 8 parameters and no output schema, the description sufficiently covers the main functionality, autotiling behavior, and special handling for regions. It does not explicitly state destructive overwrite behavior, but the overall context is adequate for an agent to proceed.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so baseline is 3. The description adds meaningful semantics beyond schema by explaining that tileId can be an autotile base or raw tile, and specifically how to use layer 5 with region numbers. This enriches parameter understanding.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool fills a rectangular area of a map with one tile id, which is a specific verb+resource. It also distinguishes from siblings like set_map_tile or paint_tiles by emphasizing automatic autotiling and the ability to handle region ids.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does 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 (rectangular area fills with autotiling) and gives guidance for layers, including defaulting to layer 0 and using layer 5 for region ids. However, it does not explicitly name alternative tools or state when not to use it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. 'Get' implies a read-only operation, and the description adds context about the arrays being referenced by index. However, it does not explicitly state that no modifications occur, nor does it disclose any edge-case behaviors or return format details. It is minimally sufficient for a simple read tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence that clearly states the action and then elaborates with a dash-separated explanation. No wasted words; every phrase earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (1 parameter, enum-based, no output schema), the description adequately covers the purpose, the valid categories, and the significance of the data (index references). It does not specify the return array's element types or formatting, but for this simple getter it is likely sufficient.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema already documents the parameter with an enum and description. The tool description adds meaning by explaining that these categories are 'the named lists other data references by index' and that each is a separate array ('one ... array'). This goes beyond the schema's simple 'Which type-name array to read'.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description starts with 'Get one System.json type-name array' — a specific verb and resource. It enumerates all valid categories (elements, skillTypes, weaponTypes, armorTypes, equipTypes) and explains that these are named lists other data references by index, clearly distinguishing it from broader tools like get_system or set_type_name.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies the usage context: when you need a specific type-name array that other data references by index. However, it does not explicitly contrast this with alternatives like get_system or set_type_name, nor provide when-not-to-use conditions. It still gives clear context, so no exclusions are present.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description must disclose behavior. It adds context about what the currency unit affects (display next to gold amounts), but it does not explicitly mention that this setting persists or mutates project state. The mutation is implied by 'Set' but not elaborated.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence that conveys purpose and examples without any fluff. It is perfectly front-loaded and every word earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's low complexity, the description is largely complete: it states what the tool does, provides examples, and the schema covers both parameters (including dryRun). The only gap is not mentioning potential side effects, but for a simple setter this is minor.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does 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 providing concrete examples ('G', 'Gold') for the 'unit' parameter, which helps the agent understand the expected format. It does not address 'dryRun', but the schema already explains it fully.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Set') and resource ('currency unit'), with clarifying context ('shown next to gold amounts') and examples. It clearly distinguishes the tool from any sibling tools, none of which relate to currency units.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description clearly implies when to use the tool (when needing to change the displayed currency unit). No explicit alternatives or exclusions are provided, but the tool's purpose is so specific that alternatives are not necessary.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the behavioral burden. It usefully discloses that the tool returns the updated array and highlights the index 0 convention. However, it does not elaborate on side effects (e.g., immediate disk write), permissions, or reversibility, leaving some gap 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.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences, front-loaded with the action and resource. Every word earns its place; no redundant or vague phrasing.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has 4 parameters and no output schema, but the description covers the return value ('Returns the updated array'), the target categories, and the index convention. It could optionally mention dryRun, but that is already in the schema. Overall, it is complete for the tool's complexity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does 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 semantic value by explaining 'Index 0 is the conventional empty slot', which enriches the meaning of the index parameter beyond the schema's '0 = empty slot'. This extra context justifies a score above baseline.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description uses the specific verb 'Rename' and clearly identifies the resource as 'one entry in a System.json type-name array' with enumerable categories. This distinguishes it from sibling tools like set_term (which likely handles different data) and get_types (which likely reads rather than writes).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context: use this tool when you need to rename a single entry in one of the listed type-name arrays. It does not explicitly mention alternatives or when not to use, but the context is unambiguous given the tool's specialized scope.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full behavioral burden. It discloses two important side effects: growing the variable list when the id is past the end, and that naming makes the variable visible to the next session. It could mention more (e.g., renaming behavior, uniqueness), but the disclosed traits are valuable and non-obvious.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
Three sentences, each earning its place. The first states the action, the second explains a key side effect, and the third gives practical usage guidance. No fluff or redundant information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple setter with well-documented schema, the description covers the essential behavioral nuances (list growth, session visibility) and usage timing. It does not mention return values, but no output schema is needed for a write operation and the description is sufficiently complete for an agent to use it correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% for all parameters, so the baseline is 3. The description adds context about variableId coming from next_free_id, but does not explain the parameters themselves beyond what the schema already provides.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with 'Set a variable name,' which is a specific verb+resource statement. It distinguishes itself from siblings like set_switch_name by clearly targeting variables and adds context about the variable list.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description advises naming a variable immediately after claiming it via next_free_id, and references list_allocated_ids for visibility across sessions. It clearly implies when to use the tool, though it does not explicitly mention alternatives or when not to use it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the transparency burden. It discloses the shallow-merge behavior, refusal on invalid command lists, and the force override. This is useful behavioral context beyond the plain 'update' semantics, though it doesn't describe return values.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, front-loaded with the core verb and resource, then concise details on merge behavior and validation override. Every sentence adds value with zero waste.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description covers the essential behavioral quirks (merge, validation, force) but omits return semantics like summary vs verbose output. However, dryRun and verbose are explained in the parameter schema, so the description is sufficiently complete for the tool's complexity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the baseline is 3. The description adds context about shallow merging and which fields to use, but the individual parameters are already well-documented in the schema. No additional parameter-specific meaning is needed.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool updates a common event's properties via shallow merge, naming specific fields (name, trigger, switchId, command list). This distinguishes it from siblings like create_common_event or call_common_event.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
It gives concrete use cases ('Use for name, trigger, switchId, or to replace the whole command list') which imply when to choose this tool, though it doesn't explicitly mention alternatives or state when not to use it. Clear context but lacks explicit exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden. It discloses the shallow-merge behavior, the return shape `{ enemy, warnings? }`, and a specific validation warning for battlerName not found in img/enemies. However, it omits what happens if enemyId is not found (error vs. null) or any permission/rollback details, preventing a 5.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
Two short sentences front-load the primary action and merge semantics, then provide return format and a key detail. No fluff, every sentence earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description adequately covers the return contract and a notable behavioral nuance (battlerName warning). Given the tool's moderate complexity (nested updates object, dryRun param), it lacks explicit information about error handling or dryRun behavior, but the schema covers parameters and the core usage is clear. This is complete enough for most update scenarios.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, giving baseline 3. The description adds meaningful extra semantics for the `updates` parameter by specifying that a `battlerName` value is validated against img/enemies and warns by default. This goes beyond the schema's generic 'object' description, enhancing parameter understanding.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the specific action ('Update an enemy's properties') and distinguishes it from siblings like create_enemy and update_actor. The key differentiator 'shallow merge into the existing record' adds precision beyond just 'update', making the tool's purpose unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for modifying an existing enemy via its ID, but it does not explicitly state when to prefer this over alternatives like create_enemy or update_actor. No exclusions or alternative tool referrals are provided, so guidance is only implied by the name and context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the burden, and it does well: it states that only provided fields are updated, unknown names only warn (never block), and the tool returns updated settings. This goes beyond the schema and covers the most important behavioral nuances for a mutation tool, though it does not address permissions or reversibility.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is compact, front-loaded with the action, and every phrase earns its place by adding functional detail (partial update, asset validation, return value). No filler or redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given five parameters, nested objects, and no output schema, the description is reasonably complete: it names all update targets, provides asset-source guidance, explains validation behavior, and states the return value. It does not restate dryRun semantics, but the schema already documents that parameter, so the description is sufficient overall.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the baseline is 3. The description groups parameters into background layers and BGM, which helps conceptually, but the individual parameter descriptions already explain each field. The description adds modest semantic value but mainly restates what the schema provides.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description names a specific verb+resource ('Update the title screen') and elaborates the exact aspects it covers: background layers (title1Name/title2Name), BGM, and whether the game title is drawn. This clearly differentiates it from the sibling get_title_screen (read-only) and update_game_title (text-oriented) tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives clear context: fields are sourced from list_assets, only provided fields are changed, and unknown assets produce warnings rather than blocking. It does not name explicit alternatives or exclusion cases, but it implicitly distinguishes this from get_title_screen by focusing on update semantics.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description fully carries the behavioral disclosure burden. It explicitly states the tool is read-only and 'without changing anything', and reports parameter/structure warnings, which clearly communicates side-effect-free behavior and expected output type.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
Two concise sentences: the first states purpose, the second states key behavioral guarantees. No wasted words or repetition.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a low-complexity tool with two simple integer parameters and no output schema, the description sufficiently covers purpose and behavior. It mentions the warning reports but doesn't detail return structure; however, that is not strictly necessary given the simplicity. The read-only assurance adds completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% for both mapId and eventId, which already explain their meaning. The description adds no additional parameter semantics beyond reaffirming the event context, so a baseline of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's function: validating a single event's command lists against a known command table. The verb 'validate' and resource 'single event' are specific, distinguishing it from sibling tools like validate_project and validate_references.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The scope (single event) implies when to use it, but it does not explicitly mention when not to use it or suggest alternatives like validate_project. There is no direct comparison or exclusion, so guidance is implied rather than explicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden for behavioral disclosure. It honestly reveals key behaviors: validation of skillId existence, sorting by level, and a warning (never blocking) when the skill's stypeId lacks a required trait. It even explains the consequence of ignoring the warning (skill-type command never appears, actors cannot use the skill). This is exceptional transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is compact, with the main purpose front-loaded in the first sentence and behavioral details efficiently packed into the second. The parenthetical about the trait is a bit dense but earns its place. No wasted words, though the long second sentence could be slightly split for readability.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has 5 parameters, no annotations, and no output schema, the description adequately covers core behaviors: what it does, validation, sorting, and the important warning. It does not explicitly describe return values or exact error behavior on failed validation, but the description is sufficiently complete for an agent to invoke it correctly in most situations.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the baseline is 3. The description does add some context for 'level' (sorted by level) and confirms the skillId existence requirement already in the schema, but it does not need to compensate for missing parameter info. It adds marginal value beyond the structured schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action: 'Add a "learn skill at level" entry to a class'. It uses a specific verb+resource pattern and distinguishes itself from an alternative hack (attaching skills to actors via an Add-Skill trait), making its purpose unambiguous among many sibling tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear usage context: it is the proper way to add skill learnings to a class, replacing a common hack. It also implicitly warns when not to use it or what prerequisite is needed (the Add Skill Type trait) for the skill to be usable. It does not explicitly name alternative tools, but the context is sufficient.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden and states 'Read-only' and the return shape '{ moveRoute, warnings? }'. It does not elaborate on limits or error cases, but for a read-only builder this is adequate and exceeds the baseline.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences, front-loaded with purpose and key characteristics, then immediately provides usage context. Every sentence earns its place with no fluff.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite having 7 parameters and no output schema, the description explains the tool's role, output shape, and two integration methods. Combined with thorough schema coverage, this provides a complete context for an agent to select and invoke the tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with detailed per-parameter descriptions, so the baseline is 3. The description does not add extra parameter-level meaning beyond the schema, but it does reinforce the 'pattern' parameter and the overall approach, which is acceptable.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool 'builds a movement route from a named pattern', specifying the verb (build), resource (movement route), and scope (from pattern vs raw codes). It also distinguishes itself from raw move-command codes and references sibling tools, making its purpose unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear guidance on how and where to use the output (as an autonomous moveRoute in update_map_event or fed to set_movement_route). It says 'instead of raw move-command codes', implicitly showing when to prefer this tool, though it does not explicitly mention exclusions or alternative build tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It explicitly states the return format `{ partyMembers }` and implies a read-only operation via 'Get' and 'Returns'. This adds useful behavioral context beyond the bare name.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, well-structured sentence front-loaded with the core purpose. It includes the return shape without any wasted words, making it highly concise and clear.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple getter with no parameters and no output schema, the description provides everything needed: what it gets, the return shape, and a useful relationship to set_party. No information appears missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has zero parameters, so the baseline is 4. The description correctly omits parameter details, and the empty schema already communicates that no parameters are expected.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool retrieves the starting party actor IDs, using the verb 'Get' with a specific resource. It also differentiates from siblings by referencing set_party's shape, making the purpose unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The usage context is implied: use this to obtain the starting party. The mention of set_party suggests a pairing, but there is no explicit when-to-use vs alternatives or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full responsibility. It transparently lists the three pieces of information returned (path, validity, game title), which is the core behavioral output. It does not explicitly state that the operation is read-only or has no side effects, but the verb 'Get' strongly implies it, and no contradictory traits are disclosed.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, well-structured sentence that front-loads the verb and resource, then efficiently specifies the exact return values. No redundant words or unnecessary detail.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a zero-parameter getter with no output schema, the description fully specifies the three return fields (path, validity, game title). All essential information is provided, making it complete for an agent to invoke and interpret the result.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, so the schema trivially covers everything. The description adds meaningful context about what entity is being retrieved (the current project) but does not need to explain any inputs since there are none.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Get') and resource ('the project directory the server is currently operating on'), and explicitly enumerates the returned information: path, validity as an RPG Maker MZ project, and game title. This clearly distinguishes it from siblings like set_project (which changes the project) and validate_project (which only checks validity).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies the tool is for retrieving the currently active project ('the server is currently operating on'), but it does not explicitly state when to use this over get_game_title or set_project, nor does it mention any exclusions or alternatives. Usage context is present but not fully elaborated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the transparency burden. It discloses extension stripping, exact reference names, and soft-failure behavior (empty list for unused asset directories). This is meaningful behavioral context beyond a basic 'lists assets' statement.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
Three sentences, each earning its place: action and result, recommended usage, and failure behavior. No redundancy or filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple one-parameter listing tool with no output schema, this description is self-sufficient. It explains what is returned, why it matters, and how failures present, making it fully actionable for an agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema covers 100% of the single parameter with a detailed enum description. The description adds use-case context ('one asset kind', validation) but does not provide new syntactic details beyond what the schema already offers.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with a specific verb and resource: 'List the available asset filenames... for one asset kind'. It also clarifies the exact naming semantics (RPG Maker data references), distinguishing it from sibling list tools like list_names and list_plugin_commands.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly states when to use: 'Use it to validate a graphic or audio name before wiring it into an event; a wrong filename fails silently at runtime.' This is clear context, though it does not name alternative tools or exclusion cases.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden and does so excellently. It discloses that graphic fields merge onto the current image, warns (never blocks) on unknown characterName, and refuses unreachable-event writes unless force:true is passed. These behaviors are critical for an agent to predict outcomes and avoid failures.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single dense sentence that is front-loaded with the main purpose and packs all key behavioral details. It is long but every clause contributes, making it appropriately sized for a tool with 22 parameters, though slightly less structured than ideal.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a complex tool with 22 parameters and no output schema, the description covers the essential behaviors: merge semantics, warnings, refusal conditions, and force override. The response format is partially explained within the verbose parameter schema, so the description is reasonably complete for the context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% and every parameter is described in the input schema. The description adds only high-level grouping (sprite, trigger, priority, movement, flags) and does not introduce meanings beyond what the schema already provides. Baseline 3 applies for high schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool updates an existing event page's graphic and behavior in one call. It distinguishes itself from siblings by explicitly noting it does not rebuild the whole page or touch the command list, separating it from command-insertion tools like add_event_command and insert_event_commands.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies when to use this tool (when you want to update graphic/behavior without rebuilding the page) but does not explicitly name alternative tools or state exclusions. Phrases like 'without rebuilding the whole page or touching its command list' provide clear context but lack explicit alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It does well by disclosing that the tool is read-only, warn-by-default, skips empty/missing directories, and returns a structured result. Still, it doesn't mention potential edge cases like case-sensitivity or path normalization, so it's very good 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.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is packed with useful detail, including a long enum of asset types, an example, a skip condition, and a return format. While it is long, every segment contributes to understanding, and the structure with a colon and semicolons is easy to follow. It is not wasteful, but slightly dense.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description explains the tool's full scope, behavior, and return value ({ ok, warnings[] }). Without an output schema, this is essential. It also notes the complement to validate_references. This is nearly complete for an agent to use the tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, and the input schema reflects that. The description adds value by explaining what the tool scans, but since there are no parameters to document, the baseline of 4 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose with a specific verb ('Audit') and resource ('asset-filename integrity across the whole project'). It also distinguishes itself from the sibling validate_references by explicitly naming what it checks (file presence) versus id integrity, leaving no ambiguity.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does 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 catch filename errors before runtime) and explicitly mentions a complementary alternative (validate_references). However, it does not give explicit 'when not to use' guidance or alternatives beyond the one sibling, so it falls slightly short of a 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden and does well by disclosing read-only behavior, the return shape ('returns { command }'), and per-kind input variants. It does not cover validation or error behavior, but for a command builder that is acceptable.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is only two sentences and front-loads the purpose; each clause adds needed grouping or safety information. It avoids redundant restatement of schema fields and has no filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a 9-parameter tool with no output schema, the description covers return value, target types, and variant-specific required arguments. It leaves default flags like indent, showLevelUp, and allowKnockout to the schema, which is reasonable because the schema documents them.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Although the schema already describes every parameter (100% coverage), the description adds semantic grouping not present in the schema: hp/mp/exp/level use operand, state uses add/remove + stateId, and recover_all takes nothing extra. This helps the agent know which parameters apply to each kind.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with a specific verb ('Build') and resource ('actor stat-change scene command'), explicitly names the six command kinds (hp, mp, state, recover_all, exp, level), and states it is read-only. This clearly distinguishes it from sibling builder tools and event-command manipulators.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
It states the intended usage context ('for insertion via insert_event_commands') and enumerates all supported variants. It does not explicitly name alternative tools or exclusions, but the builder-for-insertion relationship is clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description takes on the full burden and states 'Read-only: returns { commands }', which informs the agent that this tool has no side effects. It also discloses the block composition and termination behavior, adding useful behavioral context beyond the schema.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single dense paragraph that packs in the block structure, condition types, branch handling, insertion target, and read-only nature without any filler. Every sentence earns its place and key information is front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the moderate complexity and rich schema, the description covers the essential usage pattern, return format, and side-effect profile. It could mention error cases or branch termination details more explicitly, but the provided text is sufficient for an agent to correctly select and invoke the tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema covers all parameters with descriptions, so the baseline is 3. The description adds extra meaning by explaining that branches are EventCommand arrays and that the elseBranch presence adds the 411 block, and clarifies the return shape. This supplements the schema with builder-pattern context.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool builds a Conditional Branch block with specific command codes (111, 411, 412) and lists supported condition types. This distinguishes it from sibling builders like build_show_text or build_control_switch by naming the exact resource and structure.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
It explicitly says the output is for insertion via insert_event_commands, which is the intended usage context. It also tells users to provide branches as EventCommand[] from other builders, but it doesn't explicitly contrast with alternatives or state when not to use it. Still, the insertion target and branch construction guidance provide clear context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden, and it discloses the key behavioral trait: 'Read-only: returns { command }.' It also explains the behavior of both scopes and the inclusive range semantics, adding context beyond the function name.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is three concise sentences, front-loaded with purpose. It specifies both modes, the range behavior, and the read-only return value without any wasted words or repetition.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given 100% schema coverage and no output schema, the description sufficiently explains the tool's modes, the range behavior, and the return shape. It doesn't discuss error cases or prerequisites, but for a read-only builder of this complexity, the information is adequate.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the baseline is 3. The description adds meaning by explaining that scope 'switch' sets a switch or inclusive range (switchId..endId) and scope 'self_switch' sets A–D, which enriches the understanding beyond the per-parameter schema descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description uses the specific verb 'Build' and clearly identifies both event command types (Control Switches 121 and Control Self Switch 123). It also ties the tool to 'insertion via insert_event_commands,' distinguishing it from other build_* tools and specifying its exact role.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
It clearly states the tool is for building event commands to be inserted via insert_event_commands, and explicitly differentiates the two scopes ('switch' vs 'self_switch'). It lacks explicit exclusions or alternative tool names, but the context is sufficient for an agent to understand when to use it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are present, so the description carries the burden. It discloses the file destination, default field values, allocation of the next unused id, and the refusal-to-write behavior for invalid command lists with force override. This is substantial, though it could mention potential side effects or prerequisites like a loaded project.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is three sentences, front-loaded with the core purpose, and every sentence adds meaningful information (defaults, id allocation, validation/force). No redundant or filler content.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with 7 parameters and no output schema, the description plus schema cover creation, defaults, validation, force, and return id. It lacks explicit mention of project dependency or duplicate-name behavior, but these are minor gaps given the overall richness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the baseline is 3. The description adds value by explaining defaults for omitted fields (empty command list, trigger 0, switchId 1) and the force override behavior, which are not fully captured in the schema. This elevates it above baseline.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's function: 'Create a new common event (reusable event-command list) in data/CommonEvents.json.' It uses a specific verb ('Create') and resource ('common event'), and distinguishes itself from sibling tools like update_common_event and call_common_event by focusing on new creation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides clear usage context: only `name` is required, omitted fields use defaults, and `force: true` overrides validation. However, it does not explicitly mention when to use this instead of update_common_event or other alternatives, so it stops short of full when/when-not guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden and performs excellently. It discloses that omitted fields use editor defaults, specifies those defaults (no restriction, priority 50, no auto-removal, 1-turn duration), and states that it allocates and returns the next unused state id. This is highly transparent about behavior and side effects.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is three brief sentences, each with a distinct purpose: what the tool does, default behavior, and return value. No redundancy or filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite the tool's complexity (24 parameters, no output schema), the description covers essential contextual aspects: creation target, required fields, defaults, and return ID. This is sufficient for an agent to use the tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
All 24 parameters have schema descriptions, giving 100% coverage. The description adds value by explaining the defaults for omitted fields, which the schema does not convey, thus supplementing the schema meaningfully.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool creates a new state (status condition) in data/States.json, with a specific verb and resource. However, it does not explicitly contrast with sibling tools like update_state, so it does not fully distinguish from alternatives.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explains that only name is required and omitted fields use editor defaults, providing clear usage context. It does not mention when to use this versus update_state or other alternatives, but the creation purpose is straightforward and no exclusions are stated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It discloses the write target (data/Weapons.json), default behavior for omitted fields, the stat bonus array order, and the id allocation behavior. This is meaningful context beyond the schema, though it doesn't mention the dryRun preview parameter.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is compact at four sentences, each serving a purpose: main function, defaults, params format, and return behavior. No redundant text.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description covers essential aspects: target file, required field, defaults, param structure, and return value. Given 10 parameters and no output schema, it provides sufficient context, though it omits mention of the dryRun parameter, which is documented in the schema.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does 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 `name` is the only required field, what defaults apply to omitted fields, and explicitly defining the `params` array order and length, exceeding the baseline.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
Clearly states 'Create a new weapon in data/Weapons.json' with a specific verb and resource. The mention of allocating the next unused id distinguishes it from sibling tools like update_weapon and other creation tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description clarifies that only `name` is required and that omitted fields use editor defaults, providing clear context for when to invoke this tool. It doesn't explicitly name alternatives like update_weapon, but the creation context is self-evident.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It discloses the read-only nature, the isolated-tile semantics (an important behavioral caveat), and the exact return shape. It does not mention error handling or invalid inputs, but for a simple read tool this is sufficient.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
Three sentences, front-loaded with the core action and output structure. Every sentence earns its place: purpose, read-only caveat with alternative, and return format. No filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description covers the purpose, relevant caveats, and return value. It explicitly notes the distinction from check_passability, which is essential given the sibling list. Minor omissions like invalid IDs or default flag values do not significantly hinder understanding, especially with the output shape stated.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already documents both parameters. The description adds a little semantic context ('tile id' and 'tileset id') but does not meaningfully extend 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.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with a specific verb ('Decode'), identifies the resource ('a tileset's flag word for a single tile id'), and details the output (passability directions, star bit, ladder/bush/counter/damage-floor flags, terrain tag). This clearly differentiates it from sibling tools like describe_tile or check_passability.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly states when to use ('read-only inspection of data/Tilesets.json flags[]') and when not to use: 'a real cell's passability layers its stacked tiles — use check_passability for that.' This gives direct alternative guidance and exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations available, the description carries the transparency burden. It discloses the cheap token cost, names-only nature, and the exact return format. It does not mention ordering or pagination, but for a simple list tool the provided behavioral details are meaningful and go beyond what the schema offers.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, front-loaded with the key phrase 'Cheap names-only index', and every word earns its place. No fluff or redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple single-parameter list tool, the description sufficiently covers purpose, return format, and use case. It doesn't specify whether all rows are returned or sorting, but given the simple scope and rich schema, it is nearly complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema already has 100% coverage with a self-explanatory enum and per-parameter description. The tool description adds no additional details about the 'type' parameter, so the baseline of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
Clearly states a specific verb ('list') and resource ('names-only index for a database table'), describes the return shape as {id, name}, and differentiates itself from full get_*/search_* dumps. This is specific and distinguishes it from sibling tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly states when to use: for looking up or sanity-checking IDs before wiring them into events. It contrasts with the more expensive 'full get_*/search_* dump', implying the alternative when full records are needed, thus providing clear usage context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden and excels: it declares the tool is read-only, details the two-half-column layout behavior, specifies error conditions (throws if topLeftId isn't flat or rectangle runs off the 16×16 sheet), and warns if the tileset lacks the sheet. This is comprehensive behavioral disclosure for a compute utility.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is compact for the complexity involved, with four sentences each serving a distinct purpose: main action, layout caveat, input source, and error/read-only behavior. It is front-loaded with the core action. Slightly verbose due to explaining the layout quirk, but every sentence earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given 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 fully contextualizes the tool: what it does, why it's needed (the tricky layout), where inputs come from, how to use the output, and error/warning behavior. It is self-contained for an agent to invoke correctly without additional context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the baseline is 3. The description adds little beyond the schema: it references the top-left id source and the layout quirk, but the schema already states the topLeftId is a 'Raw flat tile id' from find_tile/get_tile_catalog. Width/height are already described as dimensions. No significant semantic enrichment.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Expand') and clearly identifies the resource (a top-left flat tile id plus width×height into a grid of tile ids). It also distinguishes this tool from siblings like place_object by explaining that the returned tiles feed directly into place_object. The mention of the unusual sheet layout further clarifies the tool's unique role.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description states when to use it ('feed the returned tiles straight into place_object') and provides a prerequisite source for the input ('Get the top-left id from find_tile/get_tile_catalog'). It implies this tool simplifies manual computation, but it does not explicitly name alternatives or say when not to use it, so it stops short of a 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It discloses the important side effect that neighbors' shapes are recomputed from same-kind adjacency when autotiles are used, and that flat tiles are painted as-is. It also explains the layer default and the distinction from set_map_tile. However, it doesn't mention potential edge cases like overwriting behavior or what happens with layer 4/5, though these are partially in the schema.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is three sentences, front-loaded with the core purpose, then explains the autotiling algorithm, then the alternative tool. Every sentence adds relevant information with no filler or repetition.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is moderately complex due to autotiling, and the description covers the algorithm, the layer default, and a close sibling. It doesn't mention the dryRun parameter, but that's documented in the schema. Given no output schema and good annotations in the schema, the description is reasonably complete for the agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, and the schema already explains layer ranges and tileId semantics (autotile base id or raw id). The tool description mostly restates the default layer and tileId kind, adding little beyond the schema. It does mention 'cells to paint' for the tiles parameter, but that's also evident from the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool paints specific tiles onto a map with automatic autotiling. It specifies the exact behavior (cell set to tile id, autotile shape recomputation) and distinguishes itself from set_map_tile by noting it is higher-level and handles multiple tiles with autotiling.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly names set_map_tile as a lower-level alternative that does a single raw tile with no autotiling, providing clear when-to-use guidance. It also notes the default layer, helping the agent decide if layer needs to be specified.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It does so richly: repadding every z-layer, preserving tiles on overlap, blank new cells, cropping on shrink, and warning about events outside new bounds. It stops short of stating whether warned events are deleted or kept, and does not confirm the write-to-disk/commit behavior beyond the dryRun param.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
Three dense sentences, each earning its place: the core action with precise overlap/crop semantics, the critical alternative contrast, and the event-warning behavior. Dense and front-loaded with zero fluff.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema, the description compensates well by thoroughly covering behavioral complexity (z-layer repadding, overlap/crop semantics, the only-safe-route contrast, event warnings). It does not explicitly describe the response summary/record shape or confirm immediate persistence, but the verbose parameter in the schema partially covers return behavior.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% — all 5 parameters (mapId, width, height, dryRun, verbose) have their own descriptions in the schema, so the baseline is 3. The description's "new width/height" adds little beyond the schema's "New width/height in tiles," and dryRun/verbose semantics are fully documented in the schema itself.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with a specific verb+resource combination: "Resize a map to new width/height, safely repadding every z-layer of its tile data." It also explicitly distinguishes from siblings: "This is the ONLY safe way to change a map's dimensions — update_map refuses a width/height change because it would not resize the tile array."
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives explicit when-to-use guidance: "This is the ONLY safe way to change a map's dimensions," and names the specific alternative (update_map) and why it is unsuitable for this purpose. The note about event warnings also clarifies a behavioral condition users should expect.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the transparency burden. It discloses important behaviors: structurally invalid routes/pages refuse the write with nothing saved, force overrides validation, and the 505 continuation rows are included. It also clarifies the characterId special values. Lacks mention of success return values, but key behavioral traits are covered.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is compact and front-loaded with the main purpose. It efficiently packs essential details—event command numbers, characterId meaning, dependency, and validation behavior—without any fluff or repetition. Every sentence contributes useful information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a complex tool with 9 parameters, nested objects, no output schema, and no annotations, the description covers the core purpose, key parameters, and important safety/validation behavior. It does not mention what the tool returns on success, which would be useful, but the schema covers all parameters and dryRun behavior, making the description sufficiently complete for invocation decisions.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, providing a baseline of 3. The description adds value by explaining characterId semantics (-1 player, 0 this event, N event id) and instructing to pass a moveRoute from create_move_route, which goes beyond the schema's generic descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the specific action: inserting a forced 'Set Movement Route' event command (205 plus 505 continuation rows) into an event page's command list. It distinguishes itself from siblings like create_move_route by describing the command insertion context with precise technical details.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
Description says to 'Pass a moveRoute from create_move_route', establishing a clear prerequisite and workflow. It also explains the validation refusal and force override condition. However, it does not explicitly name alternatives or when-not-to-use scenarios, though the context is evident.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the burden of disclosure. It reveals key behaviors: the override lasts until server restart, and the directory must contain specific required files (game.rmmzproject and data/System.json). This is more than minimal but doesn't detail error handling 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.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, front-loaded with the primary purpose, then caveats. Zero redundant words; every clause adds useful detail.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a single-parameter setter, the description covers the essential context: what it does, the session scope, and the prerequisites. It doesn't explicitly mention return values, but given the simplicity and absence of an output schema, this is acceptable.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the baseline is 3. However, the tool description adds extra semantic value by specifying the directory must contain game.rmmzproject and data/System.json, and by clarifying it's a *different* directory. This enriches the bare schema definition.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states a specific action ('Point the server at a different RPG Maker MZ project directory') and resource ('RPG Maker MZ project directory'). It distinguishes itself from siblings like get_project or validate_project by focusing on switching the working directory.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides clear context: it affects the rest of the session and overrides the RPGMAKER_PROJECT_PATH environment variable. No explicit alternatives are named, but the intended use case (changing the active project) is clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden. It discloses that this is a write operation ('Edit') and adds important behavioral constraints: every referenced map must exist, non-zero parentId must exist, and the tree must stay acyclic. It also scopes the effect to MapInfos.json only, which is valuable context beyond the schema.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences. The first sentence states purpose and scope, the second adds batch and validation context. No wasted words; every clause earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is moderately complex with batch updates and validation rules. The description covers the core purpose, scope, and constraints. The schema fully documents the parameters, including dryRun behavior. A minor gap is that the description doesn't mention the return diff for dryRun, but the schema covers it, so the description is sufficiently complete for selecting and invoking the tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so baseline is 3. The description adds semantic value by explaining the batch nature ('takes a batch of per-map updates') and the validation rule about existing maps and acyclicity. This goes beyond the individual property descriptions in the schema, reinforcing how the parameters interact.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'Edit', the resource 'map tree (MapInfos.json)', and the specific operations 'reparent, reorder, rename, or expand/collapse maps'. It explicitly distinguishes from other map tools by adding 'only' and 'without touching their tiles or events', which helps differentiate it from siblings like update_map and get_map_infos.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context on when to use this tool: for editing the map tree structure, not for map tiles/events. It does not explicitly name alternative tools, but the 'only' and 'without touching' phrasing implies exclusions that separate it from update_map and similar tools. The batch and validation constraints also give practical guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It explicitly states 'Read-only: returns { command }', which is essential behavioral information for an agent. It also discloses that includeEquip counts equipped copies when removing, giving insight into the tool's behavior beyond its basic function.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences with no wasted words. The first sentence presents the core purpose and insertion mechanism, while the second adds a key edge case and the read-only behavior. This is appropriately sized and front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a builder tool with no output schema and no annotations, the description provides complete context: it explains what is built, how it will be used (insert_event_commands), the relevant parameter nuance (includeEquip), and the return shape. Nothing essential is missing for an agent to correctly select and invoke this tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the baseline is 3. The description adds value by summarizing the overall gain/lose semantics and clarifying the includeEquip parameter's behavior (equipped copies when removing), which goes beyond individual field descriptions. This additional context helps the agent understand how the parameters interconnect.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Build') and identifies the exact event commands ('Change Items (126), Change Weapons (127), or Change Armors (128)'), clearly distinguishing it from other build_* sibling tools. It states the action (gain/lose an item/weapon/armor) and the mechanism (constant or variable amount), making the tool's purpose unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description says this builds a command 'for insertion via insert_event_commands,' which gives clear context on when to use it. It also notes the includeEquip caveat for weapons/armors, but does not explicitly state when not to use it or alternatives. However, the build_* family is well-defined, and the purpose itself implies the appropriate use case.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description appropriately discloses 'Read-only' and the return shape '{ command }'. This communicates that the tool has no mutation side effects and gives a clear behavioral boundary, though it doesn't detail error cases or further side effects.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences, front-loaded with purpose, and every element contributes: the four kinds, their IDs, the insertion relationship, and the read-only note. No filler or redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's moderate complexity and 100% schema coverage, the description provides sufficient context. It explains what is built, the available kinds, the insertion workflow, and the return shape, while relying on the schema for detailed parameter syntax.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does 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 mapping numeric command IDs to each kind ('wait (230...'), clarifying that label/jump_to_label take a 'named jump target', and indicating 'N frames' for wait. This ties the parameters to actual usage beyond the schema's basic field descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's verb ('Build'), resource ('flow-control event command'), and purpose ('for insertion via insert_event_commands'). It enumerates the four specific command kinds with numeric IDs, distinguishing it from sibling builders like build_show_text or build_conditional_branch.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explains that this tool builds commands for later insertion via insert_event_commands, providing clear context for when to use it. It doesn't explicitly list when not to use it, but the 'flow-control' scope plus the named sibling alternatives imply the differentiation.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the burden of disclosure. It reveals important behaviors: omitted fields get defaults (Shield equip slot, no stat bonuses), param format, and that it allocates and returns the next unused armor id. These go beyond the schema but do not mention potential side effects like dryRun behavior 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.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
Three compact sentences, front-loaded with the main action and file target. No redundant wording; every sentence provides essential information (purpose, defaults, param semantics, id allocation).
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite 10 parameters and no output schema, the description gives sufficient context for correct use: it explains defaults, key parameter semantics, and the return value (next unused id). The schema covers the remaining parameter details, making this complete for a creation tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so baseline is 3. The description adds value by clarifying defaults for omitted fields and reinforcing the meaning of `params` and `etypeId` with the exact stat order and equip slot mapping. It goes beyond just restating the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool creates a new armor in data/Armors.json, using a specific verb and resource. It distinguishes from siblings like update_armor and create_weapon by specifying the armor data file and the creation context.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides clear usage context: only `name` is required and omitted fields use editor defaults. This implicitly guides when to use the tool (creating a new armor) but does not explicitly contrast with update_armor or other alternatives, so it lacks explicit exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the burden of disclosing behavioral traits. It does disclose defaults, write location, validation refusal, and the force override. It does not mention the dryRun or verbose return behaviors, though those are covered in the schema descriptions. This is strong 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.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is three sentences of dense, front-loaded information with no filler. Every clause contributes meaning: creation target, defaults, validation constraint, and override behavior. This is an exemplar of concise, well-structured documentation.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a 6-parameter create tool with no output schema, the description plus rich schema descriptions paint a complete picture. The description covers creation behavior, defaults, validation failure handling, and an override path. The schema even explains return summary via the `verbose` parameter. No significant gaps remain.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 100% coverage, so the baseline is 3. The description adds value beyond the schema by clarifying that `name` is required, stating default values for `members` and `pages`, and specifying the referential integrity constraint for `member.enemyId`. This goes beyond what the schema provides.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Create') and the resource ('a new troop (enemy battle group) in data/Troops.json'). It distinguishes itself from sibling tools like create_enemy by explicitly identifying troops as enemy battle groups, and from update_troop by focusing on creation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides useful usage context: it notes that `name` is required, that `members` must reference existing enemies, and that a structurally invalid battle-event page will refuse the write unless `force: true` is passed. However, it does not explicitly mention when to prefer this over related tools like create_enemy or create_battalion, so it stops short of a 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations exist, so the description carries full burden. It discloses read-only behavior, the exact return shape, and the nuanced transparency flag semantics: 'true = the tile is see-through and needs an opaque base tile on a lower layer; painting it on layer 0 alone shows the map void.' This is thorough behavioral context.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is dense but structured: first the core decoding behavior, then read-only context, return shape, and optional parameter effect. Each sentence earns its place, though it is slightly longer than minimal.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema, the description provides the return object fields, which is essential. However, some fields like 'empty' and 'kind' are not defined, leaving minor gaps. For a moderately complex decode tool, this is acceptable but not exhaustive.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does 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 beyond the schema by explaining that passing tilesetId triggers PNG inspection and reports 'transparent' and 'transparentPercent', giving meaningful context about the optional parameter's effect.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description uses the specific verb 'decode' and clearly identifies the resource: a raw RPG Maker MZ tile id. It details the output (tileset sheet A1–A5, B–E, autotile kind/shape/geometry) and frames itself as a read-only inspection helper, distinguishing it from sibling tools like paint_tiles or get_tile_flags.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description clearly states the context: 'Read-only inspection helper — raw tile ids are opaque integers, this makes one legible.' This implies when to use it (to understand a raw id) but does not explicitly name alternatives or exclusion cases, so it falls short of a 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It reveals key traits: default stamping on layer 2, zero cells left untouched, warn-by-default with no refusal, use of tileset flags for warnings, and return of per-cell passability plus collision cells. This is exceptionally transparent.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is dense but well-structured. It front-loads the main purpose and uses backticks and parentheticals to keep information tight. While longer than the TDQS 4.3 example, every sentence contributes critical detail without redundant fluff.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with no output schema, the description clearly states the return values (per-cell passability and collision cells) and warns about the non-autotiling behavior. It also references related tools for tile IDs. Minor gaps remain, such as not mentioning the dryRun parameter's behavior in the description (though the schema covers it), but overall it is complete for the tool's complexity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema already describes all parameters (100% coverage), but the description adds meaningful context: the `tiles` array orientation (rows top-to-bottom, left-to-right) and the meaning of 0 (transparent cell), plus the default layer value of 2. This goes beyond the schema descriptions and materially aids correct invocation.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with a specific verb+resource: 'Place a multi-tile B/C object... on a map and report its passability.' It includes concrete examples (house, tree, fountain) and explicitly differentiates from the sibling tool paint_tiles by stating it does NOT autotile.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly contrasts with paint_tiles ('Unlike paint_tiles this does NOT autotile'), providing clear context for choosing this tool. It also tells the user to get tile IDs from find_tile/get_tile_catalog. However, it does not enumerate specific scenarios where other alternatives (e.g., fill_area, object_tiles) would be preferable.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Explicitly states 'Read-only' and describes the output as aggregated map-tagged warnings, disclosing side-effect-free behavior and return format. No annotations are present, so this description carries the burden, and it does so adequately.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, direct and informative. First sentence states the action; second adds read-only and output. No wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no parameters and no output schema, the description still conveys the tool's scope, behavior, and return type. It is sufficient for an agent to decide when and how to invoke it.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Tool has zero parameters, so description has no parameter semantics to explain; baseline 4 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
Clearly states it validates event command lists for every map in the project. Distinguishes from sibling validation tools by scope ('every map') and target ('event command lists').
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides context that it is read-only and intended for auditing before or after batches of edits, which implies usage timing. However, it does not explicitly name alternative tools like validate_event or validate_references, so not a full 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full responsibility for behavioral disclosure. It explicitly states 'Read-only: returns { command }', which reveals that the tool has no side effects and only returns a data structure. It also clarifies that the command is meant for insertion via insert_event_commands, implying it does not automatically apply changes. This goes beyond what the schema or annotations would provide.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences, front-loaded with the primary purpose, and every piece of information contributes to understanding the tool's function. It avoids repetition of schema fields and wastes no words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (nested operand object, 5 parameters, no output schema), the description covers the core behavior, return shape, range semantics, and operand categories. It does not explain how to configure game_data parameters in detail, but that is partially handled by the schema and the 'see corescript' hint. Overall, it provides sufficient context for an agent to use the tool correctly in the majority of cases.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the parameters are already documented. The description adds valuable semantics by explaining the inclusive variableId..endId range behavior, the supported operation types (set/add/sub/mul/div/mod), and the four operand sources (constant, variable, random, game_data). This exceeds the baseline and helps the agent map high-level intent to schema fields. Minor gap: game_data sub-parameters are not detailed in the description, but the schema references 'corescript'.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Build') with a concrete resource ('Control Variables (122) event command') and explicitly states its purpose ('for insertion via insert_event_commands'). This clearly distinguishes it from sibling builder tools like build_show_text or build_conditional_branch, which target different event command types.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context: this tool constructs a command for later insertion via insert_event_commands. It implies the tool should be used to prepare a command rather than directly modify the game. However, it does not explicitly mention when not to use it or name alternative tools for similar operations (e.g., build_control_switch for switches).
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description shoulders the full disclosure burden. It declares 'Read-only' and explains the layered evaluation order, output fields, and optional direction behavior, giving the agent a complete picture of side effects and return semantics.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is three sentences, front-loaded with the primary purpose, and each sentence adds necessary detail about procedure, output, and read-only nature. It is dense but not wasteful, though it could be slightly tighter around the return value list.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given 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 fully compensates by listing all return values (per-direction booleans, terrain tag, stacked tile ids, optional passable), explaining the algorithm, and stating read-only behavior. There are no factual gaps for selecting/invoking the tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Although the schema has 100% coverage with descriptions for all four parameters, the description adds meaningful context by explaining how x/y are used in the tile stack lookup, how the optional direction alters the return value, and what the mapId refers to ('Reads the map's tileset flags'). This exceeds the schema's minimal descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with a clear action ('Check whether a map cell can be walked onto') and specifies the exact scope (layered passage rule per direction). It distinguishes itself from tile-reading tools like get_tile_flags by detailing the algorithm and output.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
It provides clear context by explaining that this tool reproduces the engine's layered passage rule and reads tileset flags, implying it is the correct choice for movement/passability checks. However, it does not explicitly name alternatives or state when not to use it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so the description carries the burden. It discloses that unknown characterName or missing graphic only warns, never blocks; that an NPC without characterName is invisible in-game; and that commands wins over text. This is substantial behavioral context, though it does not mention return values or side effects on success.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
Four sentences, front-loaded with the core purpose, each sentence adds distinct information (modes, defaults, warnings, alternative). No fluff.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For an 18-parameter tool with no annotations and no output schema, the description covers purpose, modes, defaults, edge cases (invisible NPC), and alternative tools. It lacks only an explicit description of return value or success/failure response, but overall is quite complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
All 18 parameters have schema descriptions (100% coverage), so baseline is 3. The description adds value by explaining the relationship between `text` and `commands` (commands wins), how `text` is built into Show Text with optional face/speaker, and defaults for trigger, priority, direction. This exceeds baseline.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb+resource ('Create a complete, placed NPC event on a map in one call') and clearly distinguishes from sibling create_map_event by noting the invisibility issue and explicitly referencing it for intentionally-invisible triggers. The 'one-shot' primitive characterization further clarifies its scope.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly states when to use versus create_map_event ('use create_map_event for an intentionally-invisible trigger'), and explains the precedence of `commands` over `text` when both are given, plus defaults like action-button trigger and solid priority. This is clear guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the burden of disclosing behavioral traits. It honestly warns that the data array can be huge and blow the token limit, explains the dataTileCount alternative, and notes the default of includeData. This is valuable disclosure of a significant behavioral trait, though it doesn't cover other potential behaviors like error handling or exact response structure.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is three sentences, front-loaded with the primary purpose, followed by a critical caveat and the default behavior. Every sentence earns its place: no filler, no repetition, and it is compact while conveying essential usage details.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (2 parameters, no output schema), the description addresses the most significant contextual concern—the token limit and how to mitigate it with includeData and get_map_region. It also hints at the output via 'dataTileCount,' but it doesn't fully describe what the map data includes or any expected response format, leaving a slight gap in completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the baseline is 3. The description adds meaning beyond the schema by explaining why includeData exists (token limit), what the data array size formula is (width*height*6 ints), and that passing false gives dataTileCount. It also clarifies the default behavior, enhancing the parameter semantics beyond the schema's own description.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description begins with 'Get map data by ID,' which is a specific verb plus resource, clearly indicating the tool's function. It distinguishes itself from siblings like get_map_region by explicitly contrasting the use of get_map_region for reading tiles when includeData is false. This makes the tool's scope unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit when-to-use guidance by explaining the token limit issue and instructing to pass includeData:false to avoid it, and to use get_map_region for reading tiles. It also notes the default behavior for backward compatibility, giving clear context on how to invoke the tool correctly versus alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It reveals a non-obvious side effect: 'Grows the project's switch list if the id is past the end (padded to the editor's 20-slot block)' and explains that naming a switch 'makes it visible to the next session.' This is rich, useful context beyond what the schema or annotations provide.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise, front-loaded with the core action, and every sentence adds value: the mutation effect, the id relationship, and the visibility tip. It avoids redundancy and remains easy to scan.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the low complexity, no annotations, and no output schema, the description covers purpose, side effects, and usage guidance quite well. It doesn't explicitly mention return values or error conditions, but for a simple set operation, this is not a major gap. It is generally complete for an agent to use the tool effectively.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, but the description adds meaningful context to the switchId parameter by explaining that ids from next_free_id are always valid and how list growth/padding works. This goes beyond the schema's simple '1-based switch ID' definition, though it doesn't elaborate on name or dryRun beyond what the schema already states.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description begins with 'Set a switch name,' a specific verb+resource statement that clearly identifies the action. It further elaborates on the behavior of growing the switch list, which distinguishes this tool from sibling set_* tools like set_variable_name or set_type_name by focusing on switches.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context on when to use this tool: 'an id from next_free_id can always be labelled' and 'Naming a switch as soon as you claim it.' It also references list_allocated_ids for related actions. However, it does not explicitly state when not to use it or name alternative tools for exclusion, so it falls short of a 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden. It discloses the shallow-merge behavior, the warning condition (code 41) when a learned skill lacks a trait, and the ability to replace arrays. It does not mention return values, permissions, or error handling, but provides strong behavioral insight for an update operation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
Three sentences, each earning its place: first defines the operation, second gives usage guidance, third describes a specific warning. No fluff, perfectly front-loaded with the core purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given 3 parameters, a nested object, no output schema, and no annotations, this description covers the essential aspects: what the tool does, when to use it, and key behavioral nuances. It does not explain return values, but for a tool with clear update semantics, this is sufficient. The alternative suggestions further enrich context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does 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 enumerating typical updatable properties (name, expParams, traits, learnings/params) and explaining the shallow-merge semantics, which clarifies how the 'updates' object is interpreted beyond the schema's generic description.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool updates a class's properties via a shallow merge, with a specific list of use cases (name, expParams, traits, learnings/params arrays). It explicitly distinguishes itself from siblings by recommending add_class_learning and set_class_param_curve for targeted edits, making the purpose highly specific and unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit guidance on when to use this tool versus alternatives: use it for general property updates or replacing whole arrays, but prefer targeted tools for individual learnings/param curves. This directly addresses tool selection and avoids misuse.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden and does so admirably. It discloses shallow merge semantics, member validation, and the critical failure behavior where structurally invalid writes are refused and nothing is saved, plus the force override. This goes well beyond a basic 'update' statement.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
Two efficiently written sentences. The first states the purpose and merge behavior; the second covers validation and safety. Every word adds value, with no redundancy or filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is complex with nested objects, validation, and failure modes. The description covers the key behavioral aspects well, including scope and safety. It does not explicitly describe the success return format, though the schema's `verbose` parameter hints at it. This is a minor gap given no output schema, so a 4 is appropriate.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the baseline is 3. The description adds valuable semantic detail beyond the schema by explaining that updates are shallow-merged and that members are validated. This enriches the `updates` parameter and the `force` parameter, justifying a score above baseline.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Update') with a clear resource ('a troop's properties') and adds the scope note '(shallow merge)', which differentiates it from create or replace operations. This clearly distinguishes it from sibling tools like create_troop or update_actor.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description clearly implies when to use this tool: to modify an existing troop's properties. It also provides context about validation and the force override. However, it does not explicitly name alternatives or state when not to use it, so it stops short of a 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It discloses read-only behavior, warn-by-default semantics, the specific checks performed, and the return shape ({ ok, warnings[] }). This is transparent and goes beyond what a bare schema would convey.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, dense sentence that front-loads the core purpose and then lists specific checks. It is long but each clause adds concrete value (what is checked, the comparison to validate_project, and the return signature). No wasted words, though it could be slightly more scannable.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given there are no parameters, no output schema, and no annotations, the description provides a complete picture: what the tool does, its safety profile, its relationship to a sibling, and its return value. For a validation tool, this is sufficient for correct invocation and interpretation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, so the input schema is empty and schema coverage is 100%. The description naturally cannot add parameter meaning, but the baseline for 0-parameter tools is 4, and it does not need to compensate for anything. The return type is mentioned, which is helpful.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Audit') and resource ('cross-file reference integrity') and enumerates detailed checks (Transfer Player targets, starting position, party/actor classes, skills, troop members, drops, effects, map tree cycles). It explicitly distinguishes itself from the sibling validate_project by stating complementarity and scope ('Complements validate_project (which checks command shape)').
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description clearly states this tool performs a read-only, warn-by-default audit and explicitly contrasts with validate_project, giving the agent a clear sense of when to use this versus that sibling. However, it does not mention other related validation tools like validate_event or validate_assets, so the guidance is not exhaustive but still useful.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden and does well: it states 'Read-only: returns { command }', clearly disclosing that the tool has no side effects and returns a command object. It also explains how canEscape/canLose gate battle result branches, adding behavioral context beyond the schema.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences, front-loaded with the core purpose, and every clause adds value—purpose, parameter behavior, and read-only nature are all conveyed without redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's moderate complexity, the description covers the essential points: what it builds, how it integrates with insert_event_commands, the key parameter modes, and the return shape ({ command }). The absence of an output schema is compensated by explicitly stating the return value.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the baseline is 3. The description adds meaningful semantics by explaining the three troop selection modes (direct id, variable, random) and how canEscape/canLose affect branches, going beyond the schema's per-parameter descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool builds a Battle Processing (301) event command, with a specific verb ('Build') and resource ('Battle Processing event command'). It also distinguishes this from sibling builders by naming the exact event command type and connecting it to insertion via insert_event_commands.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly places usage in the context of insertion via insert_event_commands, providing clear context. However, it does not name alternatives or explicitly say when not to use this tool, falling short of a 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full behavioral disclosure. It clearly states 'Read-only' and specifies the return shape '{ commands }'. It also warns about branch termination details, giving agents the structural knowledge needed to predict output.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences deliver the core purpose, structure, usage pointer, and return info. No filler; the information is front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For an 8-param builder with full schema coverage and no output schema, the description covers the essential missing pieces: the block's internal structure, insertion workflow, and return value. It's sufficient for an agent to invoke correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the baseline is 3. The description adds cross-reference value by explaining the `branches` parameter can come from build_show_text and that each branch is an EventCommand[], reinforcing the relationship. This is a modest enhancement over the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with a specific verb ('Build') and names a distinct resource ('Show Choices block'), then enumerates the exact command structure (102, 402, 403, 404), differentiating it from sibling builders like build_show_text and build_conditional_branch.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
It explicitly states this block is 'for insertion via insert_event_commands' and suggests using build_show_text to create branch bodies, offering concrete workflow context. It doesn't list when-not scenarios, but the usage context is unambiguous within the tool family.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description explicitly states that the tool is read-only and returns { commands, warnings? }, writes nothing, which is critical behavioral transparency given no annotations exist. It also discloses the non-wrapping behavior and character limits, including that long lines are warned but never blocked.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences, front-loaded with the core purpose, and packs in usage, behavioral warnings, and return format without redundancy. Every sentence earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description provides a complete picture for a relatively complex builder tool: purpose, output structure, key constraints, and read-only safety. The schema covers parameter details, and the description adds the operational context needed to use it correctly, especially the word-wrap limitation and the list_assets reference.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema descriptions already cover all 7 parameters, so the baseline is 3. The description adds meaningful context: lines should be kept under ~55 chars (~38 with a face), faceName should come from list_assets('faces'), and the background/position/speaker parameters map to the mentioned features, enhancing beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly identifies the tool as building a Show Text event-command sequence, with a specific construction detail (101 setup + 401 lines) and a stated downstream use (insertion via insert_event_commands). This distinguishes it from sibling build_* tools like build_show_choices or build_conditional_branch.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description states that the output is intended for insertion via insert_event_commands, and it provides context for when to use this tool (creating Show Text commands). It mentions supported features (face, background, position, speaker) and a critical constraint (MZ word-wrap), but does not explicitly contrast with alternative tools, so it falls short of full explicit guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden. It discloses that the tool validates existence of the common event, is read-only, returns `{ command }`, and writes nothing. This clearly conveys the safety profile and return behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two concise sentences with no filler. The first sentence states the primary purpose, the second clarifies behavior and integration, making it easy to parse.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple builder tool with two parameters and no output schema, the description covers purpose, usage, validation, side effects, and return format. There are no significant gaps that would leave an agent uncertain.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the baseline is 3. The description adds value by explaining that commonEventId must reference an existing event (validation) and that the result composes into a command array, which gives the parameter context beyond the schema's basic description.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description explicitly states the tool builds a 'Common Event' event command (code 117), specifies the target resource, and notes it is for insertion via insert_event_commands. This clearly distinguishes it from other build_* siblings by naming the specific command type and its composition context.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
It states the tool is used to generate a command for insertion into an event page, and that the return shape matches build_* tools for composing into thenBranch/commands arrays. While it does not explicitly name alternative tools or exclusions, the context is clear enough for an agent to know when to use it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description fully discloses behavior: it details the event page structure (action-button, priority-same, optional text, gives contents, flips self switch), the opened page behavior, and error handling (throws on invalid id, warns but never blocks on unknown characterName or no graphic). It even explains the RTP sprite direction defaults. This is exemplary transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is four sentences long, front-loaded with the core purpose, and every sentence provides substantive detail. It is dense but well-structured, covering purpose, mechanism, parameter semantics, and error behavior without redundancy or fluff.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with 15 parameters, no output schema, and no annotations, the description is remarkably complete. It explains the event structure, the payout kinds, the default directions, and the error behavior. It leaves little ambiguity about what the tool will do, making it adequate for an agent to invoke correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema already covers all 15 parameters with descriptions (100% coverage), so the baseline is 3. The description adds extra meaning beyond the schema by explaining the relationship between `kind` and `id`, the direction row defaults for `closedDirection`/`openedDirection` on the !Chest sheet, and the two-page idiom. This is a meaningful addition, so a 4 is warranted.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's function: 'Create a complete, placed treasure chest on a map in one call'. It identifies the specific resource (treasure chest), the action (create/place), and the key implementation detail (two-page self-switch idiom) that distinguishes it from generic event-creation tools like create_map_event or create_npc.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description signals when to use this tool by emphasizing the 'two-page self-switch idiom done correctly' and 'so the chest can never be looted twice', implying it should be used instead of manually constructing the event pages. It also gives context for the `kind` parameter. However, it does not explicitly name alternative tools or state when not to use this tool, so it falls short of a perfect score.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full transparency burden and excels: it discloses defaults (EXP curve, no traits/learnings), the allocation behavior, dryRun preview, and two serious behavioral pitfalls (missing Hit Rate trait causes misses; missing Add Skill Type trait hides skill commands). This goes well beyond basic expectations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is three sentences but every sentence earns its place: purpose/defaults, then two crucial warnings. It is front-loaded with the core action and free of fluff, making it appropriately sized for the tool's complexity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description covers purpose, defaults, side effects, and pitfalls, which is comprehensive for a create tool with no output schema. However, it only partially specifies the return value (says it returns the next unused id but doesn't clarify whether the full created class object is also returned), leaving a minor gap.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Although schema coverage is 100%, the description adds significant meaning: it explains the default EXP curve values, the default maxLevel of 99, and the specific trait codes required for combat readiness (code 22) and skill-type visibility (code 41). This goes beyond the schema descriptions and materially helps correct invocation.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's function: 'Create a new character class in data/Classes.json.' It uses a specific verb and resource, and the mention of allocating a new id distinguishes it from sibling tools like update_class or add_class_learning.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context on how to use the tool (only name required, defaults for omitted fields) and important caveats about traits for combat-readiness. However, it does not explicitly name alternative tools or state when not to use it, though the creation purpose is evident from the description and sibling names.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description fully carries the burden and excels. It discloses ID allocation ('Allocates and returns the next unused item id'), default behavior for omitted fields, and specific error conditions for effect references. This is valuable operational context beyond the schema.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is compact and front-loaded, with every sentence delivering useful information: purpose, default behavior, ID allocation, and error cases. No redundant phrasing.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the 17-parameter schema with full per-parameter descriptions and no output schema, the description covers what's missing: usage simplicity, return value, and failure modes. It is complete enough for an agent to correctly invoke the tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, giving the baseline of 3. The description adds meaningful guidance by advising that only `name` is worth passing and explaining that omission yields Regular Item, consumable, no effects. This clearly adds value beyond the schema's per-parameter descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's function: 'Create a new item in data/Items.json.' This is a specific verb+resource, and the file path adds precision. It naturally distinguishes itself from siblings like update_item or search_items.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear guidance: 'Only `name` is worth passing; omitted fields use the editor's new-item defaults.' This tells the agent which parameters are important and what to expect if omitted, though it doesn't explicitly contrast with update_item or mention when to use an alternative.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description fully carries the burden of disclosure. It details read-only behavior, return shape { command, warnings? }, validation against actual plugin annotations, warn-by-default policy (never blocks), and args normalization to string-valued shape. This is exceptionally transparent.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences, front-loading the core purpose in the first sentence and packing validation, normalization, return shape, and side-effect-free behavior into the second. Every sentence earns its place; there is zero waste.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with 5 parameters, nested objects, and no output schema, the description covers all critical aspects: what it builds, how it validates, warning behavior, return value, and that it writes nothing. This is complete for an agent to select and invoke it correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema already documents all 5 parameters with 100% coverage, so baseline is 3. The description adds meaning by explaining that args are normalized to the editor's string-valued shape and that validation may produce warnings for unknown or disabled plugins, which affects how parameters are interpreted.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it 'Build an RPG Maker MZ plugin command (event command code 357)' for insertion via add_event_command, providing a specific verb and resource. It distinguishes itself from siblings by focusing on creation/building, not listing or inserting, making its role unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context: the tool is used to build a plugin command for later insertion via add_event_command. It doesn't explicitly mention alternatives or when-not-to-use, but the sibling list and the phrase 'via add_event_command' imply the workflow clearly enough.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description fully carries the burden of behavioral disclosure and does so excellently. It discloses that the tool 'Throws if the destination map does not exist; warns if the destination tile is outside that map, if the characterName is unknown, or if the event can never fire'. It also explains the behavioral difference between idioms (priority same vs below, visible vs invisible), the effect of 'force' and 'dryRun', and default behaviors for direction and fade. This is rich, honest context.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is dense but well organized: it opens with the main purpose, then explains the two idioms in a structured way, and closes with behavioral caveats. Every sentence provides essential information, and the length is appropriate for the tool's complexity. No filler or redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the high complexity (14 parameters, no output schema, no annotations), the description is remarkably complete. It covers what the tool creates, how to choose the idiom, default behaviors, and failure/warning modes. It also explains the safety mechanisms (force, dryRun). This is sufficient for an agent to select and invoke the tool correctly without additional context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema already covers all 14 parameters (100% coverage), so the baseline is 3. The description adds meaningful semantics beyond the schema by explaining the practical consequences of 'idiom' choices, the meaning of 'direction' and 'fade', and the validation behavior associated with 'force'. It does not describe every parameter individually, but it significantly enriches the key behavioral ones, justifying a score above baseline.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's function: 'Create a complete, placed map-transfer event in one call'. It distinguishes itself from generic event creation tools by emphasizing the one-call placement and the two idioms, and it specifically covers the map-transfer domain. The verb 'create' and resource 'map-transfer event' are precise and differentiate this from siblings like create_map_event or build_transfer_player.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit guidance on when to use each idiom: 'action_button' for solid landmarks and 'player_touch' for interior exits and map-edge gaps. It also clarifies defaults and error/warning conditions, giving clear context. However, it does not name alternative tools or explicitly state when not to use this tool in favor of a sibling, so it falls short of full 'when/when-not/alternatives' coverage.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the burden and does well: it discloses the output format (2D array with row/column order), the default layer, and that it throws if the rectangle is out of bounds. It could add more about error behavior or performance limits, but the essential behaviors are covered.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is three sentences, each earning its place: purpose/alternative, return format, and constraints/defaults. It is front-loaded and wastes no words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
There is no output schema, so the description correctly explains the return structure. It covers the main edge cases (bounds, layer default) and provides enough context to invoke the tool correctly. Given moderate complexity, the description is complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does 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 the layer default, referencing set_map_tile for layer meanings, and highlighting the boundary constraint, which supplements the schema's parameter descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool reads raw tile ids in a rectangular window of one map layer, and explicitly differentiates it from get_map as a token-cheap alternative. The verb 'read' and resource specification make the purpose unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5Does the description explain when to use this tool, when not to, or what alternatives exist?
It explicitly names get_map as the alternative and specifies when to use this tool ('inspecting part of a painted map'). It also gives a key usage constraint (must lie within bounds) and refers to set_map_tile for layer meanings, providing clear context for selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full responsibility and succeeds. It discloses read-only nature, the output-limit behavior for omitted sheet, autotile returning base tile id only, the 'transparent' flag meaning and practical implications, and the trust metadata (source, confidence, manual). It even explains coverage omissions. This is exemplary behavioral disclosure.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is long but every sentence carries substantive information. It is structured logically: purpose, data fields, autotile behavior, coverage, sheet parameter usage, and transparent flag. The bolding of the critical sheet guidance improves scannability. No filler or redundancy observed.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
No output schema exists and annotations are absent, so the description must self-document the return behavior. It does so thoroughly: return fields (source, confidence, manual, transparent), edge cases (autotile, uncovered sheets), output-limit behavior, and practical usage (feed to paint command). The description is fully sufficient for an agent to invoke correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% and both parameter descriptions are already detailed. The description adds meaningful context beyond the schema by explaining the rationale for the output limit ('to stay within the tool-output limit') and clarifying the per-sheet index content ('name + entry count'). It also reinforces the sheet role/filename usage. This raises it above the baseline 3.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
Purpose is explicit and specific: 'Get the semantic tile catalog for a tileset', clearly identifying the action (get), resource (tile catalog), and scope (per tileset). It distinguishes itself from sibling tools like describe_tile or find_tile by focusing on the catalog-level structure and semantic labels, including source, confidence, and transparency metadata.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
Usage guidance is strong: the description explicitly instructs 'Called WITHOUT `sheet` it returns only a per-sheet index... Pass `sheet` (filename 'World_A2' or slot role 'A2') to list one sheet's actual tile entries.' It also notes coverage ('Covers the default Overworld tileset... still-uncovered sheets are omitted'). However, it does not explicitly name alternative tools or say when NOT to use this tool, so only a minor gap remains.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It discloses read-only behavior, data source (js/plugins/*.js annotations + built-in allowlist), and the limitation that unlisted commands aren't validated—all adding context beyond tool name.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
Four short sentences, front-loaded with the action and purpose. Includes only essential information—usage, alternative, and caveat—without waste.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple tool with one optional param and no output schema, the description is complete: it states purpose, source, read-only nature, output shape, and a key limitation. No critical gaps for agent invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% for the single optional parameter pluginName (restrict to one plugin filename without .js). The description echoes 'Pass pluginName to narrow to one plugin' but adds little over the schema, meeting the baseline for full schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool lists plugin commands that create_plugin_command can validate, with a specific output structure (plugin filename → command key → args). It distinguishes itself from siblings by referencing create_plugin_command and scan_plugins.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly says 'Use scan_plugins for the richer per-project view' and notes that an unlisted plugin command can still be built but won't be validated, providing clear when-to-use and when-not-to-use guidance. Also instructs how to narrow with pluginName.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description fully discloses behavior: it is read-only, does not write IDs, allocates strictly above all declared/referenced IDs, and explains the default gap behavior (holes are often ID claims not yet written). This goes well beyond a simple operation summary.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is front-loaded with the core action and includes useful context. However, the playtest anecdote is vivid but non-essential, making it slightly longer than necessary. Still, every part contributes to understanding the tool's purpose and trade-offs.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description covers purpose, safety, guardrails, and edge cases well, and the schema fills in parameter details. The main gap is the lack of an explicit return-value description (e.g., does it return a single ID or an array?), and no output schema exists to compensate. Overall, it's nearly complete for selection and invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so parameters are already documented. The description adds valuable semantics beyond the schema: the collision rationale, the meaning of 'unallocated', and why reuseGaps defaults off (holes may be claimed in notes). This extra context enriches parameter understanding without being strictly necessary.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's action: 'Reserve the next unallocated switch / variable / common-event ID(s)'. It specifies the relevant namespaces and differentiates from siblings by emphasizing reservation/allocation rather than creation or listing. It also distinguishes from database-row ID assignment by pointing to create_*/batch_create.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides explicit context for when to use the tool: 'instead of picking one by hand' and to avoid silent collisions across editing sessions. It also gives exclusions/alternatives: database rows are 'not here' and are handled by create_*/batch_create, and names should be claimed via set_switch_name / set_variable_name.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description fully discloses mutation behavior: non-destructive merge, autotile-kind application, commit choke point with dry-run/diff, and the return shape. This goes well beyond minimal transparency for a write tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is information-dense but every sentence earns its place: purpose, merge behavior, key parameter semantics, autotile special case, write path, and return shape. It is front-loaded and efficiently structured.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (11 parameters, nested passage object, autotile behavior, and no output schema), the description covers all essential aspects: what the tool does, how it behaves, special autotile handling, and the exact return payload. It is a complete picture for an agent to invoke it correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 73%, so the description adds value by explaining passage directions, star/damage semantics, terrainTag range, and the applyToAutotileKind behavior. This compensates for undocumented parameters like bush/ladder/counter, though those remain self-explanatory booleans.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool edits tile passability/terrain/behaviour flags in a tileset's flags[] array, which is a specific verb+resource. It also distinguishes itself as the 'write side of get_tile_flags', differentiating it from the read tool and sibling editing tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context by positioning this as the write counterpart to get_tile_flags, implying when to use it. However, it does not explicitly name alternative tools or state when not to use it, such as set_map_tile for broader tile edits.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description fully carries the transparency burden. It discloses the default values (100 HP, one Attack action, no drops), id allocation, return shape '{ enemy, warnings? }', warn-by-default for battlerName, throw conditions for invalid references, and the critical Hit Rate trait pitfall—far exceeding typical transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise at five sentences and front-loaded with the core action and file target. Every sentence adds necessary information—defaults, id allocation, return shape, validation, and a critical combat pitfall—with no redundant filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite having no output schema or annotations, the description covers the tool's purpose, defaults, id assignment, return value, warning behavior, validation errors, and a common usage mistake. For a mutation tool with 11 parameters and reference-checking complexity, this is highly complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, but the description adds significant value beyond schema descriptions: it clarifies that omitted fields use editor defaults, explains validation failure for nested references, and flags the battlerName warning and Hit Rate trait issue. This supplements the schema's per-property descriptions with behavioral guidance.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The opening sentence 'Create a new enemy in data/Enemies.json' uses a specific verb and resource, clearly stating the tool's purpose. It also distinguishes itself from sibling tools like update_enemy and search_enemies by emphasizing creation and file location.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
It explicitly states that only 'name' is required and defines defaults for omitted fields, giving clear entry conditions. It does not explicitly name update_enemy as the alternative for modifying existing enemies, but the 'Create a new enemy' phrasing and id-allocation behavior make the intended use unambiguous.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden and does an excellent job. It discloses case-insensitivity, literal substring matching (with examples), the effect of searchDescriptions, coverage of Overworld vs custom sheets, and the 'read-only' nature. It even explains the meaning of the 'transparent' flag. All important behavioral traits are explicitly stated.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is long but every sentence adds unique value: purpose, matching semantics, workflow, searchDescriptions behavior, return fields, and coverage. It is front-loaded and well-paragraphed, though slightly dense. The length is justified by the tool's complexity and absence of an output schema.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given there is no output schema, the description impressively covers return fields (name, sheet, tile id, autotile kind, source, matchedIn, transparent, description/confidence/manual), the difference between built-in and custom catalog data, and the relationship to get_tile_catalog. No critical context is missing for a search tool of this complexity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the baseline is 3. The description adds value beyond the schema by explaining the query is a literal substring (not synonym), that searchDescriptions only widens over custom sheets, and by clarifying that tilesetId comes from Tilesets.json/the map. This goes beyond merely restating parameter names.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb and resource: 'Find tiles in a tileset by a case-insensitive SUBSTRING match on their catalog name.' It clearly distinguishes itself from sibling tools like get_tile_catalog (browsing) and describe_tile (describing a single tile) by emphasizing its role as a 'quick bridge from a name fragment to a paintable tile id.' The contrast with semantic search also clarifies its exact scope.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit when-to-use guidance and names an alternative: 'To browse the actual tile names first, use get_tile_catalog with a `sheet` filter, then search a fragment you see.' It also explains when searchDescriptions is useful (custom sheets vs built-in entries) and the limitation of literal substring matching. This gives an agent clear direction on selecting this tool over alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden. It discloses validation-before-write, refusal on structural problems, the force override, advisory warnings never blocking, and the exact return shape. It even explains the verbose flag and how to read the full result back, which goes well beyond basic mutation tool behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is information-dense but every sentence adds value: purpose, target requirements, validation behavior, force override, warnings, return shape, and verbose option. It is organized logically from action to outcome, with no filler or repetition.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema, the description fully explains the return value shape and how to verify a splice. It covers all key contexts: targets, position, validation, failure modes, override, advisory findings, and verbosity. The only minor omission (dryRun) is already covered in the parameter schema, and the description even points to get_map_event as a read-back path.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Although schema coverage is 100%, the description adds meaning by grouping parameters per target (mapId+eventId+pageIndex vs commonEventId vs troopId+pageIndex), explaining that commands should come from build_* builders, and clarifying position default and force/verbose effects. This significantly reduces guesswork about how parameters interrelate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with a specific action: "Insert a pre-built sequence of event commands ... into any of the three command lists an MZ project has". It distinguishes itself from the read-only build_* tools and clearly states its mutating nature. The target-specific breakdown (map_event, common_event, troop_page) removes ambiguity about scope.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
It explicitly positions this as the "mutating companion to the read-only builders" and tells users to pass commands from build_* tools. It also clarifies target-specific required IDs. However, it does not explicitly mention the alternative add_event_command for single-command insertion or state when not to use this tool, only implying it through "sequence of event commands".
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description fully discloses behavior: it parses specific files, reports enabled state, notes that disabled plugin commands never run, and flags a limitation about MZ's lack of required-argument annotations. It also declares itself read-only, which is critical safety information.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is longer than one sentence but every clause earns its place, covering purpose, output, usage, and a limitation. It front-loads the main action and remains well structured, though a slightly tighter wording could improve conciseness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Considering there is no output schema, the description fully specifies what will be reported (command key, label, description, args with name/type/default, enabled status). It also provides essential context about the relationship with create_plugin_command and a key limitation, making the tool's behavior clear and complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does 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 the practical effect of each parameter ('narrow to one plugin', 'skip plugins that are installed but switched off') and ties them to the tool's purpose, going slightly beyond the schema descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with a specific verb ('Discover') and resource ('the plugin commands this project actually has'), and details exactly what it parses and reports. It clearly distinguishes itself from create_plugin_command by framing as a discovery tool, and the mention of enabled/disabled state adds unique scope.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly says when to use it ('Use it to find out what create_plugin_command can call') and when not needed ('create_plugin_command validates against this scan automatically, so you don't need to call this first'). It also explains the optional filters (pluginName, enabledOnly), making usage context clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the burden of behavioral disclosure. It clearly states that the list is replaced wholesale, that every troopId is validated against Troops.json, and that a non-existent troop throws. It also explains the 'hides the on-disk shape' aspect. However, it does not mention the return value (e.g., success indicator) or the effect of dryRun, though the schema covers dryRun separately.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is three sentences: first the main action, then the encounter object format, then validation and tool preference. Every sentence adds essential information without redundancy. It is front-loaded with the primary purpose and avoids tangents.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's moderate complexity (encounter list with nested objects) and lack of output schema, the description fully prepares the agent to invoke it correctly: it covers the operation, parameter semantics, validation, defaults, and the recommended alternative. All necessary context for selection and use is present.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema provides baseline descriptions for all parameters, but the description adds significant meaning beyond schema: weight's default value (5), regionSet's empty/omitted interpretation ('anywhere'), validation behavior for troopId, and the meaning of encounterStep ('average steps between encounters'). This enriches the schema's parameter definitions with practical semantics.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's function: 'Set a map's random-encounter list (replaces it wholesale) and optionally its encounterStep.' It uses a specific verb ('Set') and resource ('map's random-encounter list'), and explicitly differentiates from the sibling tool update_map by recommending this for encounters, preventing confusion.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit usage guidance: 'Prefer this over update_map for encounters (it validates and hides the on-disk shape).' This tells the agent exactly when to use this tool versus an alternative, and implies it is the appropriate choice for encounter list changes.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden, and it excels. It discloses atomic failure ('Throws — writing nothing at all'), sequential id allocation ('Ids are allocated sequentially from the current max'), the return shape (`{ type, count, created, warnings? }`), and warning behavior ('enemy battlerName misses are warnings, never blocked'). These are critical behavioral nuances beyond simple schema info.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
Four dense sentences, each earning its place. The first sentence states purpose, the second explains record semantics and id behavior, the third gives usage guidance, and the fourth covers return/error behavior. No filler or repetition.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
This is a complex batch write tool with no output schema. The description covers return format, error conditions, atomicity, id allocation, and warning semantics. It also references sibling tools for record shape clarification. This is fully complete for an agent to select and invoke correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Input schema already covers 100% of parameters with descriptions, providing a strong baseline. The description adds meaningful semantics: each entry in `records` follows the matching create_* tool's field shape, only `name` is required for most, and omitted fields use defaults. It also explains how the `type` parameter relates to record shape. This goes beyond schema, though the schema already does much of the work.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with a specific verb and resource: 'Create many database records of one type in a single call and a single file write.' It explicitly identifies itself as the batch sibling of the single-record create_* tools, distinguishing it from those alternatives and clearly conveying its purpose.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit when-to-use guidance: 'Use this instead of N sequential create_* calls when authoring a cast, a loot table, or a skill list.' This also indicates the alternative approach (sequential calls) and the scenarios where batching is preferable.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description fully carries the transparency burden. It discloses the raw 1-indexed array return format, the null slot at index 0, single-record behavior with id, null for missing records, and explicitly states 'Read-only.' This goes beyond the schema to explain observable behavior comprehensively.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is compact and front-loaded: it leads with the primary action, then return format, then usage guidance and exclusions. Every sentence earns its place, and it avoids repeating schema details verbatim beyond the necessary context.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
There is no output schema, so the description must explain return values itself; it does so thoroughly (array, indexing, null behavior, field granularity). It also covers scope exclusions and safety (read-only), making it complete for a tool of this complexity. No meaningful gaps remain.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with the type enum and id description already present, giving a baseline of 3. The description adds semantic clarity by explaining the behavior of omitting vs. providing id—returning the whole table versus a single record or null—and emphasizing that these are full records, which enriches the parameter meaning.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with a clear verb and resource: 'Read a database table in full' and enumerates the exact tables it covers. It also explicitly distinguishes itself from related sibling tools by naming alternatives like list_names and search_actors, making its purpose unmistakable.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit when-to-use versus when-not-to-use guidance: it recommends list_names for id→name lookups, search_actors/search_items/search_skills for name-based searches, and get_map_infos/get_map for maps/tilesets. This directly addresses alternatives and exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden and succeeds. It explicitly says 'Read-only,' discloses output formatting details like 'empty slots omitted,' and describes the mode encoding (0 world / 1 area). It even notes which image sheet labels are used, giving a clear picture of the tool's behavior and output shape.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is three tightly written sentences. The first defines the action and output, the second gives usage context, and the third offers a cheaper alternative and the read-only note. Every sentence earns its place with no redundancy, and the most critical information is front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given zero parameters, no annotations, and no output schema, the description is remarkably complete. It covers what the tool returns, how the data is structured, when to use it, what other tools depend on it, an alternative approach, and its safe, read-only nature. This fully equips an agent to select and invoke the tool correctly without needing further clarification.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, so the baseline is 4. The description adds semantic value by explaining the meaning of the mode field (0 world / 1 area) and the sheet labels, which helps the agent interpret results. While no input parameters need explanation, the contextual output details enrich understanding beyond the empty schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description starts with 'List every tileset in the project' — a specific verb and resource — and enumerates the exact fields returned (id, name, mode, image sheets). It also distinguishes itself from sibling tool list_names by noting the alternative for a plain id→name list.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5Does the description explain when to use this tool, when not to, or what alternatives exist?
It explicitly states when to use the tool: 'Use this to discover valid tilesetId values' and lists dependent tools. It also provides an alternative: 'For a plain id→name list, list_names(type:"tilesets") is even cheaper.' This gives clear contextual guidance on choosing between similar operations.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full responsibility. It discloses the read-only nature, data source (project JSON vs. hand-maintained list), the precise allocation definition (declared or referenced anywhere), and the return shape ({ count, highest, gaps, declaredCapacity, allocated[], coverage }). This is exemplary transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is appropriately sized and front-loaded with the core purpose. Every sentence contributes: the data-source caveat, allocation definition, usage guidance, and alternative tool reference. No filler or redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite the absence of an output schema, the description specifies the return structure and gives enough behavioral detail to understand the tool's full functionality. It covers what the tool counts, how it behaves, when to use it, and what it returns, making it self-sufficient.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema already covers both parameters fully, so baseline is 3. The description adds valuable context by explaining that 'id' answers 'where is switch 23 actually used?' and clarifying the scope of 'type' via the namespace list, elevating it slightly above pure schema reliance.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Show') and clearly identifies the resource: allocated IDs across switch, variable, and common_event namespaces. It explicitly contrasts with sibling tools like next_free_id and list_names, making the tool's niche unmistakable.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5Does the description explain when to use this tool, when not to, or what alternatives exist?
It provides direct guidance: 'Use this before reusing an id' and explains when to pass the id parameter for targeted lookup. It names the alternative tool (next_free_id) for claiming a fresh id, offering clear when-to-use vs. when-not-to-use direction.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden. It discloses that tiles are not repainted, dimensions cannot be changed due to data desync, and the response omits tile data/events while reporting counts. Explains the verbose alternative for full record.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
Three sentences, each carrying unique information: scope, constraints, and response behavior. No redundancy, well front-loaded with the primary purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with no output schema, it explains return summarization, omitted fields, and how to get the full record. It also handles edge cases like dimension changes with explicit redirection to resize_map.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema covers all parameters, giving a baseline of 3. The description adds practical examples of allowed update properties and clarifies the response trade-off of verbose, providing meaningful value beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
Clearly states it updates a map's top-level properties with specific examples (name, display name, bgm, encounters). It distinguishes from siblings by explicitly excluding tile repainting, width/height changes, and event edits, pointing to resize_map for dimensions.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5Does the description explain when to use this tool, when not to, or what alternatives exist?
Gives explicit when-not-to-use guidance: not for tiles, not for width/height (use resize_map), and not for events. Also mentions verbose: true or get_map for full record, indicating when deeper inspection is needed.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden and excels. It exposes default page values, deep-merge behavior, empty-list handling, validation refusals, and the facing-trigger pitfall, all of which are critical behavioral specifics beyond the schema.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
Every sentence contributes unique operational detail; the text is front-loaded with purpose, uses an inline example, and ends with a structured field list. For a tool with 8 parameters and complex merge semantics, the length is justified and there is no waste.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the absence of annotations and output schema, this description supplies complete context. It covers defaults, enums, merge rules, validation behavior, page attributes, and sibling-tool alignment, enabling an agent to invoke the tool correctly without external documentation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema only gives generic descriptions like 'Event pages', but the description adds concrete field formats including image parameters, trigger/priorityType/moveType enums, conditions, and list termination. This goes far beyond the schema and is essential for correct invocation.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
Description opens with 'Create a new event on a map' and immediately defines the tool's scope via the merge model. It also distinguishes from the sibling create_npc by explicitly recommending that tool for talking NPCs, so the agent can tell them apart.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides direct when-to-use guidance: 'For the common "talking NPC" case prefer create_npc' and explains when priorityType:1 is required for action-button pages. It also covers validation refusal and the force override, so the agent knows the failure modes and how to handle them.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
GitHub Badge
Glama performs regular codebase and documentation scans to:
- Confirm that the MCP server is working as expected.
- Confirm that there are no obvious security issues.
- Evaluate tool definition quality.
Our badge communicates server capabilities, safety, and installation instructions.
Card Badge
Copy to your README.md:
Score Badge
Copy to your README.md:
Latest Blog Posts
- Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)By Om-Shree-0709 on .mcpAgent IdentityOAuth 2.1
- Your AI Chatbot Just Exposed Your CEO's Salary to an InternBy Om-Shree-0709 on .Agent IdentityMCP SecurityOAuth Delegation
- Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)By Om-Shree-0709 on .Agentic AiPrompt InjectionWebAssembly
MCP directory API
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/Redseb/rpgmaker-mz-mcp'
If you have feedback or need assistance with the MCP directory API, please join our Discord server