livetennisapi-mcp

Charting: one match, every stat family

get_charting_match

Read-onlyIdempotent

Every charting stat family for ONE charted match, both players, with the per-set split (set 1, set 2, ..., Total) exactly as charted. Charting ids are their own id space (1960 to 2026). Most of these matches have no counterpart in the live tables. Requires the ULTRA plan.

Input Schema

Name	Required	Description	Default
`charting_match_id`	Yes	Charting match id, in its own id space. Not a match_id.

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.
`gender`	No
`mcp_id`	No	The charting dataset's own row identifier.
`message`	Yes	Human-readable summary of the result, safe to relay to the user verbatim.
`players`	No	Both players as charted.
`families`	No	Every stat family, per player, with the per-set split.
`charting_match_id`	No	The charted match.

Schema Changelog

Changes observed during successful MCP inspections.

Changed4 schema fields changedOct 28, 2026

changedInput schema / properties / charting_match_id / description

Previous value: -"Charting match id — its own id space, not a match_id."New value: +"Charting match id, in its own id space. Not a match_id."

changedOutput schema / properties / mcp_id / description

Previous value: -"The Match Charting Project's own row identifier."New value: +"The charting dataset's own row identifier."

changedOutput schema / properties / message / description

Previous value: -"Human-readable summary. Identical to the text content, so either half can be used alone."New value: +"Human-readable summary of the result, safe to relay to the user verbatim."

changedOutput schema / properties / ok / description

Previous value: -"True when the call returned data. False for a tier wall, a missing or rejected key, or an empty result — all of which are normal states with a clear remedy, not failures."New value: +"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."

AddedAug 13, 2026

TDQS

A4.5/5.0

Behavior4/5

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

Annotations already cover read-only, idempotent, non-destructive, open-world behavior, so the bar is lower. The description still adds real value by disclosing the ULTRA plan gate, the id-space range, and the warning that these matches generally don't exist in the live tables, which is behavioral context an agent could not infer from the schema.

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?

Four short sentences, front-loaded with what is returned, then scope, id space, and plan requirement in descending order of importance. No filler or restatement of the tool name.

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

Completeness5/5

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

Details the return shape (per-set split through Total, both players), the id-space caveat, the plan prerequisite, and the non-overlap with live tables. Combined with existing annotations and an output schema, an agent has everything needed to call it correctly.

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

Parameters4/5

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

Schema coverage is 100% and the single parameter is already documented as being in its own id space. The description reinforces this with an explicit 1960-2026 range, which the schema does not state, adding modest extra semantic value.

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 specific verb-and-resource: every charting stat family for ONE charted match, both players, with per-set split. The 'ONE charted match, both players' scoping cleanly separates it from get_charting_player, which an agent can infer covers a single player.

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

Usage Guidelines4/5

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

Gives strong selection context: charting ids live in their own id space (1960-2026), most charted matches have no live-table counterpart, and the ULTRA plan is required. It stops short of explicitly naming an alternative tool for live matches or the per-player variant, but the prerequisites and id-space warning make misuse unlikely.

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.