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

Annotations already cover the safety profile (readOnly, idempotent, non-destructive, closed-world), but the description adds real value beyond them: synchronous execution, task support forbidden, and explicit output-handling rules (use assistantSummary first, never display raw JSON, mention IDs only when useful). These are behavioral constraints an agent could not derive from the structured fields alone.

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 deprecation notice and the output-handling guidance earn their place, but the first sentence duplicates the title word-for-word (including a doubled period), and the classification/execution/task-support lines are boilerplate. Front-loading the deprecation notice would have been stronger than burying it after the repeated title.

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 values need not be described, and annotations cover safety, which lowers the bar. Still, for a tool with 20 undocumented parameters and a dense sibling set, the description does not convey what the summary actually contains or how the entity/question inputs shape it, leaving an agent able to invoke it but not to invoke it well.

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?

There are 20 parameters with 0% schema description coverage and no enums, so the description carries the full burden of explaining them — and it explains none of them. Fields like entity, question, targetMarket, marketContext, and the locale variants are completely opaque from both the schema and the description.

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 verb and resource (read an advertiser-scoped World Intelligence V3 summary with evidence) and explicitly identifies itself as the deprecated alias of get_world_research_summary, which is genuine differentiation from the dense cluster of sibling get_world_research_* tools. The opening sentence is largely a verbatim restatement of the title, so it earns clarity mainly through the deprecation note rather than original content.

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?

Labeling itself a 'Deprecated alias for get_world_research_summary' implicitly steers the agent toward the canonical tool, and 'no publication authority' hints at scope limits. However, there is no explicit when-to-use / when-not-to-use statement relative to the many nearby siblings (get_world_intelligence, get_world_research_insights, get_world_research_decision), leaving the routing decision to inference.

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