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

The description goes well beyond the annotations by disclosing the credit cost, the ~4 week duration, the automatic completion threshold (reputation score 80), the failure mode, and the exact success return shape. The annotations already indicate mutation and non-idempotency, so the description adds valuable behavioral context without contradicting them.

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 dense but every sentence carries distinct value: purpose, prerequisite, cost, duration, auto-completion, optional parameter behavior, failure condition, return contract, and related tool. The most important action is front-loaded, and there is no filler or redundancy.

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 tool has 3 parameters, no output schema, and no rich annotations, the description covers all essential operating context: prerequisites, cost, side effects, failure modes, return shape, and recommended pre-check. An agent can decide to call this tool and interpret its result without additional information.

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%, so the baseline is 3. The description adds useful context around warmupEmail (alias vs primary), but this largely mirrors the schema's own parameter description. It does not introduce new parameter-level semantics beyond what the input schema already 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 action ('Enable email warmup'), the target resource (a connected Google account via MailReach), and clearly differentiates from related sibling tools like campaignstack_disable_warmup and campaignstack_get_warmup_status. The scope is immediately understandable without needing to inspect the schema.

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 explicitly names a prerequisite tool (campaignstack_set_google_app_password) and a pre-check tool (campaignstack_list_workspace_warmups), giving the agent a clear sequence. It also discloses the failure condition when the email is already being warmed, but does not explicitly provide a 'when not to use' or alternative for already-enabled accounts.

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