Padel Analyst

list-tournament-matches

Read-onlyIdempotent

List the matches of a tournament by providing the tournament ID. Returns each match with its round, both teams with their players and seeds, scheduled time, court, status, score, winner and duration. To get the tournament ID, use the "search-tournaments" tool.

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "tournament_id": "<tournament_id>"
    },
    "name": "list-tournament-matches"
  }
}

Input Schema

Name	Required	Description	Default
`draw`	No	Draw the matches belong to: `main`, `qualy`, `group` or `placement` (team tournaments only), or `all` for every draw in a single list. Defaults to `main`: the other draws are only returned when explicitly requested.	main
`page`	No	Page number for pagination. Results are paginated: check `meta` (`current_page`, `last_page`, `total`) in the response and request further pages with this parameter until you have all the results you need.
`court`	No	Filter matches by court name (partial match).
`round`	No	Filter matches by round (1 = Final, 2 = Semifinal, 4 = Quarterfinal, 8 = Round of 16, 16 = Round of 32, 32 = Round of 64, 0 = group stage of team tournaments). Avoid using this parameter if you are also filtering by played_at.
`sort_by`	No	Sort matches by this field. Use `court_order` to follow the order of play within each court.	played_at
`category`	No	Category of the match. Either `men` or `women`.
`order_by`	No	Order of the sorting, either `asc` or `desc`.	desc
`per_page`	No	Number of results per page (1-50). Use a small value when you only need the top results (e.g. 1 for the most recent match), or 50 to minimize pages when you need the complete list.
`played_at`	No	Filter matches played on this date (YYYY-MM-DD)
`tournament_id`	Yes	The ID of the tournament to list matches for

Schema Changelog

Changes observed during successful MCP inspections.

Changed1 schema field changedNov 10, 2026

changedInput schema / properties / sort_by / enum

Previous value: -[
-  "played_at",
-  "court",
-  "court_order",
-  "round"
-]New value: +[
+  "played_at",
+  "court",
+  "court_order",
+  "round",
+  "watchability"
+]

First observedOct 30, 2026

TDQS

A3.8/5.0

Behavior4/5

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

Annotations already establish this as a safe, idempotent, non-destructive read, so the description's main contribution is the return shape: round, both teams with players and seeds, scheduled time, court, status, score, winner and duration. That is meaningful context an agent cannot get from annotations or the schema, though it says nothing about result volume beyond the schema's pagination field.

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?

Two sentences, both front-loaded and load-bearing: the first states the action and the required input, the second covers the return contents and the dependency needed to call it. No 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 rich annotations, a fully described 10-parameter schema, and no output schema, the description covers purpose, return contents, and the prerequisite lookup, which is enough to call it correctly. The only real gap is sibling discrimination against other match-listing tools.

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% with five enums and defaults fully documented, so the schema does the heavy lifting and the baseline is 3. The description adds only the acquisition path for tournament_id and no meaning for draw, round, court, or sorting beyond what the schema states.

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?

A specific verb and resource ('List the matches of a tournament') plus the scoping key (tournament ID) makes the purpose unambiguous. It does not, however, contrast itself with nearby siblings such as search-matches or list-pair-matches, which also surface match data.

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?

The description gives one concrete routing instruction: use search-tournaments to obtain the tournament_id, which is genuinely helpful for the required parameter. It offers no guidance on when to prefer this over search-matches, list-player-matches, or list-pair-matches, so usage is only partly implied.

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

All Padel Analyst 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.

Resources

Need Help?