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

Annotations already cover read-only, idempotent, non-destructive, closed-world, yet the description adds genuinely new behaviour: synchronous execution, task support forbidden, and a fairly detailed response protocol (assistantSummary first, never dump raw JSON, mention IDs only for follow-up). That is real value beyond annotations. It loses a point for the ambiguous 'Task support: forbidden' phrasing with no explanation of what that constrains.

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 sentence is a verbatim copy of the title, and the second half is a lengthy presentation policy that reads as system-prompt material rather than tool documentation. It is front-loaded, but several sentences could be cut or moved without loss.

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 no explanation, and the presentation protocol is a nice addition. The decisive gap is that a four-parameter tool with zero schema coverage leaves the agent guessing at every argument, which no amount of prose about formatting compensates for.

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?

Four parameters with 0% schema description coverage, and the description accounts for none of them. Only the title's phrase 'for one authorised advertiser' loosely hints at advertiserId; limit, seatId, and seatName — including how seatId vs seatName are meant to interact — are completely unexplained in both schema and 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?

States a specific verb (List), resource (World Intelligence signals), and scope (active, source-provenanced, one authorised advertiser), and explicitly excludes the general-purpose news-search reading. It does not, however, distinguish itself from near-neighbours like list_world_opportunities, get_world_intelligence, or leanriq_list_world_signals, so an agent still has to infer which of the family to pick.

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?

Gives one useful exclusion (not a general-purpose news search) but never says when to call this versus get_world_intelligence, list_world_opportunities, or the leanriq_ variants. The large fraction of the text dedicated to user-facing presentation rules is guidance about output, not about tool selection.

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