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

Annotations already cover read-only, idempotent, and non-destructive hints, so the description does not need to repeat them. It adds value by explaining the meaning of suppression and the scope field, which is likely part of the output. However, the scope field is not defined in the schema, creating ambiguity about whether it is an input or output property. No contradiction with annotations exists.

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 three sentences with no redundant phrasing. It front-loads the definition of suppression, then adds the scope clarification, and ends with the removal caveat. Each sentence earns its place, and the structure is clean and efficient.

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?

The description explains the concept of suppression and the manual removal process, which is useful context. However, it does not explicitly state that providing an email filters to that specific address, nor does it mention pagination behavior with limit and cursor. The scope field ambiguity also detracts from completeness. For a simple listing tool, these omissions leave room for confusion.

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 only 33% (email has a description; limit and cursor do not). The description does not mention any of the parameters, nor does it explain how email filters results or how limit/cursor control pagination. It even introduces a `scope` field that is not a parameter, potentially misleading the agent about the input schema. This is a significant gap given the low schema coverage.

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 conveys that the tool deals with suppression entries and clarifies they are unsubscribed, bounced, or complained addresses. It does not explicitly state the verb 'list' or 'retrieve', relying on the title, but it distinguishes this from removal by noting no tool removes addresses. The mention of a `scope` field that is absent from the input schema is a clarity issue, though the overall purpose is understandable.

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 description explains that removal is done manually, which tells the agent not to expect a removal action here, but it does not explicitly state when to use this tool versus alternatives like add_suppression or list_subscribers. There is no direct comparison to sibling tools or conditions for selection, leaving usage context implied rather than explicit.

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