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

Adds substantial context beyond the annotations: a concrete cost of 2 credits, an explicit data-availability caveat ("No serve statistics: they are not available"), the coverage scope for moneylines, and the meaning of captured_at. It also states a policy constraint about never computing stakes, payouts, or recommending bets, which an agent cannot infer from readOnly/idempotent hints 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?

Front-loaded correctly, but the middle is one sprawling sentence that itemizes return fields which an existing output schema already defines, so a chunk of the text does not earn its place. The genuinely load-bearing parts (cost, missing serve stats, market-information policy) are buried inside that enumeration.

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?

For a read-only, effectively single-lookup tool this covers everything an agent needs: cost, the ID source, the WTA routing rule, what is deliberately absent (serve stats), when price data will be missing, and a guardrail on how the retrieved prices may be used. The output schema handles return-shape details, so nothing important 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 100%, so the schema already documents both parameters, and the description's match_id guidance merely echoes schema hints. The league/tour guidance does add routing value ("on the shared endpoint pass league: 'wta' for the WTA"), but it introduces a naming mismatch by calling it "Tour: atp (default) or wta" while the schema enum is tennis|wta with a default of tennis — so it clarifies and muddies in equal measure.

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 verb-plus-resource framing ("Use for everything about one match") and immediately enumerates the exact payload: score by set with tiebreak points, seeds, per-player sets/games/tiebreaks, ratings before and after, and moneylines. An agent can distinguish this from get_matches/get_player_matches purely from the word "one match" versus those list-oriented siblings.

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?

"Use for everything about one match" gives a clear positive selection rule, and the note that moneylines exist "mostly Grand Slam, ATP Masters and WTA 1000 matches" tells the agent when the price data will be absent. There is no explicit exclusion naming a sibling (e.g. "use get_head_to_head instead for X"), which keeps it short of a 5.

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