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

Annotations already declare readOnlyHint=true, idempotentHint=true, openWorldHint=true, and destructiveHint=false, covering the safety profile. The description adds useful behavioral context: 'One bounded request, no background polling or automatic retry', 'Access, delay and metered usage follow your connected account', and 'Affiliate 27 is excluded'. It also warns against inferring coverage from an empty result. This goes beyond annotations, but some claims like 'Product data or price calculation' are vague. Score 4 because it adds real value but could be clearer.

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 description is a single sentence with multiple clauses, which is somewhat dense but front-loaded with the core purpose. It includes several disjointed facts (product data/price calc, canonical IDs, access/delay/metered usage, bounded request, affiliate exclusion, no wagers/account changes/guarantee). While not bloated, it lacks clear structure and reads like a list of caveats rather than a coherent guide.

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?

Given the tool has an output schema, the description needn't explain return values. Annotations cover safety, and the description adds behavioral constraints and exclusion notes. However, it omits important context for a read operation: what 'lines' are, the format of the response, and how to interpret the data. It leaves gaps for an agent trying to understand the tool's full scope, especially with 2 parameters and nested objects.

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 0%, so the description must compensate. It does not describe the 'path' or 'query' parameters beyond implying the use of event IDs. The schema itself defines 'eventId' with pattern and length constraints, and 'include' and 'affiliate_ids' are described in the schema (though coverage metric says 0%, the schema does include descriptions). The description adds no parameter-specific meaning, so baseline 3 is appropriate when schema provides some documentation, but not enough to compensate for the 0% coverage metric.

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 clearly states a specific verb and resource: 'Get a single event with lines'. This is distinct from sibling list tools like list_events and v2GetEventByID. However, it doesn't explicitly differentiate itself from v2GetEventByID, a very similar sibling; the 'v1' vs 'v2' distinction is not explained.

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 provides some context such as 'Product data or price calculation' and 'Use returned canonical IDs', but it does not explicitly state when to use this tool versus alternatives like v2GetEventByID or v1GetEventsBySportAndDate. The usage guidance is implied rather than explicit.

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