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

Annotations already flag destructive=true and openWorld=true; the description adds what the agent actually needs — that inbound messages still reach the business's WhatsApp and the team answers manually, and that the owner gets a daily reminder while paused. That is real consequence context beyond the annotations, though it never says what human confirmation or permissions the pause requires.

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?

Three tight sentences, with the core effect front-loaded and the clarifying consequences after. Every sentence carries new information, though the 'business's WhatsApp' phrasing is slightly redundant with 'the team answers by hand'.

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 one-optional-param mutation with no output schema, the description covers the effect, what stops and what continues, and the recurring reminder. The main gap is recovery: it doesn't name switch_on_assistant or say how quickly pausing takes effect on in-flight messages.

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 100% and the single optional 'brand' parameter is already documented with its source (get_overview brands[].slug) and its default. The description adds nothing about multi-brand scoping, so baseline 3 applies.

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?

It states a specific verb and resource (pause the assistant) and immediately defines the operational effect: it stops replying to everyone and sends nothing scheduled. The scope ('at once', 'nothing scheduled') distinguishes it from narrower siblings like cancel_scheduled.

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?

Usage is only implied through the effect description ('until switched on again'), which hints the counterpart is switch_on_assistant but never names it. No explicit statement of when an agent should pause versus take a less drastic action such as flag_for_team or set_signoff.

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