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

Annotations already declare destructiveHint=true, readOnlyHint=false, and openWorldHint=false, so the safety profile is covered. The description adds meaningful behavioral context beyond that: it requires a verified human account owner and explains the practical effect ('cannot admit more paid work or keep using a stale saved permission').

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?

Two tight sentences with no wasted words; the main action and effect are stated clearly. The action verb is slightly delayed by the auth clause, keeping it just short of a 5 for front-loading.

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 single-parameter, non-open-world mutation with annotations and an output schema, the description covers auth prerequisites and the consequence of revocation. Minor gaps remain around irreversibility and whether the registration record itself is affected, but the essential context is present.

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 0%, so the description must carry the burden, but it only implies that the parameter identifies 'one registration'. The schema itself supplies the pattern and length constraint, and the description adds no further semantics about the registration_id format or lookup.

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 (revoke) and a precise resource (one registration's internal-agent spending permission), which clearly separates it from the grant-setting sibling. It does not explicitly name sibling tools like private_agent_delegation_set, so it falls short of the 5 bar for 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?

The phrase 'As the verified human account owner' adds a useful prerequisite, and the consequence sentence implies when revocation is appropriate. However, it never states when to choose this over private_agent_delegation_set or what happens if the grant is already revoked, so usage is only implied.

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