convert_map_to_world_partition

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

The description states the tool only performs read-side work (resolves the editor world, detects World Partition, returns converted=false) and explicitly says the in-place mutation 'cannot be driven safely or synchronously from this request.' That directly conflicts with the declared annotations destructiveHint=true / readOnlyHint=false, which assert the tool may modify its environment. Per the rubric this contradiction caps the score at 1.

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 purpose is front-loaded in the first sentence and the follow-on detail (commandlet path, in-place mutation, what gets returned) each earns its place, though the second sentence is a dense run-on bundling several distinct facts.

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 helpfully enumerates the return fields ({world, is_world_partition, converted, already_converted, success, note, message}), which is exactly what an agent needs. It is nearly complete, though it could state the tool's relation to sibling World Partition 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 100% and the single optional map_path already carries its semantics in the schema ('optional informational path... the world converted is always the current editor world'). The main description adds nothing about parameters, so the baseline 3 applies.

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

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

States a specific verb and resource ('Reports whether the current editor world can be converted to World Partition') and immediately corrects the misleading name by clarifying that it is a report/gate, not an actual conversion. However, it never names or routes against sibling tools (e.g. create_world_partition_map, get_world_partition_info), so it stops short of explicit sibling differentiation.

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

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

Explains the conditions under which conversion is actually possible (commandlet-only via UWorldPartitionConvertCommandlet) and why the runtime path cannot be driven from this request, giving the agent clear context for what this tool is and is not for. It never names a concrete alternative tool to call instead, so it lacks explicit when/when-not/alternatives framing.

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