Skip to main content
Glama

livetennisapi-mcp

by io.github.livetennisapi
OverviewDiscussionsAdmin

Archive result detail

get_archive_match
Read-onlyIdempotent

One result from the results archive (1968 to 2022), with per-match serve statistics where the era recorded them. Stats are null for most rows before 1991, never synthesised. Requires the BASIC plan or any History plan.

Input Schema

NameRequiredDescriptionDefault
archive_match_idYesArchive match id, as returned by search_archive_matches.

Output Schema

NameRequiredDescriptionDefault
okYesTrue 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.
statsNoPer-match serve statistics (aces, double_faults, serve_points, first_in, first_won, second_won, serve_games, bp_saved, bp_faced). Null for most pre-1991 rows.
resultNoThe archive result.
messageYesHuman-readable summary of the result, safe to relay to the user verbatim.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed9 schema fields changed
    • 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."
    • changedOutput schema / properties / result / properties / event_date / description
      Previous value: -"The tournament START date — per-match dates do not exist in this era’s records."New value: +"The tournament START date. Per-match dates do not exist in this era's records."
    • changedOutput schema / properties / result / properties / level / description
      Previous value: -"Source tier code: G, M, A, F, D, C, O, or a futures category code."New value: +"Tier code: G, M, A, F, D, C, O, or a futures category code."
    • changedOutput schema / properties / result / properties / outcome / description
      Previous value: -"completed, retired, walkover, default or abandoned — parsed, null when unparseable."New value: +"completed, retired, walkover, default or abandoned. Parsed, null when unparseable."
    • changedOutput schema / properties / result / properties / tour / description
      Previous value: -"atp or wta — the results archive covers those two tours."New value: +"atp or wta. The results archive covers those two tours."
    • changedOutput schema / properties / result / properties / winner / description
      Previous value: -"The winner — a stored field in the corpus, never an inference."New value: +"The winner, a stored field in the corpus, never an inference."
    • changedOutput schema / properties / result / properties / winner / properties / entry / description
      Previous value: -"Draw entry where recorded (WC, Q, LL, …) — null for direct acceptances."New value: +"Draw entry where recorded (WC, Q, LL, ...). Null for direct acceptances."
    • changedOutput schema / properties / result / properties / winner / properties / player_id / description
      Previous value: -"Corpus person id — pass to search_archive_players results to join bios. NOT a roster player id."New value: +"Corpus person id. Join it to search_archive_players results for bios. NOT a roster player id."
  2. Added

TDQS

A3.8/5.0
Behavior4/5

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

Annotations already cover read-only/idempotent safety, so the description spends its space on genuinely new behavior: null statistics before 1991, no synthesised values, and a BASIC/History plan requirement. That is exactly the kind of pre-call caveat annotations cannot express. It stops short of covering error behavior for missing ids or out-of-range years.

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?

Three short sentences, front-loaded with what the resource is and immediately followed by the data-quality caveat and the access requirement. No filler and nothing repeated from structured fields.

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?

With an output schema present, the description needn't explain return shape; it usefully covers the era limitation and plan gating instead. Only the failure mode (invalid or out-of-range id) is left unaddressed.

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

Parameters3/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 documented as coming from search_archive_matches, so the description adds nothing beyond the schema. Baseline 3 applies.

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

Purpose4/5

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

States a specific verb+resource: a single result from the results archive, scoped 1968-2022, with serve statistics. The era range implicitly separates it from get_match / get_recent_results, but it never names the sibling that returns the same entity for the modern era.

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

Usage Guidelines3/5

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

Usage is implied through the id (an archive_match_id, matching search_archive_matches) and the plan prerequisite, but there is no explicit 'use this instead of X when...' or exclusion guidance against get_match or get_archive_career.

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

All livetennisapi-mcp toolsInspect
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.

Resources