add_catch_all_address

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

No annotations are provided, so the description carries the full disclosure burden, but it only states the intent to add. It fails to disclose behavioral implications of a catch-all: whether it changes routing for all unaddressed mail, whether it can replace an existing catch-all, whether the address must already exist as a mailbox, or whether domain verification is required.

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 a single efficient sentence with the action verb front-loaded and zero wasted content. It earns a 4 rather than 5 because the brevity sacrifices information that a slightly longer phrasing could have absorbed without bloat.

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?

Despite an output schema existing (so return values need not be explained), the description is incomplete for a mutating email-routing tool with three undocumented parameters and no annotations. Missing context includes behavioral side effects, prerequisites, idempotency, and what distinguishes a valid catch-all setup.

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 compensate, but it only implicitly maps 'domain' to domain_name and 'catch-all address' to catch_all_address. The zoid parameter is entirely unexplained, and there is no hint about what format catch_all_address should take (e.g., existing mailbox vs. arbitrary address).

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 names a specific verb ('Add'), resource ('catch-all address'), and scope ('for domain'), which clearly conveys what the tool does and distinguishes it from siblings like delete_catch_all_address. It falls short of a 5 only because it states the bare action with no elaboration on what a catch-all address accomplishes.

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 provides zero guidance on when to use this tool, when not to, or how it relates to the closely-related sibling tools (delete_catch_all_address, add_domain_alias, verify_domain). An agent is given no context about prerequisites such as domain verification or when a catch-all is the right mail-routing strategy.

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