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

Annotations only cover read-only/open-world hints, so the description carries the real burden and does it well: it enumerates which fields exist per sport, discloses accuracy caveats ('minute null = not known', 'no headers or xG per shot: not in our data'), states temporal availability of editorial content, and warns the consumer not to extrapolate. That is exactly the beyond-schema behavioral context an agent needs.

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?

It is a single run-on sentence of roughly 150 words with semicolon-chained clauses; the vocabulary enumeration for the soccer timeline is long enough to slow scanning. Content earns its place, but formatting does not — bulleted or sentence-split structure would make the sport-specific branches far easier to parse.

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?

With no output schema, the description must describe returns and largely does — field lists, event kinds, referee_stats denominators, summary components. Residual gaps are error behavior for a bad match_id and whether the shape varies by sport beyond the soccer/editorial notes, but nothing critical to a correct call is missing.

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 coverage is already 100%, so the baseline is 3; the description earns an extra point by adding a real caveat not present in the schema — that the editorial summary is English only regardless of the lang parameter. It also corroborates that match_id comes from get_matches and sport from list_sports.

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?

Opens with a specific resource-and-payload statement: 'One match: teams, score, status, events..., venue, referee', and layers on sport-specific extras (soccer timeline, referee_stats, editorial summary). It is clearly distinct from the plural get_matches, but it never names or rules out the closely-related siblings get_match_details and get_match_briefing, leaving overlap unresolved.

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?

No statement of when to pick this tool over get_match_details, get_match_briefing, or get_match_briefing's kin that sit right next to it. The only directive is about downstream handling ('Quote them as facts; never add predictions'), which is output etiquette, not tool selection. Availability windows ('only until kick-off and once finished', 'English only (no lang)') hint at constraints but do not guide selection.

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