Skip to main content
Glama

The Tennis Desk

by io.github.chungty
OverviewDiscussionsAdmin

What a club's page shows

query_club
Read-onlyIdempotent

Returns what a club's page on The Tennis Desk shows, in one call. That is its teams in a season by league, each with its place in the Desk's unofficial league table and its record. It also gives the club's next matches, latest results and record against each other club. Call it when someone asks how a club is doing, its record against other clubs, or where its teams stand. For only its list of teams, or which plays next, query_club_teams is enough. Pass club: the club's name as people say it or as USTA prints it, or its page address or number. Pass season, a year, for that season's page, and briefing true for the club's week. A team's firstPlace says whether it can still finish first, which assumes each scheduled match is played. In a result, * marks a line won or lost by default.

Input Schema

NameRequiredDescriptionDefault
clubYesThe club: its name as people say it or as USTA prints it, e.g. 'Scott Valley', or its club page address or number, e.g. '/c/218'.
askedNoThe person's question word for word, never paraphrased. Leave it out rather than invent one.
seasonNoA season year, 2022 or later: the club's page in that season, its teams, places and records then. Leave it out for the newest season the club fielded a team. A season the club has no team in is not found, and the answer names the seasons it has.
briefingNoTrue for the club's week instead of its page: every team match in the next 7 days, counting the day of the call in Pacific time, each with the other team's place in the Desk's unofficial league table and their earlier meetings this season, and the checks the Desk writes from the records, each with the pages it rests on. Its `firstPlace` says whether each club team that plays in those days can still finish first, and when none plays, each team with a team match left. The answer's `briefing` is null when no team match falls in those days. Leave it out, or call again without it, for the club's page.

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observed

TDQS

A4.3/5.0
Behavior4/5

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

Annotations already cover readOnly/idempotent/non-destructive, so the description correctly spends its space on caveats the annotations can't carry: that firstPlace assumes every scheduled match is played, that a season with no team is 'not found' and the answer lists available seasons, the 7-day Pacific-time briefing window, and the '*' default-scoring marker in results. It never states what happens when the club itself can't be resolved, so it stops short of 5.

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

Conciseness4/5

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

Purpose is front-loaded in the first sentence and the sibling routing follows immediately. Some duplication of the schema's briefing text and a couple of long, clause-heavy sentences cost it a point, but nothing is filler.

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 no output schema, the description carries the return-shape burden and does so: teams, places, records, upcoming matches, results, head-to-head, plus the briefing variant. The only gap is the unmentioned `asked` parameter, which is minor given its optional, verbatim-question nature.

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 schema already documents club forms, season default and briefing behavior; the description mostly restates those. It does not mention the `asked` parameter at all, so it adds little beyond the structured fields.

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: it returns what a club's page shows — teams by league with table place and record, next matches, latest results, head-to-head records. It explicitly separates itself from query_club_teams ('for only its list of teams... query_club_teams is enough'), so an agent can route without opening either schema.

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 concrete trigger questions ('how a club is doing, its record against other clubs, or where its teams stand') and names the narrower sibling for the subset case. Both when-to-use and when-to-use-something-else are stated.

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

All The Tennis Desk 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