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

Annotations already flag destructiveHint=true and readOnlyHint=false, but the description adds the critical detail that activation starts spending money and is gated behind a preview-then-confirm handshake. This is exactly the kind of context annotations cannot convey. It does not mention reversibility (whether a pause can be undone), permission requirements, or what happens if id_or_name matches multiple entities.

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?

Two short sentences with zero filler, and the highest-stakes fact (activation spends money and needs confirmation) is placed immediately after the pause case. Every clause carries operational weight.

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 seven-parameter destructive mutation with no output schema, the description covers the riskiest path well but leaves real gaps: entity resolution via id_or_name, the effect of level and folder scoping, and whether the action can be reversed. Adequate to avoid the worst mistake (unconfirmed activation), not adequate to call it confidently in edge cases.

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 only 43%, and the description compensates for the most important gap by fully explaining the confirm parameter's two-step protocol. However, id_or_name — the riskiest parameter, since a fuzzy name match on a destructive mutation could hit the wrong entity — gets no explanation of whether names, IDs, or partial matches are accepted, and level/status meaning beyond their enums is also absent.

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 this toggles between pausing and activating, but never names the resource it operates on (campaign, ad group, ad) or the status-setting verb — that scope lives only in the title. An agent must combine name + title + description to know what is being changed, and there is no differentiation from siblings like tiktok_remove or tiktok_update_bid.

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 draws a clear behavioral fork: pause is a single immediate call, while activation requires a preview, a user check-in, then a second call with confirm=true. That is actionable procedural guidance. It stops short of naming alternatives or stating when this tool should not be used (e.g., use tiktok_remove to delete).

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