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

Annotations already declare destructiveHint=true and idempotentHint=true, but the description adds important operational context: it changes the signed-in person's data and requires a browser login rather than an API key. It also clarifies the idempotent behavior: unfollowing something not followed still succeeds.

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 description is short and mostly front-loaded, with the core action, auth requirement, idempotence, and usage hint all present. The opening clause about changing signed-in person's data is slightly generic before the specific action appears.

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?

Given the rich annotations, single required parameter, and existing output schema, the description covers what the agent needs: auth mode, watchlist-removal behavior, idempotence, and the relevant follow-limit workflow.

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 only parameter, bill_id, is already documented as 'The bill's own id.' The description does not add parameter-specific syntax, source, or format details beyond what the schema provides.

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 states a specific verb and resource: 'Removes a bill from this user's watchlist.' This clearly distinguishes it from follow_bill and from list_my_followed_bills, which only inspects follows.

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?

It gives a concrete usage cue: 'Useful right after FOLLOW_LIMIT_REACHED,' and points to list_my_followed_bills for deciding what to drop. It does not explicitly state when not to use the tool, but the context is clear.

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