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

Annotations already flag destructiveHint=true, so the safety profile is covered; the description adds genuinely useful behavior: DNS records are left intact, the call maps to a shared backend action whose returned actual_tool_output should be trusted, and retry/idempotency handling is spelled out. The canonicality and idempotency sentences are somewhat generic policy boilerplate, which keeps this from a 5.

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 purpose and DNS caveat are correctly front-loaded, which is good. However, the trailing canonicality/idempotency/confirmation block is generic policy text that reads as boilerplate rather than tool-specific detail, diluting an otherwise tight description.

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 destructive, no-output-schema mutation, the description covers prerequisites, confirmation, idempotency, and what side effects do NOT occur, which is close to everything an agent needs. The undefined context parameter is the main remaining gap.

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?

The only parameter is the _corply_context envelope, and schema description coverage is 0%, so nothing in either place explains its id/receipt fields. It is likely plumbing the agent doesn't need to reason about, but the description doesn't compensate for the gap, landing at the baseline.

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 and resource ('Stop sending company mail from the connected domain') and immediately scopes it with 'DNS records remain untouched', which separates it from domain-clearing siblings like clear_company_domain. It stops short of naming connect_email_domain/disconnect alternatives explicitly, but an agent can still tell what this does and what it does not do.

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?

Gives a clear trigger condition ('Call only on the founder's explicit request') plus a prerequisite ('authenticated active company access') and a confirmation boundary ('obtain fresh, explicit user confirmation'). It does not name the sibling tools it should be preferred over, so it's strong context rather than full routing guidance.

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