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

Annotations already declare readOnlyHint, idempotentHint, destructiveHint=false and openWorldHint=false, so "Classification: read-only" is largely redundant. The description does add genuinely new context: synchronous execution, "task support: forbidden," and a response-handling policy (use assistantSummary first, never surface raw JSON). However it omits pagination behavior despite cursor/limit parameters and says nothing about filtering semantics.

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 opening is front-loaded but is pure name restatement, and the classification boilerplate (read-only/synchronous/task support) duplicates annotation data. The presentation directives are individually useful but the JSON-display rule is stated twice in near-identical form, padding the text.

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?

An output schema exists, so return-value explanation is not required, and the description does address response presentation. But for a 21-parameter filtering tool with nested objects and zero schema coverage, the complete absence of any filter or pagination guidance leaves the agent unable to construct a correct call.

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?

21 parameters at 0% schema description coverage, including nested objects (marketContext, marketLanguageProfile) and filters like seatId, campaignId, creativeId, and locale arrays. The description never mentions a single parameter, so it compensates for none of the coverage gap.

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?

"list campaigns" merely restates the tool name and title without adding a verb-object refinement, scope, or any distinction from siblings like list_advertisers, list_creatives, or list_flights. An agent cannot tell from the text why it would pick this over get_campaign or other list tools.

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 gives extensive guidance on how to present results to the user, but nothing on when to invoke the tool, what preconditions exist, or which sibling (get_campaign, list_flights) is the alternative. Usage context must be inferred entirely from the name.

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