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

With no annotations, the description carries the full burden, and it does disclose the key trait: this is an asynchronous review workflow, not an immediate mutation, and a third party decides the outcome. It omits permissions needed to propose, what happens to the patch payload (merge vs replace), whether the proposal blocks further edits, and rate or duplicate-proposal limits.

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 short sentences, front-loaded with the core action, with the constraint and the note-length limit attached where they belong. Little waste, though the parenthetical length limit is embedded mid-sentence rather than surfaced with the parameter discussion.

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 four-parameter tool with a nested free-form object, no annotations, no output schema, and zero schema descriptions, the definition explains the workflow but leaves the payload contract and one parameter undocumented. Nothing is said about what a successful proposal returns (an id? a pending status?), which matters since no output schema exists.

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

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

Schema coverage is 0%, so the description must compensate, and it only partially does: it constrains the note to 140 characters and frames `patch` and `id` through the entity-patch concept. The `room` parameter is never mentioned, the accepted shape of the nested free-form `patch` object is unexplained, and the description calls the note "Optional" while the schema lists it as required — a contradiction an agent could act on incorrectly.

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 ("Propose a patch to an entity you do not own") plus the resolution path (author/claim owner accepts or rejects). The "you do not own" qualifier implicitly separates it from an edit-style sibling such as world_edit, but no alternative is named 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 ownership constraint gives a clear condition for when this tool applies rather than a direct-write tool. It stops short of explicitly routing the agent (e.g., "to modify an entity you own, use world_edit") and says nothing about whether multiple proposals may be pending or how to withdraw one.

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