livetennisapi-mcp

Player record and splits

player_stats

Read-onlyIdempotent

One player's record over completed singles matches from 2023 onward, by default the last 365 days. It gives W/L overall, over the last 12 months and by surface, venue, level and season. It also gives tiebreaks, deciding sets, the record after winning or losing the first set, comebacks, withdrawals and the last N matches. Every count carries its sample size, and a percentage on an empty sample is null, never 0. On ULTRA it adds serve_return: measured serve and return statistics summed over the window. Singles only, so a doubles-team id is refused. For 1968 to 2022 use get_archive_career. Requires the PRO plan (serve_return requires ULTRA).

Input Schema

Name	Required	Description
`to`	No	Window end: YYYY-MM-DD (the whole of that day) or a UTC ISO-8601 instant. Default now.
`from`	No	Window start: YYYY-MM-DD (start of that day) or a UTC ISO-8601 instant. Default to minus 365 days.
`last`	No	How many recent matches to list, newest first (1-50, default 20).
`level`	No	The match tour. A match with no stated tour matches no level.
`surface`	No	hard, clay or grass read the match surface; indoor keeps matches stated indoor, on any surface.
`player_id`	Yes	Player id, as returned by search_players.

Output Schema

Name	Required	Description
`ok`	Yes	True when the request succeeded, including when the answer is an empty list. False for a missing or rejected key, a plan that does not include this data, an unknown id, a rate limit or a network error. The message then says what to do. check_api_status is the exception: it is true whenever the API answered, and reports API key problems in the message.
`sets`	No	Set-based record: sample, tiebreaks, deciding_sets, after_winning_first_set, after_losing_first_set, comebacks, sets.
`player`	No	The player.
`recent`	No	The last N matches, newest first.
`window`	No	The window applied, UTC.
`message`	Yes	Human-readable summary of the result, safe to relay to the user verbatim.
`overall`	No	W/L over the window.
`by_level`	No	W/L keyed by match tour, or unknown.
`by_venue`	No	W/L keyed indoor, outdoor, unknown.
`by_season`	No	W/L keyed by UTC calendar year.
`by_surface`	No	W/L keyed hard, clay, grass, unknown.
`withdrawals`	No	Retired / walkover / default, each as given (this player) and received (the opponent).
`serve_return`	No	ULTRA only, null below: summed serve and return statistics, each ratio as numerator/denominator/pct with its match count.
`last_12_months`	No	W/L over the 12 months ending at the window end.

Schema Changelog

Changes observed during successful MCP inspections.

AddedOct 28, 2026

TDQS

A4.9/5.0

Behavior5/5

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

Annotations only cover safety (readOnly/idempotent), so the description carries the disclosure burden and does it: plan gating, tier-dependent extra field, the null-not-zero convention for empty samples, sample sizes on every count, and the singles-only refusal. That is real behavioral context beyond structured fields.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Front-loads scope and default window, then enumerates the aggregate blocks, then the caveats and gating, then the sibling route-out. Every sentence carries information; nothing is repeated from the schema verbatim.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Despite an output schema, it usefully previews the return shape (W/L splits, tiebreaks, deciding sets, serve_return) and the null semantics, and covers plan gating. Minor gap: filtering interactions between the top-level surface/level params and the by-surface/by-level breakdowns are not spelled out.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters5/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100%, so baseline is 3; the description earns above that by explaining what the window means in terms of the aggregates (overall, last 12 months, by surface/venue/level/season) and that `last` controls the recent-match listing. It adds semantic framing the per-param text does not.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

States a concrete verb and resource: one player's record over completed singles matches, with an explicit default window (last 365 days) and a floor (2023 onward). It is clearly distinguishable from get_player, get_recent_results and get_archive_career, the latter named explicitly.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines5/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Gives explicit routing: use get_archive_career for 1968-2022, and PRO is required while serve_return requires ULTRA. It also states a hard exclusion (doubles-team ids are refused), so an agent knows when this tool is the wrong one.

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

All livetennisapi-mcp tools Inspect

Try in Browser

One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.