Skip to main content
Glama

livetennisapi-mcp

by io.github.livetennisapi
OverviewDiscussionsAdmin

Rankings listing

get_rankings
Read-onlyIdempotent

The FULL published ranking table in rank order for one system, from the newest week at or before as_of. Rows carry player_name as published and a null player_id for players outside our roster, so the table has no silent holes. ATP/WTA history runs deep. The ITF circuits begin 2026-07-29. For point-in-time records of SPECIFIC players use get_player_rankings. Requires the PRO plan.

Input Schema

NameRequiredDescriptionDefault
as_ofNoYYYY-MM-DD. Serves the newest published week at or before this date. Omit for latest.
limitNoMaximum ranking rows to return (1-200).
systemYesRanking system to list. utr has no listing, because it is a rating, not a ranking.

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.
messageYesHuman-readable summary of the result, safe to relay to the user verbatim.
rankingsNoThe table in rank order.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed9 schema fields changed
    • changedInput schema / properties / as_of / description
      Previous value: -"YYYY-MM-DD — serves the newest published week at or before this date. Omit for latest."New value: +"YYYY-MM-DD. Serves the newest published week at or before this date. Omit for latest."
    • changedInput schema / properties / system / description
      Previous value: -"Ranking system to list. utr has no listing — it is a rating, not a ranking."New value: +"Ranking system to list. utr has no listing, because it is a rating, not a ranking."
    • 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 / rankings / items / properties / player_id / description
      Previous value: -"Roster player id — null on listing rows for players outside our roster."New value: +"Roster player id. Null on listing rows for players outside our roster."
    • changedOutput schema / properties / rankings / items / properties / player_name / description
      Previous value: -"Name as the ranking publisher printed it (listing rows)."New value: +"Player name as it appears in the ranking (listing rows)."
    • changedOutput schema / properties / rankings / items / properties / previous_rank / description
      Previous value: -"Rank at the preceding snapshot week (ATP/WTA only; null elsewhere)."New value: +"Rank at the preceding snapshot week (ATP/WTA only, null elsewhere)."
    • changedOutput schema / properties / rankings / items / properties / rank_movement / description
      Previous value: -"The circuit's own signed weekly movement (ITF systems only)."New value: +"Signed weekly rank movement (ITF systems only)."
    • changedOutput schema / properties / rankings / items / properties / rating / description
      Previous value: -"UTR only; null elsewhere."New value: +"UTR only, null elsewhere."
  2. Added

TDQS

A4.7/5.0
Behavior5/5

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

Annotations already establish that this is a safe, read-only, idempotent operation. The description adds meaningful context beyond annotations: null player_id behavior for unrostered players, no silent holes, ATP/WTA historical depth, ITF start date, and PRO plan access.

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?

The description is front-loaded with the core purpose and then adds only operationally useful details about roster gaps, historical coverage, alternatives, and access. Every sentence contributes to correct tool selection or invocation.

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?

Given the rich annotations, complete input schema, and existing output schema, the description provides enough context for correct selection and invocation. It covers scope, historical availability, null handling, alternatives, and auth without redundantly explaining return values.

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 description coverage is 100%, so the schema already explains as_of, limit, and system. The description reinforces the as_of week-selection behavior and system scope but does not add parameter-level semantics beyond what the schema provides.

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?

The description states a specific verb and resource: it returns the full published ranking table in rank order for one system. It also distinguishes this listing tool from get_player_rankings, which is for point-in-time records of specific players.

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?

It explicitly names the alternative for player-specific ranking history and gives the condition for choosing it. It also states the PRO plan requirement, so the agent knows the access prerequisite before calling.

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