Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations, the description carries the full burden. It discloses key behaviors: indent must increase by 1 inside branch blocks, the trailing code-0 terminator is preserved automatically, and choice branches must stay in sync. These are non-obvious behavioral details that help the agent avoid errors. It doesn't mention error handling or reversibility, but the provided details are substantial.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is dense but every sentence adds value: the main action, the alternative for Show Text, a practical code reference, and two critical structural rules. It's a single paragraph without fluff, though the code list is long. The most important information is front-loaded.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the complexity of the tool (nested command object, many code types), the description provides a comprehensive reference for common codes and structural rules. It does not explain return values or error handling, but the absence of an output schema suggests simple success/failure responses. The 'position' parameter is covered in the schema. Overall, it's sufficient for a well-informed agent.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is only 20%, so the description compensates by explaining the `code` parameter in detail with a list of common XP codes and their specific parameter structures (e.g., 102=Show Choices, 123=Control Self Switch). It also explains `indent` semantics. The other parameters (mapId, eventId, pageIndex) are self-evident from the tool name, and `position` is described in the schema.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description opens with a clear verb and resource: 'Add a single command to an event page'. It immediately differentiates itself from the sibling tool add_show_text by stating 'for Show Text prefer add_show_text', showing the agent exactly which tool to use for that specific case.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

Provides explicit guidance to prefer add_show_text for Show Text commands, and offers a detailed list of common XP codes with their meanings and structural requirements (e.g., indent, branch blocks, terminator). While it doesn't explicitly mention when not to use this tool for other event operations, the purpose and code list make the context clear.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations, the description carries the load and reveals the important automatic splitting of long text into multiple boxes and the code structure handling, which is useful context. It lacks return/error behavior, but covers the key mutation aspects.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is concise, two sentences, and front-loads the primary purpose while packing essential technical behavior without fluff.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a specialized command adder, the description covers the main behavior and usage, including line breaks and automatic splitting, but does not mention return values or error handling, leaving minor gaps.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is only 40% with text and position described. The tool description adds meaningful detail about text (using \n for line breaks, 4 lines per box) but does not clarify mapId, eventId, or pageIndex, though those are fairly self-explanatory by name.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states 'Add a Show Text message to an event page' with a specific verb and resource, and distinguishes itself from generic siblings like add_event_command by focusing on Show Text and its XP 101/401 structure.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

It implies it is the appropriate tool for adding Show Text messages, and explains the automatic handling of 101/401 codes and line break syntax, but does not explicitly contrast with 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.

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 reveals key behaviors: computes edge variants from 8-neighbour connectivity, auto-sanitizes shapes to be 4-connected with no diagonal pinches or 1-cell holes, and recomputes the border ring of existing same-autotile cells. It also directs to render_map for preview. This is substantial transparency, though it does not mention error handling or side effects on overlapping layers.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is compact and front-loaded: it opens with the core action, then lists the four shape modes with guidance, and closes with sanitization and preview notes. Every sentence adds value; there is no filler. The structure uses clear formatting with code-styled parameter names, making it scannable.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the tool's complexity (four mutually exclusive shape modes, edge handling) and lack of output schema, the description covers essential operating context: shape use cases, sanitization behavior, border ring recomputation, and preview. It lacks mention of what happens if no shape or multiple shapes are supplied, and does not describe the return value. These are minor gaps for a paint operation, so a 4 is appropriate.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is high (88%), with each shape parameter having a descriptive schema. The description adds value by explaining the relationship between shape modes and use cases, noting that slot 0..6 indexes into tileset autotile_names, and clarifying width recommendation. It does not duplicate schema details but reinforces and extends them.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool's action: 'Paint an autotile... and compute the correct edge variant per cell from 8-neighbour connectivity.' It distinguishes itself from sibling tools by emphasizing autotile-specific edge computation and seamless coastlines/paths/cliffs. The purpose is specific and the resource (autotile slot) is clearly identified.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description provides explicit guidance on when to use each shape mode: 'USE for ponds/lakes/forest patches' for blob, 'only for rectangular floors' for region, and the recommendation 'width >=2' for paths. It clarifies the tool is for autotile-safe painting, implicitly distinguishing it from general tile fill tools. It does not explicitly name alternatives or exclusions, but the shape usage guidance is strong.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations are present, but the description explicitly states 'No writes', making the read-only nature clear. It also discloses that it analyzes filename patterns and content edge-periodicity, and returns a classification with tier/op/category/flags. This provides substantial behavioral insight beyond what 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.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is moderately long but every sentence adds useful information—detection logic, edge-case detection, outputs, and side-effect guarantee. It front-loads the main action, though it could be condensed.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

With no output schema, the description partially compensates by listing returned fields (tier, op, category, flags). It doesn't enumerate possible tier/category values, but for a classification tool with a single input, this is reasonable completeness.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema covers 100% of the single parameter with a clear description of filePath. The tool description doesn't add much parameter-specific detail beyond what the schema already states; it repeats the PNG context. Baseline 3 is appropriate.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool inspects a PNG before import and determines if it is a native RMXP asset, going beyond canvas dimensions. It specifies detection methods (filename fingerprinting, edge-periodicity) and distinguishes itself from generic validators by targeting RMXP-specific tile-size issues.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

Explicitly says 'before import', which is the appropriate usage context. It also explains the value (detecting 1.5x/2x size mismatches). However, it doesn't explicitly contrast with sibling validate_assets or state when not to use it, leaving some ambiguity.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations, the description must carry the behavioral burden. It discloses a key behavior (defaults to linear stat growth unless a parameters Table is provided), which adds context. However, it introduces an undeclared 'parameters Table' not present in the schema, and lacks details on side effects or permissions.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

A single concise sentence, front-loaded with the action verb, and no unnecessary words. It efficiently communicates the core purpose.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Despite the complexity of a 15-parameter creation tool, the description is sparse. It explains a default behavior but omits return values, prerequisites, or clarification of the 'parameters Table' reference. The schema partially compensates, but the description lacks sufficient context for reliable invocation.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 53%, so the description should compensate for the undocumented parameters. It only vaguely references 'parameters Table' and 'defaults', adding little semantic value to the 15 parameters. The provided parameter descriptions in the schema do most of the work.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the action ('Create a new actor') and resource, distinguishing it from sibling tools like update_actor or search_actors. It also adds specific default behavior (RMXP defaults, linear stat growth curves), providing a clear scope.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

Usage is implied by the verb 'Create' but there is no explicit guidance on when to use this tool versus alternatives, such as update_actor for modifications or get_actors for retrieval. No exclusions or conditions are mentioned.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations are provided, so the description must disclose behavior itself. It reveals that the armor is appended to a file and that defaults match the RMXP editor, giving useful side-effect and defaulting context. However, it omits return values, error handling, and whether creation is idempotent.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is three short clauses, front-loaded with the core purpose, with no redundant content. Every sentence adds value: creation, file append, kind mapping, and default behavior.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Despite a complex 15-parameter tool with no output schema and no annotations, the description stays minimal. It does not explain return values, valid ranges, or field meanings beyond kind, so it is not complete enough for confident invocation in edge cases.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The schema has only 13% description coverage, and the description only explains the 'kind' parameter and the overall default/override strategy. The many numeric parameters (pdef, mdef, eva, plus modifiers) are left undefined, so the description does not compensate for the schema's sparse coverage.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description uses a specific verb ('Create') and resource ('armor'), and adds the side effect 'appended to Armors.rxdata', which clearly distinguishes it from sibling creation tools like create_weapon and read tools like get_armors.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description clearly identifies when to use this tool (to create a new armor) and offers no misleading alternatives. It lacks explicit exclusions or comparisons to alternatives, but the context is unambiguous given the tool name and sibling set.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations, the description carries the behavioral burden. It discloses the exact damage formula, the meaning of the physical flag, and a reference example (Fire). It does not cover error conditions or side effects, but provides substantial insight into the tool's core mechanics 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.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is three sentences, front-loaded with purpose, then formula, then reference. No wasted words; each sentence adds essential information. It is appropriately concise for the complexity it conveys.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a creation tool with 7 parameters, no output schema, and no annotations, the description explains the most complex behavior (damage formula) and provides a reference example. It does not state return values or persistence behavior, but these are likely standard for creation tools and not critical given the detailed formula coverage.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100%, so baseline is 3. The description adds meaning by explaining the damage formula, which contextualizes power, physical, and the stat multipliers. The reference values (power 140, sp 75) give concrete expectations for these parameters, exceeding simple schema descriptions.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description opens with 'Create a damage-dealing skill (simplified),' which clearly identifies the action and resource. It distinguishes itself from sibling tools like create_healing_skill and create_state_skill by explicitly focusing on damage-dealing. The physical/magic clarification further refines the purpose.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description implies when to use this tool (for damage skills) by its name and opening line, and explains how to choose physical vs magic via the physical parameter. However, it does not explicitly mention alternatives or state when not to use it, relying on sibling tool names to guide distinction.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations, the description carries the behavioral burden. It discloses the non-obvious healing formula and INT scaling, which is critical for correct parameter usage. However, it does not explain what 'simplified' means or address persistence/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.

Is the description appropriately sized, front-loaded, and free of redundancy?

Three sentences, each earning its place: purpose, formula, and reference. The language is efficient and front-loaded, with no wasted words or redundant information.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

The tool has moderate complexity with 5 parameters and no output schema. The description covers the main non-obvious mechanic (healing formula), and the schema handles parameter definitions. The vague 'simplified' and lack of post-create behavior notes are minor gaps.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100%, so the baseline is 3. The description adds precise formula details and the default int_f=50 convention, going beyond the schema's generic 'scales with INT' note. Other parameters are adequately documented in the schema.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states 'Create a healing skill' with a specific verb and resource, distinguishing it from sibling tools like create_damage_skill and create_state_skill. The 'simplified' qualifier adds slight ambiguity but does not 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.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description does not explicitly state when to use this tool versus alternatives, though the name and content imply healing skills. The formula and reference provide useful context for parameter selection, but there are no explicit exclusions or alternative recommendations.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Without annotations, the description carries the burden of disclosing side effects. It explicitly states it 'Writes the next-free MapXXX.rxdata (blank Table[w,h,3]) + MapInfos entry', which is a concrete behavioral disclosure, and describes the return value (id plus size_advisory and design guide). It does not mention permissions or error conditions, but for a creation tool, the side-effect and return information is strong.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is three sentences long and front-loads the core action. The all-caps opening phrase is attention-grabbing but earns its place by highlighting the key decision. It packs in side effects, return values, and related tools without waste, though it is slightly dense. Overall, every sentence contributes useful information.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a tool with 6 parameters and no output schema, the description covers return values (id, size_advisory, design guide), side effects (writes file + MapInfos), and the size decision process. It also provides guidance for follow-up tools, making it contextually rich. It does not mention parentId/tilesetId, but the schema covers those defaults, so the description is adequately complete.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100%, so the baseline is 3. The description goes beyond by explaining the decision logic: 'SIZE IS THE FIRST DESIGN DECISION' and connecting purpose to default sizes (e.g., interior=20x15, town~40x35). It also clarifies that width/height can be set explicitly as an alternative to purpose, which adds semantic value not fully captured by the schema's individual parameter descriptions.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description opens with a specific verb+resource ('Create a new map') and immediately clarifies what this entails: writing a MapXXX.rxdata file and MapInfos entry. It distinguishes itself from sibling tools by explicitly directing subsequent painting/preview actions to apply_autotile, scatter_tiles, set_map_tiles, and render_map, making clear this is for creation, not editing or rendering.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description provides clear usage context: pass a purpose for a sensible default size, or set width/height explicitly. It also names alternative tools for follow-up operations ('Paint with apply_autotile / scatter_tiles / set_map_tiles, preview with render_map'), which helps the agent decide when to use this tool versus others. No explicit 'when not to use' is given, but the alternatives cover the main cases.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations are present, so the description carries the full burden. It discloses the default empty page behavior, but omits side effects, permissions, overwrite semantics, or what happens if the map or coordinates are invalid. This is minimal transparency for a mutation tool.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

Two short sentences, front-loaded with the primary purpose. The conditional default-page note is concise and earns its place.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

No output schema, no annotations, and only 20% schema coverage. The description omits return value, coordinate/x-y semantics, uniqueness constraints, and required prerequisites. It is under-specified for reliable use.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is only 20% (only 'pages' has a description). The description adds context for pages by explaining the default behavior, but leaves mapId, name, x, and y unexplained beyond their property names. With low schema coverage, the description should compensate more.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description states a specific action and resource: 'Create a new event on a map.' This clearly differentiates it from siblings like update_map_event, get_map_event, and other create_* tools.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The core usage is implied ('Create a new event on a map'), and the note about omitted pages adds a conditional use case. However, it does not explicitly compare against related tools like add_event_command or create_transfer_event, missing an opportunity to clarify when this tool is preferred.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

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 does disclose one behavioral trait: the default insertion position 'just above Main'. However, it does not mention potential side effects, whether the operation is reversible, what happens if a script with the same name exists, or what the return value is. This is a moderate level of transparency, earning a 3.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is two sentences long, front-loaded with the primary action, and includes only essential information. Every sentence serves a purpose: the first states the function, the second clarifies an important default behavior. This is an example of conciseness without under-specification.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the tool's low complexity (3 parameters, no output schema, no annotations), the description provides enough context for an agent to understand the core function and the key default behavior. The schema fully covers parameter semantics. However, it lacks any information about prerequisites, return values, or potential edge cases, which prevents a perfect score. For a simple create operation, this is still fairly complete.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100%, so the schema already provides descriptions for all three parameters. The description adds minimal value by echoing the default position behavior for the 'position' parameter, but it does not explain the 'code' or 'name' parameters beyond what the schema states. Baseline 3 is appropriate because the schema does the heavy lifting.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool's function with a specific verb and resource: 'Create a new RGSS script.' It also adds a meaningful detail about the default insertion position, which distinguishes it from siblings like update_script and search_scripts. The word 'new' explicitly differentiates it from update_script.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description implies the tool is for creating scripts, as opposed to updating or searching them. While no explicit alternatives or exclusions are named, the context is clear enough that an agent would know to use this when adding a new script rather than modifying an existing one. A score of 4 is appropriate because it provides clear context without explicitly listing alternatives.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

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 reveals a key non-obvious behavior: damage is not formula-based but scaled by stat influence rates, and negative power causes healing. This is valuable context. However, it does not disclose other important side effects such as whether the skill is persisted, what happens on duplicate names, or if there are any validation constraints 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.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is exactly two sentences. The first states the tool's purpose and scope, the second explains the critical damage formula. There is no fluff, repetition, or irrelevant detail; every word contributes useful information.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the high complexity (23 parameters) and absence of an output schema or annotations, the description covers the essential purpose and a key behavior, but leaves gaps. It does not mention the return value, persistence effects, or how this tool relates to the specialized skill creation siblings. The schema explains each parameter well, but the description itself could provide more contextual guidance for such a complex tool.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100%, so the baseline is 3. The description adds meaning beyond the schema by explaining the damage model: 'damage = power scaled by stat influence rates (atk_f/str_f for physical, int_f for magical)' and 'Negative power heals.' This clarifies how the influence rates and power parameters interact, which is not fully explicit in the individual parameter descriptions.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool's function: 'Create a new skill with full control over RPG::Skill fields.' It identifies the resource (skills) and the verb (create), and 'full control' hints at being the general-purpose creator, but it does not explicitly distinguish itself from the specialized create_damage_skill, create_healing_skill, or create_state_skill siblings.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The phrase 'full control' implies this is the low-level tool to use when you need complete customization, versus the more specialized sibling tools. However, there is no explicit guidance on when to prefer this over create_damage_skill, create_healing_skill, or create_state_skill, nor any exclusions or alternative recommendations.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations are provided, so the description carries the burden. It discloses a key behavioral aspect: state IDs come from States.rxdata, with XP defaults enumerated. However, it does not mention side effects, permissions, or return behavior. This adds value beyond the schema but lacks comprehensive disclosure for a mutating operation.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is two sentences, front-loaded with the core purpose and followed by a practical reference. No words are wasted, and the format is scannable. It earns its place with the state ID defaults, making it both concise and dense with useful info.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

The tool has 6 parameters and no output schema, yet the description focuses primarily on stateId semantics. It leaves gaps around return values, error handling, and when to use this vs. sibling tools. While the schema covers parameters, the description doesn't fully round out the operational context for an agent to invoke this safely and correctly.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100%, giving a baseline of 3. The description enriches parameter understanding, particularly for stateId, by explaining where it comes from and providing concrete default mappings (3=poison, 8=sleep, etc.). This goes beyond the schema's brief 'State ID to inflict', adding actionable context.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states a specific verb and resource: 'Create a state-inflicting skill'. It distinguishes itself from siblings like create_skill, create_damage_skill, and create_healing_skill by focusing on state effects (poison, sleep, etc.). The resource and action are unambiguous.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description implies use for state-inflicting skills but never explicitly contrasts it with alternatives like create_skill or create_damage_skill. It doesn't say when to prefer this tool over a generic skill creation tool, leaving the agent to infer from the name and examples. This is implied usage, not explicit guidance.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations, the description carries the transparency burden. It details the artifacts produced (source sheet, tile images, manifest.json contents, index.html), giving insight into behavior. However, it does not disclose potential side effects like overwriting existing files in outDir, required permissions, or whether the tool is safe to re-run. It provides meaningful context but not full 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.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is two sentences: the first states the core purpose and the second enumerates the specific outputs. It is front-loaded with the action and resource, follows a logical structure, and contains no fluff or redundancy. It is information-dense but still readable.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

The tool has moderate complexity with no output schema and no annotations. The description explains the complete artifact set, the input requirement (one tileset), and the recommended usage timing. While it does not mention return values or side effects, the provided context gives an agent enough to decide when to use and what to expect from the tool.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100%, so the schema fully documents the three parameters. The description adds overall purpose but does not elaborate on the meaning or usage of 'scale' or 'outDir' beyond the schema defaults. It mentions manifest.json contents, which indirectly relates to tileset processing details, but not to the parameters themselves. Baseline 3 is appropriate.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description uses a specific verb phrase 'Create a review bundle' and identifies the exact resource ('one tileset'), distinguishing it from sibling tools like render_tileset_atlas or verify_tileset by focusing on the identification harness purpose. It clearly states the output types and the goal of separating engine facts from semantic claims.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

Provides explicit usage guidance: 'Use this before assigning map-design roles to an uncataloged tileset.' This clarifies when to invoke the tool, though it does not enumerate specific when-not-to-use conditions or alternate tools. The context is unambiguous enough for an agent to decide appropriately.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations, the description carries the full burden. It discloses key behaviors: validates both endpoints exist and are in-bounds before writing, and explains trigger behavior. However, it does not mention return value or error messaging, which are important for a tool with no 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.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is three sentences, front-loaded with the core purpose, then providing trigger guidance, then validation and next-step advice. Every sentence contributes operational value without redundancy.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

While the description covers purpose, validation, and parameter nuances, it omits return value details for a tool with no output schema. An agent would benefit from knowing what the tool returns (e.g., created event ID) to chain operations. This is a clear gap in an otherwise rich description.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100%, providing baseline 3, but the description adds practical meaning beyond the schema: it explains trigger 0/1 semantics in terms of door vs. edge teleport, and advises on graphic usage. This elevates parameter understanding beyond the raw schema.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description opens with a specific action: 'Wire two maps together: create a Transfer Player (command 201) event at (x,y) on a map that warps the player to (targetX,targetY) on targetMapId.' This clearly identifies the tool as creating a transfer event with precise command and destination semantics, distinguishing it from generic map-event tools like create_map_event.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description provides concrete usage context: trigger 0 for a door (with graphic) and trigger 1 for an edge teleport (invisible), plus a follow-up recommendation to use validate_connectivity. It lacks explicit mention of alternatives or when not to use this tool, but the scenario is clear.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations provided, the description carries the burden of disclosing side effects. It explicitly states that the weapon is 'appended to Weapons.rxdata', indicating a non-destructive write operation. It also discloses behavior for unspecified fields via the defaults statement. It does not cover return values or validation rules, but the key behavioral traits are addressed.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is three focused sentences, each adding unique value: purpose and storage, default behavior, and equipment slot. No redundant or filler content. It is front-loaded with the primary action and reads efficiently.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

While the description covers the core action and defaults, it leaves out crucial operational details: no return value is mentioned, and there is no output schema. It also does not specify whether names must be unique or what happens if the name already exists. Given the tool has 16 parameters and no annotations, the description is adequate but not fully complete for an agent to predict the tool's behavior in all cases.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is only 19%, so the description must compensate. It does so by stating that all fields beyond the required name can be omitted and will receive RMXP editor defaults ('Defaults match the RMXP editor; override any field'). This gives a global understanding of parameter optionality and behavior, which is more valuable than individual descriptions for a well-known domain.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool's action ('Create a new weapon') and resource ('Weapons.rxdata'), and distinguishes it from siblings like create_armor by specifying the 'weapon slot'. It goes beyond a simple verb+object by noting file append behavior and default alignment with the RMXP editor.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description implies when to use the tool: when a new weapon is needed. It provides guidance on how to use it ('Defaults match the RMXP editor; override any field'), making it clear that only the name is required and other fields have sensible defaults. However, it does not explicitly contrast with alternatives like create_armor or mention 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.

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 that tile ID 0 clears, and more importantly, explains that autotiles are placed as base variant (P1) only, requiring apply_autotile for smart edges. This is non-obvious and valuable. It does not mention side effects like overwriting, but for a fill operation the behavior is clear.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is three concise sentences, each adding distinct information: the core operation, the clear behavior, and the autotile caveat. It is front-loaded with the verb and resource, with no wasted words.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the tool's simplicity and the existing schema, the description combined with the schema covers the functionality well: target map, layer, rectangle, tile ID, and special cases (clear, autotile). It also connects to apply_autotile for a complete workflow. Minor gaps remain around error conditions or coordinate formats, but these are not critical for a fill tool.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 75%, with descriptions for rect, layer, and tileId, but mapId is undocumented. The description adds the autotile behavior note and restates clear behavior, but does not explain mapId or coordinate details. It adds marginal value over the schema without fully compensating for the missing parameter description.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool fills a rectangle of a layer with a single tile ID, and optionally the whole layer if rect is omitted. This distinguishes it from siblings like set_map_tiles (sets individual tiles) and scatter_tiles (random placement), and the mention of whole-layer fill adds useful scope.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description provides clear context for when to use this tool (rectangular fill, whole-layer fill) and directly references the apply_autotile tool for achieving smart edges with autotiles, which is a relevant alternative/next step. It does not explicitly list exclusions for other tile-placement tools, but the guidance is sufficient.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations provided, the description carries the burden of disclosure. It reveals that the result includes a 6x100 parameters table, which is useful. However, it does not disclose potential error behavior (e.g., unknown ID), return format details beyond the table, or any side effects (though 'get' implies read-only). This is a moderate level of transparency.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is a single sentence with no redundant words. It is front-loaded with the main action and resource, then details the included data. It earns its place without waste.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a simple getter with one well-documented parameter and no output schema, this description is fairly complete. It states what is returned (the actor and its parameters table), which is the key context. However, it lacks explicit guidance on error handling or differentiation from sibling tools, so it is not fully comprehensive.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The input schema already fully documents the only parameter, actorId, as 'The ID of the actor to retrieve'. The description adds no additional semantic information beyond what the schema provides, so the baseline score of 3 applies.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the action (get), the resource (specific actor), and the scope (by ID). It also distinguishes itself from siblings like get_actors (plural) and search_actors by specifying retrieval of a single actor by its unique ID.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

Usage is implied rather than explicit: you need an actor ID to fetch a specific actor. The description does not contrast with alternatives like get_actors or search_actors, nor does it state when not to use this tool. This is acceptable but not fully guiding.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations are present, so the description must carry the transparency burden. It only hints that parameter tables are omitted, but doesn't state output format, read-only nature, or any side effects. This is a minimal disclosure for a read operation.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is a single, concise sentence, but the parenthetical 'parameter tables omitted' is ambiguous and may confuse readers. It is still appropriately sized, though the note could be clearer.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a simple zero-parameter getter, the description is minimally sufficient but omits the return format and fails to explain the ambiguous 'parameter tables omitted' note. It doesn't fully clarify what the agent can expect from the response, especially given the many sibling tools.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

With zero parameters and 100% schema coverage (vacuous), the description has no parameter details to add. The baseline of 4 applies, and the description doesn't detract from it.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description states 'Get all actors from the RPG Maker XP project' with a specific verb and resource, clearly distinguishing it from 'get_actor' (single actor) and 'search_actors' (search). Though the parenthetical 'parameter tables omitted' is cryptic, the core purpose is unambiguous.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description provides no guidance on when to use this tool versus alternatives like search_actors or get_actor. There are no exclusion criteria or context hints, leaving the agent to infer usage from the name alone.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

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 communicates that the tool returns the complete, unfiltered set of armors, implying a read-only operation. However, it omits any details about return format, pagination, or potential errors, so behavioral transparency is limited.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is a single, concise sentence that gets straight to the point. It doesn't waste words and is appropriately sized for such a simple tool.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

The tool is extremely simple with no parameters and no output schema. The description states it fetches all armors, but doesn't elaborate on the response structure or any limitations. For a basic list getter, this is adequate but leaves room for improvement, so a 3 is fitting.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The tool has zero parameters, so there are no parameters to document. The schema's 100% coverage is trivially satisfied, and the description doesn't need to explain any inputs; baseline of 4 is appropriate.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description 'Get all armors from the project' clearly identifies the tool as a read operation to fetch every armor entity. It uses a specific verb and resource, distinguishing it from other get_* tools by resource type, though it does not explicitly contrast with search_items or get_items.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description provides no guidance on when to use this tool versus alternatives like get_items or search_items. It doesn't mention any filtering or prerequisites, leaving the agent without decision criteria.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations provided, the description must carry the full burden of behavioral disclosure. It notes that output is summarized for tables/command lists, which is useful, but it does not explicitly state whether the operation is read-only or describe the return format or edge cases. The verb 'list' implies a read operation, but more explicit confirmation would strengthen transparency.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

Two sentences that front-load the action and immediately give the relevant kinds and an important usage note. No filler or repetition.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a simple listing tool with one parameter and no output schema, the description covers the primary purpose, kinds, and summarization behavior. However, it lacks guidance on how this tool relates to the dedicated getter tools and what the returned entries contain, which would make it more complete.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The schema provides an enum for the single 'kind' parameter, and the description repeats the enum values in prose, giving context for parameter selection. However, it does not define each kind's semantics or how the output varies by kind, so the description adds limited value over the schema.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool's function: 'List all entries of a database file.' It enumerates valid kinds and distinguishes itself from get_database_entry, which provides full data. This provides a specific verb+resource and differentiates from a sibling tool.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

It advises that 'Tables and command lists are summarized; use get_database_entry for full data,' which is an explicit alternative for a different use case. However, it does not mention dedicated getters like get_items, get_actors, etc., which might be more appropriate for specific categories, leaving some ambiguity.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations are provided, so the description carries the burden. It discloses that the tool returns nested structures like tables and event commands, which is useful. However, it doesn't mention read-only behavior, error conditions, or whether the ID must be valid, but the description does add value.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

Single sentence, technically accurate, includes concrete examples of content returned. Efficient, though the parenthetical list is somewhat long.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

With no annotations, no output schema, and high complexity (many entry types with nested data), the description gives a good overview but lacks details on return format, error behavior, and edge cases. Adequate for a simple retrieval but not fully complete.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 0%, meaning the description must compensate. It mentions 'by ID' and implies the kind is the entry type, but doesn't explain the enum values or the meaning of id beyond 'ID'. However, the description does indicate the tool is for a specific database entry, adding some context over the raw schema.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool retrieves a full database entry by ID, with specific details about what is included (tables and event command lists). It distinguishes itself from get_database which likely lists entries, but it doesn't explicitly contrast with sibling get_actor, get_skill, etc.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

No explicit instruction on when to use this vs. the more specific get_actor/get_skill or search functions. The description implies it's for full entry retrieval, but doesn't state alternatives or exclusions.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations, the description carries the transparency burden. It discloses the data source (Game.ini) but does not mention return format, potential errors, or other behavioral traits. For a simple read tool, this is acceptable but minimal.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is a single, focused sentence that communicates the essential purpose and source without wasted words. It earns its place completely.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a zero-parameter, no-output-schema getter, the description is complete. It tells the agent exactly what the tool retrieves and from where, which is sufficient for invocation. The simplicity of the tool means no further context is necessary.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The tool has zero parameters, so the baseline is 4. The description need not elaborate on parameter meanings, and the schema already fully covers this (coverage 100%). No additional parameter semantics are needed.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description uses a specific verb ('Get') and clearly identifies the resource ('game title') with a source ('from Game.ini'). It is distinct from sibling tools like update_game_title, which suggests a read vs. write pairing.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

Usage is implied by the getter nature and the sibling update_game_title, but the description does not explicitly state when to use this tool versus alternatives or any exclusions. It is adequate but relies on inference.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations are provided, so the description carries the full burden of behavioral disclosure. It only says 'Get all items from the project' which essentially restates the tool name. It does not disclose return format, potential size, pagination, or any permission requirements, leaving the agent with minimal behavioral insight.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is a single, short, front-loaded sentence: 'Get all items from the project'. It is appropriately sized for a zero-parameter tool with no wasted words, making it easy to parse quickly.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For such a simple tool, the description is functional but minimal. Without an output schema, it does not clarify what 'items' includes (e.g., whether it includes weapons/armor) or what the return structure looks like. Given the many sibling tools, a brief clarification of scope would improve completeness.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The tool has zero parameters and the input schema is empty (coverage 100%). With no parameters, the description does not need to elaborate, and the baseline of 4 applies. Nothing additional is required.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description uses a specific verb ('Get'), resource ('all items'), and scope ('the project'), which clearly states what the tool does. However, it does not explicitly differentiate from sibling tools like get_weapons or get_armors, which may overlap with 'items' depending on the game data model.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

There is no guidance on when to use this tool versus alternatives. The sibling search_items exists, but the description does not mention when a full 'get all' is appropriate versus a filtered search, nor does it note 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.

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 a key behavioral trait: tile data is summarized by default and only fully included when includeTiles is true. However, it does not describe return format, error handling, or confirm whether the returned map data includes other components like events or properties, leaving some uncertainty.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is two sentences, front-loaded with the main purpose, and contains no redundant information. It efficiently conveys the core function and the key behavioral note about tile summarization.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

The tool has no output schema, so the description should ideally explain what 'map data' includes. It mentions tiles and the ID but does not clarify whether events, properties, or other map components are part of the return. Given the sibling tools, this is a reasonable but incomplete summary for an agent.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The schema already provides 100% coverage for both parameters. The description adds value by explaining the default tile summarization behavior, which is not fully clear from the schema's 'Include the full tile data Table (large!)' alone. This clarifies the effect of setting includeTiles to true.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool's function: 'Get map data by ID' and references the file path Data/MapXXX.rxdata. It also indicates that tile data is summarized unless includeTiles is true, which helps distinguish it from tile-specific tools like get_map_tiles. However, it does not explicitly differentiate it from siblings like get_map_events or 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.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description implies usage when you need map data by ID, but it does not state when to use this tool over alternatives. The note about tile summarization provides parameter-level guidance (when to set includeTiles), but there is no explicit exclusion or comparison with sibling tools such as get_map_tiles or get_map_events.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations, the description carries the full burden. It clearly states the tool is a retrieval ('Return the guide') and specifies what the guide covers. While it doesn't explicitly say it's read-only or describe the return format, the nature of returning a document is clear enough. A score of 4 reflects adequate transparency without explicit side-effect disclosure.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is a single sentence that packs in the tool's purpose, the specific file name, and a list of key contents. It is front-loaded ('Return the level/map design guide') and every clause earns its place. No wasted words.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

The tool is simple: no parameters, no output schema, and the description fully enumerates the guide's contents. Given its simplicity, there is nothing missing. The description completely contextualizes when and why to use it.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The tool has zero parameters, so the baseline is 4. The description adds context about the returned content, which is more than necessary. The schema has no properties, so there is no gap to compensate for.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool returns a specific resource (MAP-DESIGN.md) and enumerates its contents: layer roles, tile priority, passability, multi-tile-object rule, composition principles, and authoring workflow. This distinguishes it from sibling tools like get_map or get_map_tiles which operate on actual map data.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

Explicitly instructs to 'Load this before authoring or editing maps', providing a clear when-to-use directive. There are no alternative tools for retrieving the design guide, so no exclusions are needed. This is direct, practical usage guidance.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

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 implies a read operation ('get') but does not state what happens if the event is not found, the return format, or whether any side effects occur. This is minimal disclosure.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is a single concise sentence with no fluff, but it is under-specified. While brevity can be good, here it omits necessary context, making it arguably incomplete rather than efficiently concise.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

The tool is simple, but the description lacks important context such as the return value, relationship to sibling tools, and any behavioral caveats. Without an output schema or annotations, the description is too sparse to fully support correct invocation.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The schema has two numeric parameters (mapId, eventId) with no descriptions, and the context signals indicate 0% schema description coverage. The description does not explain the meaning or relationship of these parameters beyond what their names already suggest, failing to compensate for the lack of schema hints.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description uses a specific verb ('get') and resource ('specific event from a map'), clearly indicating the tool's function. It does not explicitly distinguish from the sibling tool get_map_events, which likely lists events, so it lacks clear sibling differentiation.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

There is no guidance on when to use this tool versus alternatives such as get_map_events, update_map_event, or create_map_event. The description does not mention any prerequisites or contexts where this tool would be preferred.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

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 states only the core action and does not disclose return format, ordering, inclusion criteria, or potential errors. This is insufficient for a read operation where the agent might need to know what 'all events' entails.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is a single focused sentence with no redundant words. It is front-loaded with the action and resource, making it highly efficient.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a simple one-parameter tool, the description is minimally adequate, but it lacks details about the return type or behavior (e.g., whether it returns an array, whether hidden events are included). No output schema exists, so the description should explicitly mention the shape of the result. Sibling tools provide some context, but the description itself is incomplete.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The schema has zero description coverage for mapId, and the description only implies that mapId identifies the specific map. It does not explain what the numeric ID represents or how it relates to other map tools, but it does clarify the parameter's role in the operation, which is more than the schema provides.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states a specific verb ('Get') and resource ('all events') with a clear scope ('from a specific map'). This distinguishes it from siblings like get_map_event (singular) and search_map_events (search-based retrieval).

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description implies the primary use case (retrieve all events for a given map) but does not explicitly mention alternatives or exclusions. Sibling names provide context, but the description itself does not state when to use this tool versus get_map_event or search_map_events.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations are provided, so the description carries the full burden of behavioral disclosure. It only states 'Get information,' which implies a read operation, but it does not explicitly confirm read-only behavior, describe the return format, or mention any potential side effects or limitations. This is minimal for a tool with no annotation support.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is a single concise sentence that front-loads the verb and resource, with no unnecessary words. It efficiently conveys the scope and fields included.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a simple tool with no parameters and no output schema, the description adequately identifies the return fields (names, parent, order) and the scope (all maps). While it doesn't describe the return format or error handling, the simplicity of the operation makes this acceptable, though additional details about read-only behavior would improve completeness.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The tool has zero parameters, so the input schema already fully captures the interface. Since there are no parameters to explain, the description does not need to add semantics, and the baseline score of 4 applies.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description uses the specific verb 'Get' with resource 'all maps' and explicitly lists the fields (names, parent, order). This clearly distinguishes it from sibling tools like get_map, which targets a single map.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The phrase 'all maps' provides clear context that this tool is for listing all maps, as opposed to get_map for a single map. However, it does not explicitly mention alternatives or provide exclusion criteria, so it stops short of full guidance.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations, the description carries the burden. It discloses that this is an advisory (read-only) tool and enumerates the return content, but it does not explicitly state side effects, failure conditions, or data format, leaving moderate gaps.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

Three sentences, front-loaded with the tool's output contents followed by usage guidance. No filler, each sentence earns its place.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

No output schema, so the description lists all key return items (screens, counts, density, budget, warnings) and explains the optional purpose parameter. The tool is simple enough that this is sufficient, though exact units or response shape are not specified.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

MapId is only implied as 'an EXISTING map' and lacks explicit meaning, while purpose is explained in both schema and description ('check the size against its sweet spot'). With schema coverage at 50%, the description adds some context but does not fully compensate for the undocumented mapId.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly identifies the tool as providing design/size advisory for existing maps, listing concrete outputs (screens, counts, density, budget, warnings). It distinguishes itself from sibling map tools by emphasizing 'EXISTING map' and 'editing a map' context, though it uses a noun phrase rather than a strong verb.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

Explicitly states 'Use this first when editing a map' and explains the optional purpose parameter is for checking size against its sweet spot. It gives a clear usage context but does not mention when to avoid this tool or name alternative tools, so slightly below a perfect score.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

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 return format (2D grid with rows top-to-bottom), layer behavior, and tile ID semantics, as well as a payload-related caveat. It doesn't address permission needs or invalid mapId behavior, but for a read operation this is strong coverage.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

Four sentences, each adding distinct information: purpose, layer behavior, tile ID ranges, and usage tip. No redundancy, front-loaded with the primary action.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a tool with no output schema and moderate complexity, the description adequately covers output structure, layer selection, tile meanings, and crop capability. It provides sufficient context for an agent to understand and invoke the tool correctly.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 67% and already describes layer and region. The description adds value by explaining the layer output behavior ('Returns one layer if layer is given, else all three') and the rationale for region cropping ('avoid large payloads'). It also clarifies tile ID ranges, which indirectly helps interpret layer/body data. mapId is self-explanatory.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description opens with an explicit action and target: 'Read a map's tile ids as a 2D grid'. This clearly distinguishes it from sibling write tools like set_map_tiles and metadata tools like get_map or 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.

Does the description explain when to use this tool, when not to, or what alternatives exist?

There is no explicit guidance on when to use this tool vs alternatives. The note 'Use region to crop and avoid large payloads' is parameter usage advice, not tool selection guidance. Context implies it is for reading tile data, but no exclusions or alternatives are mentioned.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations, the description carries the burden. The verb 'Get' implies a read-only operation, but the description does not disclose error behavior, return format, or any side effects. It adds minimal context beyond the basic action.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is a single sentence that is concise, front-loaded with the action and resource, and contains no unnecessary words.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a simple getter with one fully described parameter, the description provides the essential purpose. However, without annotations or an output schema, it omits details about return type and error handling, making it minimally viable but not comprehensive.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The schema covers 100% of the parameter description, so the baseline is 3. The description merely repeats 'by index' and adds no semantic value beyond the schema.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the action 'Get' and specifies the exact resource 'RGSS script's Ruby source code' with the indexing method. This distinguishes it from get_scripts, which presumably lists scripts, and other script-related tools.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description implies usage when you have an index from get_scripts, but it does not explicitly state when to use this tool versus alternatives like get_scripts or search_scripts. The dependency is only hinted at in the parameter schema.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations are provided, so the description fully carries the burden of behavioral disclosure. It reveals that the tool reads Scripts.rxdata and returns metadata (index, name, source length) rather than source content, which is valuable context. It does not explicitly state it is non-destructive, but 'List' implies a read-only operation, and no side effects are suggested.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is a single sentence that is front-loaded with the action ('List all') and resource, followed by the output fields. Every word earns its place; there is no fluff or redundancy.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a list-all tool with no parameters and no output schema, the description is nearly complete. It specifies the exact file (Scripts.rxdata) and the fields returned (index, name, source length). It could optionally mention ordering or filtering behavior, but this is not critical for a simple list operation.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The tool has zero parameters and the schema coverage is 100% (vacuously). With no parameters to describe, the baseline score of 4 applies; the description adds no parameter-specific information because none are needed.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool lists all RGSS scripts from Scripts.rxdata and specifies the returned fields (index, name, source length). It uses the specific verb 'List' and identifies the resource and scope, distinguishing it from siblings like get_script (single script) and search_scripts (filtered search).

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description implies use when one needs a complete inventory of scripts, but it does not explicitly state when to use this tool versus alternatives like get_script or search_scripts. No exclusions or recommended alternatives are mentioned, leaving usage context somewhat implicit.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

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 states the core operation but does not mention response format, error behavior (e.g., 404 if not found), or whether the returned object includes full details. For a simple getter this is acceptable, but additional context would improve transparency.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is a single, front-loaded sentence with no filler. Every word contributes to meaning, making it appropriately concise for a simple getter.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the low complexity (one parameter, no output schema), the description is largely complete. It could benefit from a note about the return value or a pointer to sibling tools, but for a basic get-by-ID operation, it provides sufficient context.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The schema has one parameter (skillId) with a description, giving 100% schema coverage. Per guidelines, this sets a baseline of 3. The description adds no extra parameter semantics, so the score remains at baseline.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description 'Get a specific skill by ID' uses a specific verb ('Get'), resource ('skill'), and scope ('by ID'), clearly distinguishing it from sibling tools like get_skills (which likely lists all skills) and search_skills. It is direct and unambiguous.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description implies the use case: when you have a skill ID and need that specific skill. However, it does not explicitly mention alternatives (e.g., use get_skills to list all skills or search_skills for filtering), so guidance on when to use it versus siblings is only implied, not stated.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

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. 'Get' implies a read-only operation, and 'all skills' conveys the scope. However, it does not mention return format, potential performance implications, or whether it modifies anything, though the simplicity of the tool makes this acceptable.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is a single, front-loaded sentence with zero wasted words. It efficiently communicates the tool's purpose without redundancy.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a zero-parameter, no-output-schema tool, the description is fully complete. It provides all necessary information for an agent to select and invoke the tool correctly, with no ambiguity about what it does.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The tool has no parameters, so the baseline is 4. The description clarifies that it retrieves all skills, which adds meaning beyond the empty schema by specifying the scope of the result.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description 'Get all skills from the project' uses a specific verb ('Get') and clearly identifies the resource ('all skills') and scope ('from the project'). This distinguishes it from sibling tools like get_skill (singular) and search_skills (filtered search).

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description provides no guidance on when to use this tool versus alternatives such as search_skills or get_skill. It simply states what it does without specifying exclusions or use cases, leaving the agent to infer usage.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations are provided, so the description carries the transparency burden. It discloses the return contents (all switch names) and the index-to-ID mapping, but doesn't explicitly state read-only behavior or return format. The verb 'get' implies safety, but the description alone is somewhat minimal.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is a single sentence that is direct and free of redundant wording. It front-loads the action and resource, and includes only the essential clarifying detail about indexing.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a simple zero-parameter getter, the description adequately covers the core behavior: it returns all switch names with the mapping from index to switch ID. It doesn't specify the return container (e.g., object vs array), but the phrasing implies a mapping, which is sufficient for the tool's simplicity.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

There are zero parameters, so the description has no parameter details to add. According to the rubric, 0 params yields a baseline of 4. The description correctly omits parameter info.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the action ('Get') and resource ('all game switch names'). The parenthetical 'index = switch ID' adds crucial semantic detail that distinguishes this from similar list tools like get_variables.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The usage is implied: to retrieve all switch names, use this tool. There is no explicit mention of alternatives or when not to use, but the sibling set_switch_name implies this is for reading names. However, no exclusions or alternative guidance is provided.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations are absent, so the description carries the burden. It clearly identifies the data source (System.rxdata) and enumerates the data categories that will be returned, which partially discloses behavior. However, it doesn't mention whether this is a read-only operation, whether it validates the file, or what happens if the file is missing. Since the name 'get_system' strongly implies a read operation and the description includes a file reference, the risk of misuse is low, but richer behavioral detail would be expected.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is a single sentence that front-loads the purpose ('Get system data') and then lists the key contents in parentheses. Every element adds value, and the parenthetical list is efficiently organized. No redundant or filler words are present.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a zero-parameter tool with no output schema, the description is quite complete: it names the resource and enumerates the major data categories. A minor gap is the lack of format or volume of the returned data, but given the tool's simplicity and the clear sibling context, this is acceptable. It doesn't need to explain return values since no output schema exists, but it would be slightly more complete with a note that the response is the full System data structure.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The tool has zero parameters, and the schema confirms this with an empty properties object. The description adds meaning by specifying what data is returned (party, elements, switches, variables, etc.), which is the relevant semantic content. Since there are no parameters to document, a baseline 4 is appropriate, and the description adequately compensates by explaining the tool's scope.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description uses a specific verb ('Get') and resource ('System data'), then elaborates with the exact file and the data categories it contains (party, elements, switches, variables, etc.). This clearly distinguishes it from sibling tools that target maps, items, actors, skills, or scripts.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description implies usage as the go-to tool for retrieving high-level system configuration, but it doesn't explicitly state when to prefer it over alternatives. However, given that it is the only system-level read tool among siblings and its name/description are unambiguous, the appropriate context is implied. No explicit 'when not to use' is provided.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations, the description carries the full burden. The verb 'Read' explicitly indicates a non-destructive operation, and the description discloses a meaningful behavioral trait: absence from the catalog signifies unreviewed content, not an error. This adds valuable context beyond a simple getter description.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

Two sentences with no filler. The first sentence states the core function, the second adds essential semantic context about absence. Every word earns its place.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a single-parameter read tool with no output schema, the description covers the return contents (catalog, manifest, validation summary) and the interpretation of missing entries. It doesn't describe error responses or output structure, but that's beyond what's expected given no output schema.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100% with tilesetId already described in the schema. The description adds no parameter-specific details, but the schema provides the type and name, 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.

Does the description clearly state what the tool does and how it differs from similar tools?

The description opens with 'Read the structured semantic catalog' – a specific verb+resource that clearly identifies the tool's function. It distinguishes itself from sibling write/validation tools like save_tileset_catalog and validate_tileset_catalog by focusing on retrieval of the catalog plus derived artifacts.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The 'Absence from the catalog means unreviewed, not safe to infer' sentence provides a clear exclusion criterion for interpreting results. This implies the tool is for reading existing reviewed catalogs, but it doesn't explicitly name alternative tools like verify_tileset or save_tileset_catalog.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations, the description carries the transparency burden. It discloses the index-to-ID mapping and that it returns all names, but does not specify the return format, potential empty results, or ordering.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is a single, front-loaded sentence with no filler. It is appropriately sized for a simple list operation.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a zero-parameter, read-only list operation, the description provides the essential semantic mapping (index = variable ID) in one sentence. It could specify the exact return structure, but given the simplicity, it is nearly complete.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The tool has zero parameters, and the schema is empty. The baseline for zero-param tools is 4; the description does not need to add parameter details.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description uses the specific verb 'Get' with the resource 'all game variable names' and clarifies that the index corresponds to the variable ID. This clearly distinguishes it from sibling tools like get_switches and set_variable_name.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

No explicit when-to-use or alternative guidance is given. The agent must infer from the name and description that this is for retrieving variable names, but it does not contrast with set_variable_name or get_switches.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations are provided, so the description carries the full burden of behavioral disclosure. It only repeats the tool's name (implying a read operation) without revealing return format, pagination, authorization requirements, or whether the result includes all fields of each weapon. This is minimal context for a getter tool.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is a single, direct sentence with no wasted words. It is appropriately sized for the tool's simplicity, matching the conciseness standard set by high-quality examples like get_calls.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the tool's simplicity (no parameters, no output schema, no annotations), the description is minimally viable but leaves gaps. It does not state the return format or whether it returns full weapon objects or just summaries, relying on the agent to infer context from sibling tools.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The tool has zero parameters, so schema coverage is trivially 100%. The description does not need to explain parameter meanings because there are none, and the baseline for zero-parameter tools is 4. No additional parametrization context is required.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description states 'Get all weapons from the project' with a specific verb and clear resource scope, making the primary action evident. However, it does not differentiate from sibling tools like get_items or get_armors, which could cause ambiguity if those tools return overlapping data.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description provides no guidance on when to use this tool versus alternatives such as search_items or get_items. There is no mention of preferred scenarios, exclusions, or prerequisites, so the agent has no basis for deciding between this and similar retrieval tools.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Without annotations, the description carries the full burden and meets it well: it discloses the sizing formula (384 + height/4), the asset guard rules, and the force override. It does not detail potential side effects like overwriting an existing entry, but this is a minor gap.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is three sentences, front-loaded with the primary purpose, followed by guard behavior and its role. No redundant language; every clause adds value.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a 4-parameter tool with no annotations or output schema, the description covers purpose, guards, sizing, and force override, enabling correct selection and invocation. It omits return value and whether an existing entry is overwritten, but the provided context is largely sufficient.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The schema provides 100% coverage of parameter descriptions, so the baseline is 3. The description adds extra meaning for graphicName by specifying the 256px width and 32px content constraints, and for force by explaining the guard override. This elevates it above baseline.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the action: creating a Tilesets.rxdata entry for an existing graphic, with specific sizing behavior. It distinguishes from sibling tools by mentioning the guard mechanism and its role as the database gate for mis-classified art.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

It gives clear context for when to use: when a graphic already exists in Graphics/Tilesets and needs a database entry. It also explains when to use force:true (to override the guard), but does not explicitly contrast with alternatives like classify_asset or verify_tileset.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations provided, the description fully discloses behavior: it composites all 3 tile layers, lacks priority/overhead draw-order, fog/panorama/weather, autotile animation, and event sprites. It also details asset resolution (project Graphics/ then RTP) and default output location, which is excellent transparency.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is concise and well-structured: purpose, use case, limitations, asset resolution, and output path are each covered in a single sentence with no waste. The key verb 'Render' leads the first sentence, making it easy to scan.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the tool's complexity and the rich schema covering all 8 parameters, the description provides all necessary behavioral context: output format (PNG), return value (file path), limitations, and file system behavior. No output schema is needed because the return is a simple path.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100%, and the schema descriptions already explain each parameter well. The tool description adds no extra semantic meaning beyond the schema, so the baseline 3 is appropriate.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description states a specific verb-resource pair: 'Render a map's tile layers to a flat top-down PNG preview... and return the file path.' It clearly distinguishes this tool from map-editing siblings like set_map_tiles or fill_region by emphasizing it produces a viewable preview outside the editor.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

It explicitly says 'Use this to SEE a map you built/edited and self-check it,' providing clear context for when to use the tool. It does not name alternative tools, but the context is sufficient to avoid confusion with map data retrieval or tile editing tools.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

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 states the tool generates a PNG with a scaled grid, labels, passability indicators, and autotile slots, and notes its limitation ('not semantic proof'). It does not mention file overwriting or side effects, but the behavior is otherwise well described for a render operation.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is two sentences long, with the main action and details front-loaded in the first sentence and usage guidance in the second. Every clause earns its place, and there is no redundancy or filler.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a simple rendering tool with three well-documented parameters and no output schema, the description is sufficiently complete. It explains what the output looks like and when to use it, while also guiding toward a sibling tool for a different use case. Minor gaps (like error handling) are not critical for this tool type.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The schema covers all three parameters with descriptions, so coverage is 100%. The tool description adds context about the atlas content (e.g., scaling with grid, tile ids) but does not provide additional parameter-specific meaning beyond what the schema already offers. Baseline 3 is appropriate.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool's function with a specific verb ('Render') and resource ('tileset') and details the output format ('a labeled atlas ... to a PNG'). It distinguishes itself from siblings by describing the atlas contents (grid, tile ids, passability, autotile slots) and positioning it as a 'quick numeric reference'.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description provides explicit usage context: it is a 'quick numeric reference, not semantic proof' and directly points to an alternative tool, create_tileset_identification_harness, for map-design role assignments. This gives clear when-to-use and when-not-to-use guidance.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

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 reveals a key constraint: 'Generated engine facts cannot be overwritten by catalog claims', which informs the agent about immutability. It also implies validation occurs before saving, though it does not detail error handling or 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.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is two sentences, front-loaded with the purpose, then input modes and a constraint. 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.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the tool has 6 parameters and no output schema, the description covers the essential usage, input modes, and an important constraint. It does not mention return values or error handling, but for a save operation this is not a critical omission. The description is sufficient 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.

Does 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 the two input modes: incremental arrays (entries, objects, autotiles) versus the complete catalog JSON, which helps the agent understand how to populate the parameters. It does not rehash schema descriptions but complements them.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description states 'Validate and save reviewed semantic findings for a tileset' with a specific verb and resource, clearly distinguishing it from sibling tools like get_tileset_catalog and validate_tileset_catalog. It is not a tautology and immediately conveys the core function.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description explains it accepts 'incremental tile/object/autotile arrays or the complete catalog JSON exported by the review page', indicating this is the save step after a review. It does not explicitly name alternatives or when-not-to-use, but the context is clear enough.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations, the description carries the transparency burden. It discloses key behaviors: 'skipping occupied cells', 'deterministic given seed', optional 'focal point with falloff for a density gradient', and non-overwriting implied by skipping. It doesn't mention side effects like whether it clears existing tiles or error handling, but the main behavioral traits are well covered.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is three sentences, each earning its place: first the core mechanism, second the optional focal point, third the use case and determinism. It is front-loaded and highly concise with no filler.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

The description provides enough context for a map-decoration tool: what it does, when to use it, key behavioral rules, and determinism. It doesn't describe the return value, but there is no output schema. It could mention alternatives like fill_region for uniform fills, but the given use-case guidance is sufficient.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 63%, and the description adds meaningful semantics beyond the schema: it explains density as 'fraction of cells', focal parameter's effect ('denser near a landmark'), and seed determinism. It also aligns 'skipping occupied cells' with avoidOccupied. This compensates for the missing descriptions of mapId and region.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states a specific verb ('Scatter') and resource ('clutter tile ids over a region'), with detailed scope including density and occupancy. However, it does not explicitly distinguish this tool from sibling tools like fill_region or set_map_tiles, so it misses the top score for sibling differentiation.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description gives a clear use case: 'Use for flowers/bushes/rocks/tall grass instead of hand-placing lone tiles — fixes sparse/corner-clustered decoration.' This provides when-to-use context and an informal alternative, but it lacks explicit when-not-to-use guidance or references to alternative tools.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations are provided, so the description carries the full burden of behavioral disclosure. It only states 'Search actors by name' and does not disclose return format, pagination, case sensitivity, or whether it returns a list or single match. This is a significant gap for a search tool without annotations.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is a single four-word sentence that is front-loaded, concise, and free of redundancy. It states exactly what the tool does without waste.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given no output schema, the description should explain what the tool returns, but it does not. It also lacks usage context and does not distinguish itself from similar sibling tools. The description is too minimal to be fully complete for an agent to invoke correctly without additional assumptions.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100%: the parameter searchTerm has a description 'The search term to find actors'. The tool description adds no additional meaning beyond repeating the schema, so the baseline of 3 applies. No format, matching behavior, or constraints are described.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description 'Search actors by name' uses a specific verb and resource, clearly indicating the tool's purpose. It implicitly distinguishes from siblings like search_items or search_skills by mentioning actors, but it does not explicitly differentiate from get_actors or search_actors alternatives, so it falls short of a 5.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description provides no guidance on when to use this tool versus alternatives. It does not mention that get_actors might be used for listing all actors, nor does it clarify whether search supports partial matching. There is no explicit usage context or exclusion criteria.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations provided, the description bears the full burden of behavioral disclosure. It only states the search scope and criteria, but does not mention read-only behavior, return format, pagination, or match semantics (e.g., partial vs. exact). This is a minimal disclosure 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.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is a single concise sentence, front-loaded with the action and resource. It contains no filler and fully uses its words effectively.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a simple search tool with one parameter and no output schema, the description is adequate but incomplete. It does not explain what the tool returns (e.g., list of objects, IDs) or any constraints like result limits. Sibling tools like get_items suggest alternative retrieval methods, but no guidance is offered.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The schema has 0% description coverage, so the description must compensate. It does convey that the searchTerm is used to match against name or description, which adds meaning beyond the bare schema. However, it does not specify match type, case sensitivity, or how multiple fields are combined.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool's function: searching items, weapons, and armors by name or description. This is a specific verb-resource combination that distinguishes it from sibling tools like get_items or create_weapon, which have different purposes.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description implies when to use the tool (when searching items/weapons/armors by name/description) but does not explicitly contrast it with alternatives like get_items or get_weapons. No exclusions or when-not-to-use guidance is provided.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations, the description carries the full burden of disclosing behavioral traits. It only states the basic search function, omitting return format (e.g., an array of events), whether search is case-sensitive or partial-match, and any rate limits or side effects. This is insufficient for a tool with no 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.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is a single, concise sentence that immediately conveys the tool's function and scope. It contains no filler or redundant information, making it well-structured and front-loaded.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a simple two-parameter search tool with no output schema, the description covers the core action but lacks important contextual details such as the return value shape and any search behavior specifics. Given the absence of annotations and output schema, the description does not fully prepare 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.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The description implicitly maps 'on a map' to mapId and 'by name' to searchTerm, adding semantic meaning beyond the bare schema. However, it does not explicitly reference parameter names or provide additional details like match type or required format, so the compensation for low schema coverage is partial.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description 'Search events on a map by name' clearly identifies the action (search), the resource (events on a map), and the scope (by name). This distinguishes it from siblings like get_map_events (which likely lists all events) and search_items (which searches a different resource type).

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description provides no guidance on when to use this tool versus alternatives such as get_map_events or get_map_event. It does not mention exclusions, prerequisites, or scenarios where this search is preferred, leaving the agent without decision-making context.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

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 explains the search operation and the expected return content (matching lines with script names and line numbers). While it does not explicitly state read-only behavior or error handling, the search verb implies non-destructive behavior and the absence of side effects.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is a single, well-structured sentence that conveys the purpose, search method, and return format. Every word contributes value, with no redundant information or filler.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a tool with one parameter, no annotations, and no output schema, the description covers the essentials: it identifies the resource (RGSS scripts), the search mechanism (regex), and the result format. It does not elaborate on output structure or limitations, but these are minor gaps for a simple search tool.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The schema fully describes the single parameter 'pattern' as a regular expression, giving 100% coverage. The description confirms this but adds no additional semantics such as regex flavor, expected format, or examples, so it meets the baseline but does not exceed it.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool searches RGSS script sources with a regex pattern and returns matching lines with script name and line number. It specifies both the action and resource, distinguishing it from sibling search tools that target other entities.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description implies its usage—searching scripts by regex—but does not explicitly contrast it with alternatives like get_scripts or other search tools. No when-not-to-use or version exclusions are provided, leaving the guidance to inference from the tool's name and description.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

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 does add the useful detail that the search matches both name and description fields. However, it doesn't disclose match behavior (exact vs partial), case sensitivity, or return format.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is a single, front-loaded sentence with no redundant words. It conveys the action, resource, and search scope efficiently.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

The description covers the core action and search scope but omits details about the return value or result format. Without an output schema, the agent lacks clarity on what to expect from the tool. It is minimally complete for a simple search tool but leaves gaps.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The description clarifies that searchTerm is used to match against skill name and description, adding meaning beyond the schema's generic 'Search term' description. This helps the agent understand how to use the parameter effectively.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool searches skills by name or description, using a specific verb and resource. It is distinct from sibling tools like get_skills and get_skill due to the 'search' verb, though it doesn't explicitly name alternatives.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

No guidance is given on when to use this tool versus alternatives such as get_skills, create_skill, or search_items. There is no mention of intended use cases or exclusions.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

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 explicitly states that cells outside the map are skipped and that 0 clears a cell, which are important edge-case behaviors. However, it does not mention that existing tiles are overwritten (though 'stamp' implies this) or any irreversibility/side effects, so it is not maximally transparent.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

Three sentences, no filler, each sentence contributes essential information: the operation, grid semantics, out-of-bounds behavior, and a preview pointer. It is well-structured and front-loaded with the primary action.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the moderate complexity (5 params, no output schema), the description covers the core mechanics of stamping, the meaning of grid values, out-of-bounds handling, and a preview method. It does not explain the return value, but for a mutation tool that is not essential. It is nearly complete, though it could mention whether the stamp overwrites or merges.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 80% (mapId lacks a description), but the description adds clarifying semantics: 'grid is rows of ids (0 clears a cell)' goes beyond the schema's generic '2D array of tile ids (rows)', and 'top-left at (x, y)' clarifies the positional parameters. This adds value beyond the input schema.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description uses a specific verb ('Stamp'), names the exact resource (a 2D block of tile ids into a layer), and specifies the positioning (top-left at (x, y)). This clearly distinguishes it from sibling tools like fill_region or scatter_tiles, which have different operations.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description implies usage for placing rectangular blocks of tiles and suggests previewing with render_map, but it does not explicitly state when to choose this tool over alternatives like fill_region or scatter_tiles. No exclusions or alternative comparisons are provided.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

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 does not mention whether the operation overwrites existing names, requires specific permissions, handles invalid switch IDs, or produces any response. 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.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is a single, concise sentence with no unnecessary words. It is appropriately front-loaded and easy to parse.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

The tool is relatively simple with two parameters, but the description lacks usage guidelines and behavioral details. Given the absence of annotations and output schema, it is minimally adequate but leaves room for ambiguity around side effects and error handling.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 0%, and the description adds minimal meaning beyond the schema. It implies 'name' is the new name but does not clarify the format, constraints, or how 'switchId' identifies the switch. The description fails to compensate for the lack of schema descriptions.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the action ('Set') and resource ('switch name'), making the tool's purpose obvious. It doesn't explicitly differentiate from sibling tools like set_variable_name, but the resource type provides implicit distinction.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

No guidance is provided on when to use this tool versus alternatives (e.g., get_switches, set_variable_name), nor any prerequisites or conditions. The description only states what it does, leaving the agent to infer context.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

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 the action without mentioning side effects, permissions, or whether it's a safe reversible operation. The short phrase implies mutation but offers no depth.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is extremely concise at one sentence, but it under-specifies the tool. It doesn't earn its place because it merely restates the function name.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a simple two-parameter setter, the description is minimal but lacks context about the operation's behavior, return value, or relationships to sibling tools. The absence of annotations and output schema makes it incomplete.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 0%, and the description mentions 'a variable name' without explaining the variableId parameter or naming constraints. The description adds no meaning beyond the parameter names.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description 'Set a variable name' essentially restates the tool name verbatim, providing no additional scope or differentiation from siblings like set_switch_name. It conveys the basic action but nothing more.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

No guidance is provided on when to use this tool versus alternatives. It doesn't mention that it's for renaming a specific variable by ID, nor any context like verifying the variable exists.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

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 explain whether updates are merged or replace the entire actor, what happens if the actorId does not exist, or whether permissions are required. The list of fields gives some transparency but omits critical side effects.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is a single sentence that front-loads the action ('Update an actor's properties') before listing fields. While the list is long, it is purposeful and not padded with fluff. The structure is clear, though the enumeration could arguably be moved to the schema for brevity.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the tool's moderate complexity (nested updates object, no output schema), the description leaves significant gaps. It does not explain the update semantics (partial vs. full replacement), return behavior, or error conditions. The list of fields is helpful, but the lack of behavioral context makes the description incomplete for safe and correct invocation.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The schema only defines actorId and updates as a generic object, providing 100% coverage at a superficial level. The description adds essential semantics by enumerating the specific properties that can be updated (name, class_id, parameters, etc.), which goes beyond the schema and is critically useful. However, it does not explain the structure of nested fields like 'parameters' or acceptable value types.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool's function: 'Update an actor's properties' with a specific list of XP fields. This distinguishes it from sibling tools like get_actor or create_actor. The verb 'Update' is explicit and the resource is specific.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description provides no guidance on when to use this tool versus alternatives, nor does it mention any exclusions or prerequisites. It simply states the action, leaving the agent to infer that it is used for modifying existing actors. Sibling tools like create_actor or search_actors are not referenced.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations, the description carries the burden. It discloses important special formats (Table structure, tileset passage encoding) but does not clarify whether updates merge or replace properties, what happens on invalid values, or any permission requirements. Partial transparency.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

Three sentences deliver purpose, examples, and critical encoding rules without wasted words. The structure front-loads the action and then provides necessary specifics, making it easy to scan.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a generic update tool, the description covers the most complex edge cases (Tables and tileset passages) and provides enough context for the 'updates' object. It does not describe return values or error behavior, but given the tool's breadth, it is reasonably complete.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 0%, so the description compensates by defining the Table object format and the meaning of tileset passage values for the 'updates' parameter. The 'kind' enum and 'id' are self-explanatory from context, but the description does not enumerate all possible property keys for every kind.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool's purpose: 'Update any database entry's properties'. It provides concrete examples (class's weapon_set, state's rates, enemy's stats, tileset passability) that illustrate the scope and distinguish this generic tool from sibling update tools like update_actor or update_skill.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The phrase 'any database entry' implies generic usage, but the description does not explicitly tell when to prefer this tool over the specific update_actor/update_skill variants, nor does it mention any exclusions. Context is present but no explicit 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.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations are provided, so the description must fully disclose behavioral traits. It only says 'update' which implies mutation, but does not mention overwriting behavior, permission requirements, or effects on existing data. For a mutation tool, this lack of detail leaves the agent underinformed about 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.