set_world_partition_runtime_hash

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

The description asserts 'nothing is mutated' and that applied is always false, directly contradicting the annotations readOnlyHint=false and destructiveHint=true. Although the body adds rich internal context, the stated behavior and the declared safety profile are in direct conflict, which is exactly the contradiction case.

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 core message ('HONEST gate', nothing mutated, applied=false) is front-loaded, but the body is padded with internal references such as 'Mirrors HandleBuildMinimap' and the WITH_EDITOR/GenerateStreaming implementation detail that do not help an agent invoke the tool.

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

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

For a complex, annotation-heavy tool with no output schema, the description does list the return fields inline and explains the WP-detection branches, which is genuinely useful. However, the self-contradiction with the destructive annotations leaves the agent uncertain about the true behavior, so it is not fully complete.

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

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

Schema description coverage is 100% and the schema already labels every parameter 'Informative only (accepted, not applied)'. The description reinforces that CellSize/LoadingRange live in a private property but adds no new per-parameter semantics beyond what the schema states, 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?

The description names a specific verb+resource (editing the World Partition runtime hash grid settings) and clearly explains what the tool actually does: resolve the editor world, detect WP, and report applied=false without mutating. An agent can understand the operation without opening the schema, though it never explicitly distinguishes itself from the 'get_world_partition_runtime_hash' sibling.

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 only implied through the explanation of why the setter cannot succeed (private UPROPERTY, cook-time streaming). There is no explicit 'use this when…' or routing to the get_ sibling as an alternative, so an agent must infer context rather than being told it directly.

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