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

Annotations already declare destructiveHint=false and readOnlyHint=false, but the description adds real value beyond them: it is 'FREE,' it explicitly does not touch the live map, it returns an 'immutable draft ID/hash,' and it warns that 'Graph reachability is not ... gameplay proof' and that missing assets require user approval. This is meaningful behavioral context, though concurrency/idempotency expectations around expectedRevision could be clearer.

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?

Dense but every sentence carries operational weight (cost, scope, revision handling, return shape, inspection step, domain caveats). It is somewhat jargon-heavy (visualParts/reveal, graph-only topology) and leads with 'FREE' rather than the core purpose, but there is little genuine padding.

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

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

With no output schema, the description usefully discloses return values (immutable draft ID/hash plus a graph-only topology report) and situates the tool in the prepare-inspect-commit workflow. For a complex, nested-document tool it covers the key operational facts, though the name/mapId/projectId semantics remain unaddressed.

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 20% (only the document field is documented), and 5 parameters are present. The description compensates partially by explaining expectedRevision ('pass expectedRevision from context') and hinting at placement-ID stability in the document, but projectId, mapId, and name carry no added meaning from the description.

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

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

States a specific verb+resource: 'Resolve owned artwork and validate a complete editable map without changing the live map.' It also implicitly distinguishes itself from commit_map_draft by saying validation happens 'before commit.' However, it never names its closest siblings prepare_map_edits or preview_map_draft, so the agent must infer the boundary.

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?

Gives clear context for use: 'validate ... without changing the live map,' 'Inspect canonical overview and camera-sized region images before commit,' and 'no browser is required.' It also flags the condition for missing assets ('use existing quoted generation with user approval'), but it does not explicitly contrast with prepare_map_edits/preview_map_draft, so no true exclusion guidance is offered.

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