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

The description discloses substantial real behavior: Rithmo sends the text verbatim through its own app, reads the approver's reply itself, honors only the approver's own reply, allows exactly once, and a `replaces` target becomes unusable. But those are outbound messages and durable, invalidatable approval state, which conflicts with the supplied readOnlyHint=true. Disclosure is above average; the annotation mismatch is the problem.

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?

Nearly every sentence carries load, and purpose is front-loaded, but it is one dense unbroken paragraph mixing prose with embedded hash-format and object-literal syntax. Splitting the lifecycle (request → reply → reliance) from the parameter notes would make it far easier to parse at invocation time.

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 an 8-parameter, zero-coverage tool with no output schema, key operational facts are missing: what the call returns (presumably an approval_id), whether it blocks or returns immediately while the reply is read asynchronously, and how to subsequently poll status. The binding rules between approval and check_premises are covered well, but the request/response lifecycle is not.

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 carries the load and does so for most parameters: `text` (sent exactly, hashed for reliance), `approval_word`, `where` (channel vs DM), `replaces` (earlier approval_id, invalidated), `action_fields` (shown under text and binding the later check_premises). `title`, `agent_key` and the required `intended_action` are never explained, so the coverage is rich 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?

States a specific verb, resource and actor: 'Ask the person you act for, from the authority map, to approve one action.' That distinguishes it cleanly from siblings like approve_from_chat (the approver's side), get_approval (retrieval) and note_to_approver (messaging without approval semantics).

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 concrete conditional guidance: use `where` for the team channel, direct message when absent; use `replaces` to supersede an earlier version; rely on the result in check_premises with the exact hash shape. It stops short of naming the sibling tools that handle the other half of the loop (get_approval, approve_from_chat, get_hold_status).

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