Tennis game plans, scouting reports and match breakdowns from shot-by-shot charted matches.
Scored across 4 tools
Each tool has a distinct primary purpose: explain_match (retrospective match breakdown), get_game_plan (matchup-specific plan), get_leaders (leaderboard rankings), get_player (single-player report). get_game_plan and get_player overlap somewhat in that both produce scouting content about a player, but the opponent-specific framing of the plan keeps them separable.
Three tools use a clean get_<noun> pattern (get_game_plan, get_leaders, get_player) with consistent snake_case. explain_match deviates by using a different verb but still follows the same verb_noun lowercase convention, so it is a minor, readable deviation.
Four tools is a little lean for such a deep analytics domain, but each tool is heavily parameterized and covers a lot of surface (match, plan, rankings, player). No redundancy, so the count is defensible though arguably slightly under-provisioned.
The surface covers the core scouting lifecycle: player profiles, leaderboards, match retrospection and opponent-specific planning. Gaps exist around comparison/side-by-side queries, tournament-level aggregation, and discoverability/search, but these are minor given the depth of the four tools.
Why a charted match went the way it did: points won, and each player's gain or loss against expectation split into direction choice, shot selection and execution, by stroke and by set, the loser's biggest leaks and the points each player left on the table by not choosing the best-value direction. Finds the most recent charted match for a player, narrowed by opponent, tournament or year, and lists other matching matches.
| Name | Required | Description | Default |
|---|---|---|---|
| year | No | Season of the match. | |
| player | Yes | A player in the match, e.g. "Jannik Sinner", "Swiatek", "Alcaraz". Misspellings and surnames alone are fine. | |
| opponent | No | The other player (optional), e.g. "Jannik Sinner", "Swiatek", "Alcaraz". Misspellings and surnames alone are fine. | |
| tournament | No | Words from the tournament name, e.g. "Wimbledon", "Roland Garros", "Indian Wells". |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare the safe read-only, idempotent, closed-world profile, so the description's job is to add non-obvious behavior — and it does: it discloses that only 'charted' matches qualify, that the most recent matching match is selected, and that other matching matches are listed. The only gap is what happens when no charted match exists.
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 dense, jargon-heavy run-on listing every analytic dimension before establishing the basic operation, which only appears at the end ('Finds the most recent charted match...'). Front-loading the operational behavior ahead of the analytic breakdown would make it 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 convey what comes back, and it does so thoroughly: points won, gain/loss vs expectation split into direction choice, shot selection and execution, by stroke and by set, plus biggest leaks and points left on the table. Given 4 fully documented parameters and no output schema, this is nearly complete.
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 100%, so the schema already documents player, opponent, tournament and year, including fuzzy-match tolerance. The description adds only that these parameters 'narrow' the search, which is marginal value over the schema's own descriptions; baseline 3 is appropriate.
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+resource (explain why a charted tennis match went the way it did) and enumerates the analytical dimensions returned, so the agent knows exactly what this tool produces. It does not explicitly distinguish itself from siblings like get_game_plan, but the scope is unmistakable.
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?
It implies usage by describing the lookup behavior ('Finds the most recent charted match for a player, narrowed by opponent, tournament or year'), which tells the agent what inputs select a match. However, there is no explicit when-to-use/when-not guidance and no reference to alternatives such as get_game_plan for tactical planning.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
A scouting game plan for one player against an opponent, from 11,822 shot-by-shot charted ATP and WTA matches: the match forecast with a 90% range (same tour only), where to serve first serves on each court against this returner and the optimal mix, which returns work best against this server, the rally shots to favour and to avoid, what the opponent tends to serve, career shot ratings side by side, style compatibility and the charted head-to-heads. Optionally for one surface.
| Name | Required | Description | Default |
|---|---|---|---|
| player | Yes | The player the plan is for, e.g. "Jannik Sinner", "Swiatek", "Alcaraz". Misspellings and surnames alone are fine. | |
| surface | No | Court surface for the forecast and rally plan (default all). | |
| opponent | Yes | The opponent, e.g. "Jannik Sinner", "Swiatek", "Alcaraz". Misspellings and surnames alone are fine. |
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), so the description's burden is lighter. It still adds real context beyond them: the data source and volume, the 'same tour only' restriction on the forecast range, and that the surface parameter scopes only the forecast and rally plan.
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 first clause is well front-loaded, but the remainder is one long comma-spliced list of deliverable nouns that is hard to scan. Given the absence of an output schema the length is defensible, yet the single-sentence enumeration lacks structure.
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 usefully enumerates the plan's contents (forecast, serve/return maps, rally preferences, style compatibility, charted head-to-heads) so an agent knows what comes back. Parameter coverage is handled by the schema, so the definition is essentially complete for a two-required-parameter read tool.
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 100%, so the schema already documents player, opponent, and the surface enum with its default. The description adds only 'Optionally for one surface', which restates what the schema says, so the baseline 3 applies.
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 opens with a precise verb+resource statement ('A scouting game plan for one player against an opponent') and quantifies the underlying corpus (11,822 charted ATP/WTA matches), so the agent knows exactly what it produces. It does not, however, name or distinguish itself from the siblings get_player, explain_match, or get_leaders, leaving that routing to inference.
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?
Usage is only implied: the matchup-framing and the explicit note 'same tour only' for the forecast hint at when the tool is appropriate, and 'Optionally for one surface' signals scoping. There is no statement of when to prefer it over get_player or explain_match, and no exclusions or prerequisites.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Top 10 ATP or WTA players on one tactical measure: direction_choice: Picks the more valuable direction for the stroke being hit (per 100 shots, opponent-adjusted). execution: Gets more out of a shot than the same choice usually yields (per 100 shots, opponent-adjusted). shot_selection: Chooses strokes worth more than the position average; partly reflects the ball they were given (per 100 shots, opponent-adjusted). fewest_points_left: Smallest gap per 100 shots between the direction chosen and the best-value direction for that stroke. most_exploitable_serve: Points per 100 first serves an optimal direction mix would win over the current one, allowing for returners reading a habit. serve_off_equilibrium: First-serve directions that win at clearly different rates (p < 0.01): usage-weighted gap per 100 first serves and the direction to use more. long_rallies_hold_up: Execution from the ninth shot of a rally on, minus the player's own earlier-rally execution, per 100 shots (ATP only). long_rallies_fade: The same long-rally measure, most fading first (ATP only). adaptability: Moves the first-serve mix toward what has been winning in earlier sets, per 100 first serves. A weak habit, not a proven gain. adapts_fastest: The same, every two to three service games, per 100 first serves. Players need at least 5,000 modelled shots.
| Name | Required | Description | Default |
|---|---|---|---|
| tour | No | atp (default) or wta. | |
| board | Yes | Which leaderboard. | |
| scope | No | active: charted in the last three seasons (default); all_eras: every era. |
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), so the description is free to add analytical context — and it does: a minimum sample threshold ('at least 5,000 modelled shots'), tournament coverage limits ('ATP only'), a significance bar (p < 0.01), and an honesty caveat ('A weak habit, not a proven gain'). These are the things an agent cannot get from annotations or schema.
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?
There is almost no wasted content — every clause defines a board — but the entire payload is delivered as one unbroken em-dash-separated block, so an agent must read linearly to find the definition of a single value. Front-loading the purpose is good; the parameter dictionary would be far more scannable as a list.
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 carries the burden of explaining return values, and 'Top 10 ... players on one tactical measure' reasonably implies a ranked ten-row result. It never names the returned fields (rank/player/value) or their units, which is the main remaining gap for a read-only leaderboard endpoint.
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% with all three parameters enumerated and labelled, so the baseline is 3; the description exceeds it by unpacking each of the ten board values with its underlying metric ('per 100 shots, opponent-adjusted', 'usage-weighted gap per 100 first serves', rally-relative execution). Tour and scope are left to the schema, which already documents them adequately.
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 concrete verb-and-resource statement: 'Top 10 ATP or WTA players on one tactical measure,' which tells an agent exactly what comes back. It does not differentiate itself from siblings (explain_match, get_game_plan, get_player), but the purpose itself is unmistakable.
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?
Usage is implied rather than stated: an agent can infer this is for leaderboard ranking, and the per-board notes embeds one genuinely useful constraint (long_rallies_hold_up / long_rallies_fade are 'ATP only'), which prevents an invalid tour+board combination. There is no explicit when-to-use-vs-alternative guidance and no routing to the sibling tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
One charted player's scouting report, found by name: serve and return points won against an average opponent, shot ratings per 100 shots (direction choice, shot selection, execution, long rallies, points left on the table) with tour percentiles, first-serve direction habits per court including on break points, how exploitable the serve is and the optimal mix, the shots they hurt opponents with most and the shots they are most exposed to, best-equipped opponents, stylistically similar players and recent charted matches. When the name matches several players it returns the best match and lists the others.
| Name | Required | Description | Default |
|---|---|---|---|
| name | Yes | The player, e.g. "Jannik Sinner", "Swiatek", "Alcaraz". Misspellings and surnames alone are fine. | |
| tour | No | Restrict the name search to one tour when a surname is shared (e.g. Williams). |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnly/idempotent/non-destructive/openWorld=false, so safety is covered. The description adds genuinely useful behavior beyond that: it discloses the ambiguous-name resolution rule (returns best match, lists the others) and thoroughly describes what the report contains, which matters given there is no output schema.
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 purpose is front-loaded in the first clause, which is good, but the payload is a single sprawling comma-list that is hard to scan and restates return contents at length. Every item may be relevant given no output schema, but the structure is dense rather than economical.
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 carries the burden of describing return values and does so comprehensively, plus it explains the multi-match disambiguation. The main gap is the absence of any sibling routing guidance for a tool with three plausible alternatives.
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 100%, so both parameters are already documented, including the enum on tour and the surname/misspelling tolerance. The description adds nothing beyond 'found by name', so the baseline 3 applies.
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 and resource — 'One charted player's scouting report, found by name' — and enumerates the report's contents in detail. The richness of the field list distinguishes it from get_leaders (leaderboards) and get_game_plan, but it never names a sibling explicitly, so it falls short of the 5 bar.
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?
There is no statement of when to reach for this tool versus get_game_plan, get_leaders, or explain_match, and no prerequisites or exclusions. The only routing-like note ('when the name matches several players...') describes return behavior, not usage context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
explain_matchget_game_planget_leadersget_playerLive tennis scores, players, rankings, odds and win-probability. ATP, WTA, Challenger, ITF, juniors.
Grounded sports predictions plus European soccer and tennis arbitrage data for AI agents.
Lab measurements of nearly 800 tennis strings: search, compare and get recommendations.
Esports cognitive-combine data over MCP: free cohort stats, paid player & team scouting reports.
Add one secure layer between your agents and this server.
