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

Annotations already declare readOnlyHint/non-destructive/closed-world, and the description adds real context beyond that: scope limited to this key's requests, newest-first ordering, and an itemized list of returned fields (request_id, operation, target, params, reason, timestamp, signal state). With no output schema, that return-shape disclosure is the valuable contribution here.

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 scope and default behavior are front-loaded, but the passage then rambles into unrelated tooling (waiting_on_maplith, recently_done, unblocked signal) using long run-on sentences. Those sentences do not describe this tool's behavior and actively cost the reader clarity rather than earning their place.

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 does the necessary work of enumerating returned fields and ordering, which is genuinely complete for the read itself. But it omits pagination behavior given a limit-only schema, and the trailing material about Maplith waitlists describes data this tool does not return, so it neither completes nor cleanly bounds the picture.

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 100%, so the baseline is 3. The description does elaborate what the status values mean ('pending (a person has not decided yet), allowed, denied or withdrawn'), adding semantic depth beyond the enum, but says nothing about limit or its 1-50 range, leaving the schema to do that work.

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?

Opens with a specific verb and resource: 'Read your own request_action requests, newest first, and where each stands,' which distinguishes it from request_action (which creates) and from mutation siblings. However, the closing sentences pivot into describing 'waiting_on_maplith' and 'recently_done', which are not what this tool returns, muddying what the tool actually is.

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?

'By default only the pending ones; status all lists every one' gives clear default-vs-override guidance. It also points at request_action with op withdraw as the way to take one back, which is a useful sibling reference. But there is no explicit statement of when to call this versus list_signals or waiting_on_maplith, and the blend of those other tools' semantics into the text leaves the agent unsure whether they are covered here.

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