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

The description aligns with annotations (readOnlyHint=true, destructiveHint=false) and adds detail: no project asset modification, expiring change set, and the interplay with createChangeSetId. This provides clear behavioral expectations beyond 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 three sentences front-loaded with the main purpose. Every sentence adds value, no fluff. Efficient and clear.

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

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

Given the complex input (6 parameters, nested objects) and presence of an output schema, the description covers the core behavior and special case. It could mention the output schema nature but suffices for a preview 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 67% (4 of 6 parameters described). The description adds context for createChangeSetId but no new details for other parameters. The schema does the heavy lifting, so baseline 3 is appropriate.

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

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

The description clearly states the action: validates a TSJ, assigns GID range, returns an expiring map change set. It specifies the resource (tileset to map) and distinguishes from sibling preview 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 explains when to use the createChangeSetId parameter for pending tileset creation. However, it lacks explicit guidance on when to use this tool vs alternatives or when not to use it, though the context is implied.

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 declare readOnlyHint=true, idempotentHint=true, destructiveHint=false. The description adds that hidden layers and tile objects are included, which is useful context beyond annotations. No contradictions; behavioral traits align with read-only operation.

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

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

Two sentences, no superfluous words. Every sentence adds value: one lists the computed summaries, the other notes inclusion of hidden layers and tile objects. Perfectly front-loaded.

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

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

Given the presence of an output schema and clear annotations, the description adequately covers the tool's behavior for a read-only analysis tool. However, it could briefly mention that results are bounded (e.g., top tile limit) to clarify scope.

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

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

Schema description coverage is 50% (2 of 4 parameters have descriptions). The description does not add any parameter details, failing to compensate for the undocumented parameters (topTileLimit, expectedDependencyRevisions). The agent must rely on schema alone, which is insufficient.

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 bounded whole-map tile frequency, layer density, transform, used-tileset, and unused-local-ID summaries, using a specific verb (returns) and resource (tile usage summaries). It distinguishes from sibling tools like tiled_get_map_summary and tiled_find_tiles by focusing on usage analytics.

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

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

No guidance on when to use this tool versus alternatives such as tiled_get_map_summary or tiled_find_tiles. The description does not provide context hints or exclude scenarios, leaving the agent to infer appropriateness.

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 already declare destructiveHint=true and idempotentHint=true. The description adds context about checking revision, evidence, and dependency pins, and mentions persisting safety metadata. No contradictions; the description supplements the annotations well.

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 with specific change types, which is informative, but slightly verbose. The first sentence front-loads the core purpose, making it efficient despite length.

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 tool complexity, the description enumerates all supported change types and the validation checks. Output schema exists (not shown), so return details are covered. The description fully captures the tool's scope and requirements.

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

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

Schema has 2 parameters: changeSetId (pattern only) and expectedRevision (pattern + description). The description adds context that the revision must be 'approved' and from a preview, but does not explain the patterns or provide additional parameter semantics beyond what the schema gives. With 50% schema coverage, the description partially compensates.

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

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

The description explicitly lists many types of changes this tool applies (e.g., map edit, tileset edit, file deletion, checkpoint restore), and clearly states it applies a previously previewed change set after validation. This specificity distinguishes it from sibling preview 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 after a preview operation (e.g., 'previously previewed'), and the sibling tools are predominantly preview operations, making the tool's role clear. However, it does not explicitly state when not to use it or name alternatives for similar actions.

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 already indicate readOnlyHint: true, idempotentHint: true, destructiveHint: false. The description adds behavioral context beyond these: 'endpoints on blocked cells fail closed', 'flip bits never affect matching', and outlines the return values (passable/blocked counts, connected components with representative cells, and connectivity between two points). This provides useful additional insight for the agent.

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 paragraph that front-loads the core function and then details modes and return values. It is concise with no redundant sentences. However, it could benefit from bullet points or clearer separation of concepts for even faster parsing.

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 (5 parameters, nested objects, output schema), the description provides a comprehensive behavioral overview including return values and edge cases (e.g., blocked cells). The existence of an output schema reduces the need to describe return types fully. Minor gaps exist for mapPath and layerId, but overall it is sufficiently complete for agent understanding.

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 20% (low). The description partially compensates by explaining the 'passable' parameter's two modes and the role of 'from'/'to' for connectivity queries. However, it does not describe the 'mapPath' or 'layerId' parameters beyond what the schema provides, leaving some semantic gaps.

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

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

The description clearly states the tool performs bounded four-way connectivity analysis over a finite tile layer, with explicit passability modes (empty-cells vs listed-tiles). It also lists what it returns (counts, components, connectivity) and distinguishes from sibling tools like tiled_get_region or tiled_find_tiles through its specific focus on connectivity.

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 over alternatives or when not to use it. While the purpose is clear, there is no guidance on comparison with other tools for pathfinding or region analysis. The usage context is implied by the tool's name and description, but not directly addressed.

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?

The description adds value beyond annotations by explaining that the checkpoint is 'committed', 'without modifying any project asset', and that restoring reproduces state 'byte for byte'. Annotations already indicate non-destructive, but the description provides deeper behavioral context.

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

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

Two sentences, no filler. Every clause adds meaning: the action, the scope, the side-effect-free nature, and the comparison to automatic checkpoints.

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 tool's purpose, safety profile, and use case adequately for a moderate-complexity tool. It does not explain the output schema or return values, but those are provided separately. Minor gap: no mention of label semantics.

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 0% schema description coverage, the description should compensate but only vaguely implies that 'paths' refer to project files. The 'label' parameter is not addressed. The schema constraints (maxItems, etc.) are not reiterated or explained.

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

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

The description clearly states it 'Creates committed recovery checkpoints of the exact current bytes of 1 to 32 project files' and emphasizes it is an explicit save point distinct from automatic checkpoints. The verb and resource are specific, and the scope (number of files, no modification) is precise.

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 positions the tool as 'an explicit save point before risky work', giving clear context for when to use it. However, it does not explicitly exclude any scenarios or mention alternatives among siblings like tiled_preview_checkpoint_restore.

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 already declare readOnlyHint=true, so the description adds value by disclosing the expiring change set and the no-modification guarantee. No contradictions.

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

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

Two concise sentences, front-loaded with key information, no redundant 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 output schema exists and annotations cover safety, description adequately covers behavioral constraints and conditional parameters. Could mention that the change set is expiring, but that's already stated.

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 56%; description adds the crucial conditional logic for imagePath and expectedImageRevision based on type, which is not fully captured in the schema descriptions. Also hints at 'root/group insertion index' for parentGroupId.

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

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

Description uses specific verb 'plans' and resource 'empty tile, object, image or group layer', clearly distinguishing from sibling tools like tiled_create_map (which creates actual maps) and tiled_preview_edits (general edits).

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?

Context is clear (preview a new layer), but no explicit when-not-to-use or alternatives are mentioned. However, the purpose and sibling list imply the proper 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?

Annotations indicate a write operation (readOnlyHint=false) and non-destructive (destructiveHint=false). The description adds behavioral details: it is a direct mutation without preview, will not overwrite existing files, and requires parent directories. This adds value beyond 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 only two sentences, efficiently conveying core behavior and conditions. The first sentence could be clearer, but overall it is concise with 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?

Despite having an output schema, the description does not explain return values or success criteria. Given the complexity of a creation tool and low parameter coverage, the description omits important context about what happens on success or error.

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 17% (only mapPath has a description). The tool description does not describe any parameters, failing to compensate for the low coverage. Width, height, tileWidth, tileHeight, and backgroundColor are undocumented.

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 it creates an empty TMJ map, which is distinct from sibling creation tools like tiled_create_tileset or tiled_create_layer. However, the phrasing 'sole additive no-preview mutation exception' is cryptic and reduces clarity slightly.

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?

Conditions like 'parent directories must exist' and 'never overwritten' are given, but there is no explicit guidance on when to use this tool over alternatives. The context of map creation is implied but not directly compared to siblings.

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 declare readOnlyHint=true and destructiveHint=false; the description confirms 'without modifying project assets' and adds extra behavioral details: returns an expiring change set, expectedRevision is SHA-256 of prospective bytes, and overwrite prevention. No contradictions.

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 with no redundancy. The first sentence conveys the main action, computation, and output; the second adds critical behavioral constraints. Every sentence earns its place.

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

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

Given 8 parameters and low schema coverage, the description covers the core purpose, formula, return type, and a key constraint. It could mention optional parameters for completeness, but the description suffices for an agent to understand the tool's main behavior.

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

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

Schema coverage is 25% (only imagePath and tilesetPath have descriptions). The description adds context for margin/spacing via the Tiled formula and mentions 'existing project image' for imagePath, but does not fully compensate for undocumented parameters like name, className.

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 'plans one new external atlas TSJ from an existing project image' using a specific formula, and explicitly distinguishes itself from tiled_create_map as the 'sole direct creation exception.' The verb 'plans' and resource 'external atlas TSJ' are precise.

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 context that this tool returns an expiring change set and that apply refuses to overwrite existing destinations, implying it is for previewing not direct creation. It mentions the sibling exception (tiled_create_map), but does not explicitly contrast with other preview tools like tiled_preview_write_tsx.

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?

The description explicitly states the tool itself modifies nothing, aligning with the readOnlyHint annotation. It details the reference scan and checkpoint commit behavior, adding significant context beyond 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 detailed but not overly long; it front-loads the purpose. However, the technical details on reference scan types could be slightly more 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 description covers the tool's non-destructive nature, the reference scan preconditions, and the checkpoint mechanism, providing a complete behavioral picture given the annotations and 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?

The single 'path' parameter has full schema coverage, and the description adds clarity by specifying it must be a canonical project-relative POSIX path, reinforcing the schema's constraints.

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: planning permanent deletion of a TMJ map or TSJ tileset. It uses a specific verb and resource, distinguishing it from sibling tools that deal with checkpoints, rendering, or other 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 when to use (for planning deletion of a single project-local file) but does not explicitly mention when not to use or provide alternative tools. The reference scan details give context, but no direct comparison to siblings.

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 already indicate read-only, idempotent, non-destructive behavior. The description adds behavioral context: it returns bounded TileRefs ordered by local ID, and searches for exact matches. This goes beyond the structured fields.

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

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

The description is a single sentence that front-loads the purpose. It is efficient but somewhat wordy; still, every part contributes meaning.

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 (7 parameters, nested query, siblings), the description covers the main purpose and search capabilities but omits the query mode (all/any) and details about startTileId and expected revisions. The output schema exists, so return value explanation is not needed.

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 explains the query semantics (class and propertyEquals) which maps to the complex query object, but does not cover startTileId, limit, expected revisions. With 43% schema description coverage, more detail would be helpful, but the description adds value for the core parameters.

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 an external TSJ for exact tile classes or serialized scalar properties, returning bounded TileRefs ordered by local ID. It uses specific verbs and resources, and distinguishes itself from siblings like tiled_list_tile_names or tiled_render_tiles by focusing on semantic 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 usage for finding tiles by class or property values, but does not explicitly state when to use this tool versus alternatives (e.g., tiled_list_tile_names for listing all names, tiled_render_tiles for rendering). No 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?

Annotations already declare readOnlyHint=true, idempotentHint=true, destructiveHint=false, ensuring the agent understands it's safe and side-effect-free. The description adds value by specifying the exact content returned (edit profile, threat model, etc.), which goes beyond annotations to clarify what 'capabilities' means.

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 and front-loaded with the action 'Returns'. Every word adds value with no repetition 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 low complexity (zero parameters, output schema exists), the description fully covers what the tool does. It explains the three categories of returned information in natural language, which complements the 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?

The tool has zero parameters, so per the calibration guidance, a baseline score of 4 is appropriate. No additional parameter semantics needed as the schema coverage is 100% (vacuously).

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 what the tool does: it returns specific Tiled capabilities (edit profile, threat model, operational requirements, command-line adapters). The verb 'Returns' and the listed resources are precise. It distinguishes from siblings which are about specific operations like creating or previewing.

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, nor does it provide usage context or exclusions. However, given the tool's purpose (inspecting capabilities) and the lack of similar siblings, it is minimally adequate. No guidance on 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?

Annotations already declare readOnlyHint=true, destructiveHint=false, idempotentHint=true. The description adds significant behavioral context: embedded inline tilesets are read-only and pinned by revision, infinite maps report infinite:true and chunked bounds, isometric maps are readable but read-only, staggered/hexagonal are rejected, and XML maps go through a fail-closed subset reader with editable:false. This goes well beyond 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 detailed but not excessively verbose. It covers essential aspects in a logical order: what is read, special cases for inline tilesets, infinite maps, isometric, staggered/hexagonal, and XML. Each sentence adds value, though it could be slightly more 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?

Given the complexity of map types (infinite, isometric, staggered, hexagonal, XML) and the availability of an output schema, the description thoroughly covers behaviors, constraints, and return markers. It addresses read-only aspects, revision pinning, and edge cases. No missing information for a read 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?

With only one parameter (mapPath) and 100% schema description coverage, the schema already documents the path constraints. The tool description does not add further meaning about the parameter beyond what the schema provides. Baseline 3 is appropriate as schema covers the parameter adequately.

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 'Reads' and enumerates the exact resources and metadata it returns (dimensions, metadata, revision, layer tree, tileset identities). It explicitly distinguishes itself from editing tools by noting 'before editing' and handling of different map types (infinite, isometric, staggered, hexagonal, XML), making its purpose clear and distinct from 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 description clearly indicates this tool is for reading a map summary before editing, implying it should be used when preparing to edit. It specifies when certain map types are readable or rejected (e.g., staggered/hexagonal rejected, XML returns editable:false). However, it does not explicitly mention when not to use it or name alternative tools, though the context from siblings helps infer.

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?

Despite annotations already indicating read-only, idempotent, and non-destructive behavior, the description adds substantial value by detailing the return structure (geometry, styling, properties), handling of value types (scalar, enum, object-reference, nested, oversized), and template expansion behavior including merge rules and error handling ('fail closed').

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 front-loaded with the main action and packs detailed information, but it is somewhat dense and could be more concise. However, every sentence provides necessary behavioral details.

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

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

Given the tool's complexity, the presence of annotations and an output schema, the description covers all key aspects: return values, edge cases (oversized entries, template failure), and template behavior. It provides a comprehensive understanding without relying on the 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 50% (only mapPath has a description; objectId lacks one). The description does not add parameter-specific semantics beyond the overall return context, which partially compensates but does not fully clarify the meaning or usage of each parameter.

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

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

The description clearly states the tool 'Returns one supported object' with specific details like shape-specific geometry, text styling, and custom properties. It distinguishes itself from siblings like tiled_list_objects by emphasizing the complete and detailed nature of the returned object.

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

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

The description implies usage for retrieving a single object with full details, but it does not explicitly state when to use this tool versus alternatives like tiled_list_objects. No exclusionary guidance or when-not-to-use scenarios 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?

Beyond annotations (readOnlyHint, idempotentHint, destructiveHint), the description provides significant behavioral detail: embedded tilesets yield a read-only reference, infinite maps use absolute coordinates with empty cells outside chunks, and XML maps return raw GIDs with flip bits and firstgid ranges. It also notes failure modes for plain tile elements and chunks, adding concrete constraints.

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 packed with information and avoids redundancy, but its single-paragraph structure could be more scannable with bullet points or clearer separation of map types (infinite vs. XML vs. finite). It is not overly long, but a slight reorganization would improve readability.

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, the description covers most edge cases (embedded tilesets, infinite maps, XML maps) and failure modes. An output schema exists to document return values. However, it does not mention potential performance implications or pagination (if any), which could be relevant for large regions. Still, it is largely complete.

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

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

With 17% schema description coverage (only mapPath described), the description adds some high-level context (coordinate system, tile ID references) but does not explain each parameter individually. For example, x, y, width, height are not explicitly defined as the rectangle's origin and dimensions, and layerId is not mentioned. The description fails to fully compensate for the schema's lack of 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 clearly states that the tool returns a bounded rectangular tile region, specifying the use of tileset asset IDs and local tile IDs. It distinguishes itself from siblings like tiled_find_tiles or tiled_get_map_summary by detailing unique behaviors for embedded tilesets, infinite maps, and XML maps, making the purpose unambiguous.

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

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

The description implicitly indicates usage for rectangular tile regions but lacks explicit guidance on when to use this tool versus alternatives such as tiled_get_tileset or tiled_find_tiles. It does not state prerequisites or scenarios where this tool is preferred, leaving the agent to infer from 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?

Annotations already declare readOnlyHint=true, idempotentHint=true, destructiveHint=false. The description adds value by detailing what the summary includes (sparse tile metadata, animation, collision shapes, Wang sets) and limitations (omission markers for oversized entries, collection Wang sets fail closed).

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 clearly structured with front-loaded purpose and layered details. Some sentences are dense and could be simplified, but the information is well-organized and relevant.

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 (5 parameters, output schema exists), the description is quite complete. It covers return value content, edge cases (omission markers), and failure conditions. The presence of an output schema reduces the burden, and the description adds useful summary context.

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

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

Schema coverage is only 20% (only mapPath described). The description adds meaning for the selectors (tilesetAssetId, embeddedIndex) by explaining their roles, but it does not provide additional semantics for limit or startTileId beyond their schema defaults and constraints.

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 bounded semantic summary of one tileset referenced by a map. It distinguishes two selector methods (external TSJ by tilesetAssetId or embedded by embeddedIndex), which differentiates it from sibling tools like tiled_get_map_summary or tiled_list_tile_names.

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

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

The description explicitly notes that exactly one selector is required (tilesetAssetId or embeddedIndex) and mentions failure modes for embedded image-collection tilesets. However, it lacks explicit guidance on when to use this tool versus alternatives like tiled_get_map_summary for broader map data.

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 already indicate read-only, idempotent, and non-destructive behavior. The description adds value by revealing two key behaviors: it lists bounded manifests (implying pagination or limits) and separately reports corrupt entries. This goes beyond what annotations provide, and there is no contradiction.

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 concise sentences. The first sentence states the core action, and the second sentence clarifies a critical behavioral constraint. No extraneous 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 description covers the tool's purpose and key behavioral traits, and an output schema exists (though not shown). However, it fails to document any parameters, leaving a significant gap in understanding how to 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 description coverage is 0%, meaning no parameter descriptions exist. The description does not explain the purpose or usage of limit, status, or scanLimit, forcing the agent to infer from names and schema constraints alone. This is inadequate compensation.

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

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

The description clearly states it lists bounded checkpoint manifests and reports corrupt entries, which is a specific verb+resource combination. It distinguishes from siblings by explicitly stating it never restores or deletes files, contrasting with tools like tiled_preview_checkpoint_restore and tiled_preview_checkpoint_prune.

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 inspection without modification, but lacks explicit when-to-use or when-not-to-use guidance. It does not mention alternatives (e.g., other list tools) or prerequisites. The statement 'never restores or deletes files' provides indirect context but is not a full usage guideline.

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 already declare readOnlyHint=true, idempotentHint=true, destructiveHint=false. The description adds no behavioral details beyond 'Lists'. No contradiction, but minimal added 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?

A single 16-word sentence directly stating purpose, no unnecessary words. Very 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?

Despite having an output schema, the tool has many siblings and a parameter that affects results. Missing details: recursion depth, scope of 'under the configured project root', effect of limit parameter, and differentiation from other list tools.

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

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

The input schema has 1 parameter (limit) with 0% description coverage. The description does not explain the limit parameter's behavior or effect on results.

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

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

The description clearly states it lists specific asset types (maps, tilesets, templates, worlds, projects) under the project root. This distinguishes it from siblings like tiled_list_world_maps (world-only) or tiled_list_objects.

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

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

No explicit guidance on when to use or avoid this tool compared to alternatives like tiled_list_world_maps or tiled_list_tile_names. Usage is implied as a generic project file listing, but no when-to-use or when-not-to-use 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?

Annotations already declare readOnlyHint=true, idempotentHint=true, destructiveHint=false, indicating safe operation. Description adds the bounded nature and layer filtering behavior, though no details on pagination or performance.

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 that is front-loaded, concise, and contains no superfluous 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?

Adequately covers the main purpose and mode switching, but omits details like pagination, sorting, and output format (though output schema exists). Reasonable for a simple listing tool with strong annotations.

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 33% (mapPath described). Description does not explain limit or layerId parameters beyond implying layer selection. Does not compensate for missing schema descriptions.

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

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

The description clearly states it returns a bounded list of objects from all object layers or one selected layer. This distinguishes it from sibling tools like tiled_get_object (single object) and other listing 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?

No guidance on when to use this tool vs alternatives such as tiled_get_object for a single object. The description does not mention exclusions or 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?

Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false. The description adds 'malformed entries fail closed,' which provides error behavior context beyond the 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?

Two sentences, front-loaded with the core action. Every word adds value, no redundancy.

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

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

Given the simple tool with one parameter and presence of an output schema, the description sufficiently explains the tool's behavior and return value (verbatim propertyTypes). No 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 100% with a clear description for projectFilePath. The description adds no extra semantics beyond the schema, meeting the baseline for high coverage.

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

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

The description clearly states it reads a .tiled-project file and returns its propertyTypes definitions verbatim. It specifies 'authoritative source' and distinguishes itself from preview siblings, making the purpose precise and differentiated.

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 retrieving property type definitions from a .tiled-project file. While it doesn't explicitly state when not to use or mention alternatives, it provides sufficient context for when to invoke this tool.

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?

Adds significant behavioral details beyond annotations: reads a specific file, validates entries, pins revisions, notes weak metadata and empty-file handling. No contradictions with annotations (readOnlyHint, idempotentHint, destructiveHint).

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?

Every sentence adds unique value: defines the registry, validation rules, constraints, edge cases, and read-only nature. No redundant or filler content.

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?

Covers all necessary aspects for a zero-parameter, read-only tool: what it reads, content format, constraints, error handling (missing file), and purpose. With an output schema present, it does not need to detail return format.

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?

No parameters exist (0 params), so the description has no need to add parameter semantics. Baseline 4 is appropriate as the description fully compensates for the absence of param details by explaining the tool's operation.

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?

Clearly states it reads a server-owned registry (specific resource) and explains its purpose of mapping names to tileset/localId. Distinguishes from sibling tools like tiled_list_files or tiled_get_map_summary by focusing on tile name registration.

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 it is read-only and describes the context where it is useful (referencing tiles by semantic name). Does not exclude alternatives or provide when-not-to-use guidance, but the purpose is clear enough for an agent to decide.

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 declare readOnlyHint=true and idempotentHint=true, and the description aligns with these by specifying it reads and returns data. The description goes beyond annotations by detailing expandPatterns semantics, pattern matching, lack of deduplication, and output structure, providing useful behavioral context.

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

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

The description is fairly long and dense, packing many details into one paragraph. While it is front-loaded with the main purpose, the length could be reduced by splitting into multiple sentences or bullet points. It is informative but not optimally 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?

Given the complexity of world maps with pattern-based members, the description covers key aspects: explicit members, coordinates, sizes, pinned revisions, custom properties, and expandPatterns behavior. The presence of an output schema (not shown) likely covers return values, so the description is sufficiently complete for agent understanding.

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 50% (worldPath has description, expandPatterns does not). The description compensates by explaining expandPatterns thoroughly: when true, it matches patterns with specific semantics, uses multipliers/offsets, and appends members without deduplication. This adds significant meaning beyond the schema.

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

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

The description clearly states the tool reads a project-local JSON .world file and returns explicit map members with world coordinates, sizes, per-member existence, pinned revisions, and custom properties. It distinguishes itself from sibling tools by focusing specifically on listing world maps, not other Tiled resources.

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 the behavior when expandPatterns is passed but does not explicitly state when to use this tool versus alternatives like tiled_list_files or tiled_get_map_summary. Usage context is implied (reading world maps) but lacks explicit guidance on 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?

Annotations declare readOnlyHint=true, and the description confirms no deletion occurs, adding details on the destructive proposal (manifest removal, fail-closed garbage collection) without contradicting the read-only nature. No annotation contradiction.

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

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

Two concise sentences that are front-loaded with the core action and include necessary details without 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 single parameter and presence of an output schema, the description covers purpose, constraints, and behavioral outcomes thoroughly, referencing appropriate alternatives.

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

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

The input schema has a single required 'checkpointId' with 0% description coverage, but the description does not explicitly explain this parameter. While the purpose is inferable, the description should have clarified that checkpointId is the UUID of the checkpoint to preview prune.

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 previews pruning a committed recovery checkpoint by returning a destructive proposal without deleting, distinguishing it from siblings like tiled_preview_prepared_checkpoint_discard which handle prepared checkpoints.

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 that prepared checkpoints are rejected and suggests using the dedicated safe-discard preview when eligibility is proven, providing clear guidance on when not to use this tool.

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

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

The description describes a destructive, non-atomic pruning process with sequential removal and garbage collection, which contradicts the annotations that set readOnlyHint to true and destructiveHint to false. This inconsistency severely misleads the agent about the tool's nature.

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 front-loaded with the core action and uses efficient sentences. Each sentence adds necessary detail, though the technical density could be slightly streamlined without losing clarity. Overall, it is appropriately sized for the complexity.

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 simple input schema and the existence of an output schema, the description sufficiently covers input semantics, behavior, error scenarios (stop on first failure, caching), and side effects (garbage collection). The contradiction with annotations is a flaw but does not diminish the completeness of the behavioral description itself.

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 0% schema description coverage, the description fully compensates by explaining that checkpointIds must be committed recovery manifests, in UUID format, 2 to 32 items, canonicalized to lowercase, ordered by ID, and that prepared checkpoints or duplicates are rejected. This adds comprehensive meaning beyond the bare 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 that the tool pins, canonicalizes, and orders checkpoint manifests, and it details the pruning process. The name 'prune_batch' and the sibling 'tiled_preview_checkpoint_prune' imply batch functionality, and the description explicitly mentions batch behavior with a range of 2 to 32 manifests.

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 specify when to use this tool over its siblings. No alternatives, prerequisites, or exclusions are mentioned; it only describes the internal process without context for selection.

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 declare readOnlyHint=true and destructiveHint=false. The description adds significant behavioral detail: the tool only returns a proposal, does not write, handles missing target files with specific revision matching, and restores only the document (not referenced files). No contradiction with 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 reasonably concise at four sentences, front-loading the key action. It packs essential details without excessive verbosity, though the first sentence is somewhat long and could be split for clarity.

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 an output schema for return values, the description covers core behavior, scope limitation, and missing file handling. Minor gaps include lack of explicit prerequisites (e.g., checkpoint existence) and multi-step process context, but these are inferable from sibling names and overall workflow.

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 50% (only expectedRevision has a description). The tool description does not explain the parameters, missing checkpointId meaning entirely. It mentions 'pins the current target revision' which relates to expectedRevision but is not explicit. Description fails to add value over 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 validates a checkpoint, pins a revision, and returns a destructive restore proposal without writing. It distinguishes itself from sibling commit/discard tools by emphasizing 'without writing' and only restoring the specific document, not referenced files.

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

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

The description implies usage for previewing before commit and addresses edge cases like missing files. It provides clear context but does not explicitly state when to use versus alternatives like tiled_preview_prepared_checkpoint_commit, though the read-only nature and 'proposal' wording serve as implicit 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?

The description adds value beyond annotations by explicitly stating 'without modifying project assets' and that it 'returns an expiring changeSetId bound to the exact map and current dependency revisions'. Annotations already set readOnlyHint=true, so the description reinforces this. It also details the types of operations supported, though it does not disclose all potential side effects (e.g., error behaviors). No contradictions with 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, very long sentence that lists numerous operations in a dense, run-on format. It is not structured for easy parsing; bullet points or shorter sentences would improve readability and conciseness. The front-loaded purpose is good, but the rest is overwhelming.

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 input schema, the description covers the main purpose, non-modification behavior, the returned changeSetId, and an exhaustive list of supported operations. It does not discuss error handling or prerequisites, but the output schema (not shown) likely covers return values. Overall, it provides sufficient context for an agent to understand the tool's capabilities.

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 50% schema coverage, the description compensates by enumerating and explaining the many operation types, including nuanced details like tile object encoding and shape constraints. However, it does not provide additional meaning for the top-level parameters (mapPath, expectedRevision, expectedDependencyRevisions) beyond what the schema already describes.

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 validates root map-property updates and various other edits without modifying assets, and returns an expiring changeSetId. The verb 'Validates' and the purpose 'Preview map edits' are specific and distinguishable from sibling tools like tiled_preview_shape or tiled_preview_generate.

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. It implies usage for previewing edits before committing, but lacks guidance on when not to use it or how it compares to other preview or edit tools. No exclusions or alternative recommendations are provided.

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

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

The description discloses key behaviors: deterministic seeding, translation stability, failed-closed for unmatched cells or small dungeon regions, and math.random avoidance. Annotations declare readOnlyHint=true, which is consistent since the tool previews changes without applying them. No contradiction present.

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 informative, front-loading the purpose. Every sentence adds value, though some technical details could be more succinct. It avoids redundancy with the schema and annotations.

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 (three generator algorithms, mapping intervals, edge cases), the description covers deterministic behavior, translation stability, failure modes, and the nature of the output (change set). The presence of an output schema further reduces burden.

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 low (25%), but the description compensates by explaining semantics of seed, region, generator types, mapping intervals, and failure modes. For example, the mapping section clarifies interval behavior and the generator section describes each algorithm's parameters and constraints.

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 that the tool computes deterministic seeded value fields (noise, cellular, dungeon) over a bounded region, maps values to tiles via intervals, and returns a mapEdit change set. This distinguishes it from sibling tools like tiled_preview_edits or tiled_preview_shape, which handle manual edits or shapes.

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 procedural generation previews (noise, cellular, dungeon) but does not explicitly state when to use this tool versus alternatives like tiled_preview_edits or tiled_preview_scatter. No exclusion criteria 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?

The description adds behavioral context beyond annotations: it describes deterministic behavior, handling of transparency and null tiles, and failure mode for fully transparent regions. The readOnlyHint is consistent with returning a change set (not applying it). No contradiction.

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 paragraph that front-loads the main action. It is concise with no redundant information, though slightly lengthy for the level of detail.

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 output schema (not shown), the description adequately covers key behaviors and edge cases. It explains the return type (change set) and deterministic plan. However, more detail on parameter interdependencies 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?

Schema description coverage is low (43%), and the description does not detail parameter meanings or constraints beyond the algorithm's overview. Parameters like region, layerId, and palette are not explained, leaving gaps for the agent.

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 title and description clearly state the tool's function: previewing the import of a reference image by resampling it onto a cell grid and converting to palette colors. It is distinct from other tiled preview tools (e.g., tiled_preview_edits, tiled_preview_shape) which handle different tasks.

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 previewing an image import, but lacks explicit guidance on when to use this tool over alternatives, prerequisites, or when not to use it. No sibling 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?

The description describes mutating operations (stamping tiles, creating objects) but annotations set readOnlyHint=true, a direct contradiction. This is a serious inconsistency.

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 dense paragraph that front-loads the core action but is overly wordy and lacks structure (e.g., bullet points or separate sections).

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, missing output schema details, and the annotation contradiction, the description fails to provide a reliable understanding. It omits discussion of return values and the contradiction undermines trust.

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 36% schema coverage, the description adds significant meaning beyond schema, explaining copyEmpty, flipHorizontal, extraTileLayers, and how parameters interact (e.g., failing closed for cross-map stamps with differing tile sizes).

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 that the tool stamps a source-map region as a prefab, involving tiles and objects. This distinguishes it from siblings like tiled_preview_template and tiled_preview_edits, though not explicitly.

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 (stamping a prefab region) but lacks explicit guidance on when not to use or alternatives. It does not distinguish from other preview tools directly.

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 already indicate readOnlyHint=true, so description supplements by detailing the real operation's effects (deletion of recovery manifest, garbage collection) and rejection criteria. No contradiction with 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?

Description is detailed but efficient, with key info upfront. Could be slightly more concise, but no extraneous content.

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?

Covers tool behavior and edge cases (state rejection) well. Missing parameter documentation, but given output schema exists, return values are not needed. Overall sufficient for agent understanding.

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 description does not explain the 'checkpointId' parameter. With a single required UUID parameter, the description should clarify its role (e.g., identifies which checkpoint to preview abandon).

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

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

Description clearly states it previews an abandon operation for ambiguous prepared checkpoints by pinning manifests and returning a destructive proposal. It distinguishes from siblings like preview_discard and preview_commit by specifying the conflict type processed.

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 when to use (ambiguous prepared-checkpoint conflicts), what states are rejected (safe-discard, machine-reconcilable exact-after), and what remains eligible (create exact-after). Also notes absence of a generic force flag.

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 already provide readOnlyHint=true. The description adds valuable behavioral details: it pins the manifest, requires exact match, returns a proposal without modifying assets, explains the effect of applying the proposal, and clarifies that it cannot restore as deletion. No contradiction with 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 compact yet comprehensive. Every sentence adds necessary information without redundancy. It is front-loaded with the core purpose and scales to behavioral specifics. 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 single parameter, clear annotations, and the presence of an output schema (inferred), the description covers all essential aspects: when to use, what it does, what it returns, and what it avoids. It is fully adequate for an AI agent to invoke 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?

The schema has one parameter (checkpointId) with 0% description coverage. The description adds context by specifying that the checkpoint must be from an ambiguous create, providing meaning beyond the schema's UUID pattern. However, it does not elaborate on the parameter's syntax or format.

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

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

The description clearly states it is a preview of committing an ambiguous prepared recovery checkpoint. It specifies the action verb 'preview' and the resource 'ambiguous prepared recovery checkpoint', distinguishing it from sibling preview tools like discard or abandon.

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

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

The description explicitly limits usage to 'for an ambiguous create checkpoint only', indicating when to use. It explains the return of a proposal without changes, and what it does not do (no garbage collection, no force flag). While it does not explicitly compare to siblings, the naming and context make it clear this is for the commit preview.

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 declare readOnlyHint=true and destructiveHint=false, and the description confirms this by stating it returns a proposal without deleting or modifying assets. The description adds detailed behavioral context (pinning manifest, proving state, rejection conditions) beyond what annotations provide. No contradiction.

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 adds value without redundancy. The first sentence states the main action and constraints, the second clarifies what does not happen, and the third lists rejection conditions. 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?

For a preview tool with one parameter and an output schema, the description covers purpose, preconditions (target state), and rejection cases. It does not detail the output schema, but that is acceptable since it exists separately. Slight omission: the checkpoint must be in a prepared state, but this is implied by the tool name and 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?

The single parameter checkpointId is described indirectly via 'pins one prepared checkpoint manifest' and the title mentioning 'prepared recovery checkpoint'. The schema has a UUID pattern and is required. While the parameter's role is inferable, the description does not explicitly define it or explain where to obtain the ID. With 0% schema description coverage, more explicit parameter guidance would improve clarity.

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: it pins a prepared checkpoint manifest and proves the target state, returning a discard proposal. It distinguishes from siblings (commit, abandon) by specifying that it is for discard preview. The conditions for rejection are listed, making the purpose unambiguous.

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

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

The description implies when to use: for previewing a discard operation on a prepared checkpoint. It lists states that lead to rejection, effectively telling the agent when the tool will fail. However, it does not explicitly compare with alternatives like tiled_preview_prepared_checkpoint_commit or abandon, though the name and title provide 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?

Annotations already indicate readOnlyHint=true and destructiveHint=false. The description adds behavioral details on upsert/delete mechanics, reference checking, and that it returns an expiring change set without contradicting annotations. Provides useful context beyond 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?

Description is somewhat long but each sentence serves a purpose, front-loading the main action. Could be slightly more concise but still effective.

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

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

Given complexity (nested operations), the description covers key behaviors for each operation type, reference limitations, and output nature. Output schema exists so return values not needed. Missing error handling but overall complete for a preview 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 67%, baseline 3. Description adds context like 'Apply patches only the propertyTypes member under the pinned project-file revision' but does not explicitly describe each parameter beyond implicit mention. Adequate but not exceptional.

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

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

The description clearly states it validates sequential upsert/delete edits to propertyTypes definitions, using specific verbs ('validates') and resources ('propertyTypes'). It distinguishes itself from siblings like tiled_preview_edits by being property-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 explains when to use (to preview property type edits) and provides details on what it does (validates, returns change set). It mentions limitations (references not scanned) but does not explicitly exclude alternatives. Overall clear 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?

The description goes well beyond annotations by detailing the internal deterministic algorithm (stateless coordinate hash, salted hash, no Math.random), explains skipOccupied and null choice behavior, and notes that a match failure fails closed. This adds significant behavioral context not captured in readOnlyHint=true.

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 paragraph of four sentences, each packed with necessary information. It is front-loaded with the action and algorithm, then covers edge cases and return value. 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 complexity and many siblings, the description covers the core behavior well and mentions the return type (mapEdit change set). However, it does not explain what 'fails closed' means precisely or how this tool fits among other preview tools. The presence of an output schema partially reduces the need for return-value details, but a bit more context would help.

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?

Given schema description coverage is only 22%, the description should elaborate on parameter meanings but only mentions 'mapPath', 'layerId', 'region', 'seed', 'density', 'choices' in passing without detailing their roles, constraints, or interactions. It does not compensate for the sparse 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 tool's action: 'Scatters decoration tiles over one bounded region' with a deterministic algorithm. It uses a specific verb ('preview') and resource ('decoration tiles') and distinguishes from siblings by highlighting the deterministic density roll and hash-based selection, which is unique among the many preview 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 implicitly conveys when to use this tool: for deterministic scatter patterns with seed-controlled randomness. It explains key features like translation-stability and skipOccupied, but does not explicitly compare to alternatives like tiled_preview_edits or tiled_preview_generate, nor 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?

Annotations already indicate readOnlyHint=true and destructiveHint=false. The description adds valuable behavioral traits: determinism, no randomness, no clipping (fails closed), at most 10,000 cells, null tile erases, and that preview/revision-pin/transaction rules apply. This significantly informs the agent beyond the 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 two sentences, front-loaded with the core action in the first sentence and constraints in the second. Every phrase adds value with no redundancy.

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

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

Given the tool's complexity (nested draw schema, 6 parameters) and the presence of an output schema, the description covers essential behavioral constraints (determinism, cell limit, null tile) and integrates with the preview workflow. Minor gaps like how to apply the change set are addressed by 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?

Schema description coverage is only 33%, placing the burden on the description. It adds meaning for the tile parameter (null erases) and explains the shape types, but does not detail the draw property's substructures, layerId, mapPath, or revision parameters. Some improvement over the bare schema but incomplete.

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 'rasterizes one deterministic geometric shape' into tile cells and returns a change set. It names specific shapes (Bresenham line, rectangle, ellipse), making the purpose highly specific and distinguishable from sibling preview tools like tiled_preview_edits or tiled_preview_generate.

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

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

No explicit guidance on when to use this tool versus alternatives is provided. The description explains what the tool does but does not contrast it with other preview tools or state prerequisites. Given the large set of sibling preview tools, this omission reduces usability.

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?

The description adds behavioral details about validation, pinning, and re-verification. However, the use of 'places' may misleadingly suggest a write operation, given readOnlyHint=true. The description should more clearly emphasize its preview-only nature.

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, adequately sized but not front-loaded with the most essential information (preview nature). Slightly verbose for an agent.

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 8 parameters and nested objects, the description covers validation and return type. However, it does not explicitly state that this is a read-only preview and does not modify, which is important for decision-making.

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 adds context about the minimal serialized form {id, template, x, y}, helping with x and y parameters. However, 'id' and 'template' are not in the schema, causing potential confusion. Schema coverage is 50%, so additional semantic value is moderate.

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

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

The description clearly states it places a template instance and returns a change set. It identifies the specific resource (template instance) and action (preview), but does not explicitly differentiate from sibling tools like tiled_preview_edits.

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 alternatives are provided. The context of templates implies usage, but the description lacks guidance on when to choose this tool over others.

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?

The description provides extensive behavioral details beyond the readOnlyHint annotation, including constraints on names (lowercase, 64 chars, tileset existence), registry bounds (4096 names), revision pinning, and the apply process. It fully discloses the tool's safety (no asset touched) and validation logic.

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 dense sentence that packs all necessary information. It is front-loaded with the core purpose and efficiently conveys constraints. However, it could be broken into shorter sentences or bullet points for easier parsing, though 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?

Given the tool's complexity (array of discriminated objects, revision pinning), the description covers all behavioral aspects: what it validates, what it returns, constraints on names, tilesets, registry limits, concurrency handling, and the apply phase. It is thorough and leaves no major questions unanswered.

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 schema description coverage at 0%, the description should compensate for missing parameter docs. While it mentions the operations array (upserts/deletes) and name restrictions, it does not explain the other parameter (expectedRegistryRevision) or the detailed structure of each operation item beyond what is in the schema. Adds some value but not complete compensation.

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 that the tool validates upsert/delete edits to the tile-name registry and returns an expiring change set. It uses specific verbs ('validates', 'returns') and resources ('.tiledmcp/tile-names.json semantic registry'), which distinguishes it from sibling preview tools that operate on different assets.

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 previewing registry edits before applying, and notes that no Tiled asset is touched (safe). However, it does not explicitly state when to use this tool versus alternatives like tiled_list_tile_names or tiled_apply_change_set, nor does it provide scenarios where it should not be used.

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?

Beyond the readOnlyHint annotation, the description reveals that the transaction locks members against individual apply, is expiring, and that applying uses a crash-recoverable redo journal for atomicity. These details add significant behavioral context not captured by 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, information-dense sentence that efficiently conveys all key aspects: composition, constraints, locking, and atomicity guarantee. Every clause earns its place with no redundancy.

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

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

Given the tool's complexity as a multi-file atomic transaction builder, the description covers composition rules, constraints, locking, and atomicity guarantee. It does not detail the return value or expiring behavior, but those are less critical for an agent's selection and 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 single parameter 'changeSetIds' is fully specified in the input schema (array, pattern, min/max items), but the description does not explain what it represents or how to obtain the IDs. With 0% schema coverage, the description fails to add any 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 tool composes multiple previewed change sets into a transaction change set, specifying allowed types (map edit, tileset edit, etc.), quantity bounds (2-16), and the requirement of pairwise-distinct target paths. It distinguishes itself from siblings like tiled_apply_change_set and tiled_preview_edits by focusing on atomic multi-file batching.

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 specifies that member change sets must be 'already previewed, unapplied' and have 'pairwise-distinct target paths,' giving clear prerequisites. It does not explicitly contrast with alternatives or provide when-not-to-use guidance, but the context implies its use for atomic multi-file operations.

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?

Beyond the readOnlyHint annotation, the description details that the tool only returns a change set (no auto-apply), fails closed on empty results or large scale, and distinguishes its scope from object deletion. No contradiction with 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?

Three well-structured sentences with no fluff, each serving a distinct purpose: action, differentiation, and edge-case handling. Slightly dense but 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?

Given the tool's complexity (3 required params, output schema present), the description covers its purpose, limitations, failure modes, and relationship to siblings. An agent has sufficient context to decide when and how to invoke it.

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

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

Schema provides descriptions for 2 of 3 parameters; the description does not add significant parameter-specific meaning beyond implying the revision parameters ensure concurrency. The overall context aids interpretation but does not deeply enrich individual param understanding.

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 precisely states the tool scans tile layers for dangling GID cells and returns a change set to erase them. It distinguishes from siblings like tiled_validate by explicitly noting which issues it fixes and which it does not (tile-object GIDs).

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 indicates when to use (for fixing dangling cells) and when not (for tile-object GIDs, large scale >10k cells suggests broken reference). It references tiled_validate as the alternative for reporting.

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 already indicate readOnlyHint=true and destructiveHint=false. The description adds valuable context: operations are validated, returns an expiring change set, does not modify project assets, and referenced map files are never touched.

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

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

The description consists of two well-structured sentences with no redundant information. It front-loads the purpose and immediately clarifies key constraints.

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 readOnlyHint annotation and presence of an output schema, the description is largely complete. It covers validation, safety, and constraints. Minor gap: could mention that the change set is for subsequent application, but not essential.

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

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

The description adds meaning beyond the schema by stating that additions require existing project-local .tmj maps and that members are addressed by their current array index under the world's revision pin. This clarifies constraints not present in 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 clearly states the verb 'validates' and the resource 'world's explicit map members' with specific operation types (add, move, remove). It distinguishes from siblings by focusing on world-level operations and bounded constraints.

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 description: use to preview world edits. However, no explicit guidance is given on when not to use it or how it compares to similar preview tools like tiled_preview_edits.

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?

The description extensively discloses behavioral traits: returns an expiring fileExport change set, apply re-serializes under pinned revision, fails closed unless bytes match, and lists features that fail (embedded tilesets, group layers, custom properties, etc.). This goes well beyond the annotations (readOnlyHint, destructiveHint) which are 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 thorough but somewhat dense; every sentence adds value, though it could be slightly more streamlined. The structure is logical, starting with the main action then detailing constraints and return type.

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 (4 parameters, output schema, many constraints), the description covers all necessary aspects: what it does, input requirements, output type, failure conditions, and side effects. No gaps are apparent.

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 description adds significant meaning: it explains that targetPath must be a new file in the source map's directory, expectedMapRevision comes from a previous read or preview, and mentions the optional projectFilePath. This enriches the schema definitions.

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

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

The description precisely states it serializes a .tmj map to TMX bytes matching Tiled 1.12.2's writer, with specific constraints (finite orthogonal, external tilesets, CSV layers). It clearly distinguishes from siblings like tiled_preview_write_tsx and tiled_preview_write_tx by focusing on TMX output.

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 previewing TMX writes with specific format constraints, but does not explicitly provide when-to-use vs alternatives or mention conditions to avoid using it. For example, if the map has embedded tilesets, the tool fails closed, but this is not framed as a usage guideline.

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?

Describes failure modes (grid derivation, per-tile metadata, etc.) and the expiring change set lifecycle. Annotations indicate readOnlyHint=true, which is consistent with a preview generating a change set.

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 paragraph with front-loaded action and necessary details; no redundancy, though could be slightly more succinct.

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?

Covers key aspects: operation, constraints, return type, and application behavior. Output schema exists, so return value explanation is not required.

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 descriptions. Description adds context about targetPath needing to be a new file in the source directory, enhancing understanding beyond the schema.

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

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

The description clearly states the tool serializes a .tsj tileset to TSX bytes matching Tiled 1.12.2, distinguishing it from siblings like preview_write_tmx and preview_write_tx.

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 specific usage constraints (target must be new file in source tileset's directory) and notes no Tiled CLI is involved, but does not explicitly guide when to use vs. 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?

The description adds significant detail beyond annotations: it explains the exact serialization process, the constraint that the .tx target must be new, the expiring change set nature, the pinned source revision requirement, and that no Tiled CLI is involved. Annotations indicate readOnlyHint=true, which is consistent as this is a preview generating a change set without immediate write.

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 coherent paragraph with every sentence adding necessary detail. It is front-loaded with the core purpose. While not extremely terse, it avoids fluff and is well-structured for its technical depth.

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 (4 parameters, output schema present), the description covers purpose, constraints, behavior, return type (expiring change set), and application conditions. It adequately complements the annotations and schema without requiring additional explanation.

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

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

Schema coverage is 100%, but the description adds context beyond schema descriptions. For example, it states that targetPath must be a new file in the source template's directory, a constraint not in the schema. It also clarifies expectedTemplateRevision as a SHA-256 revision from a read/preview, reinforcing the schema pattern.

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 precisely states it serializes a restricted-profile .tj object template to TX bytes following Tiled 1.12.2's writeObjectTemplate exactly. It specifies the root element, excluded attributes, and failure modes for tile templates and nested templates, clearly distinguishing it from siblings like tiled_preview_write_tmx and tiled_preview_template.

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

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

The description explicitly states conditions where the tool fails closed (tile templates and nested templates), implying when not to use it. It also constrains the target path to a new file in the source directory. While it provides clear usage context, it does not explicitly name alternative tools for different scenarios.

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?

The description adds significant behavioral details beyond annotations: it explains the visual output format (differing pixels red, matching faded, tile-cell aggregation), the requirement for matching pixel sizes, and the ability to compare with different layer selections. The 'Read-only' tag reinforces the 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 four sentences and front-loads the main purpose. It is relatively concise with no obvious filler, though the first sentence is somewhat long.

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