Padel Analyst

list-pair-matches

Read-onlyIdempotent

List matches played by a pair of players. Returns each match with its tournament, round, both teams with their players and seeds, scheduled time, court, status, score, winner and duration. To get the player IDs, use the "search-players" 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": {
      "player_1_id": "<player_1_id>",
      "player_2_id": "<player_2_id>"
    },
    "name": "list-pair-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.
`level`	No	Filter by tournament level(s), comma-separated. Premier Padel: major, p1, p2, finals. FIP tour: fip_platinum, fip_gold, fip_silver, fip_other. World Padel Tour (historical): wpt_master, wpt_1000, wpt_500, wpt_final. Padel Pro Tour (historical): ppt_master, ppt_final, ppt_international, ppt_promotional, ppt_other.
`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).
`sort_by`	No	Sort matches by this field.	played_at
`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.
`after_date`	No	Filter matches played after this date (YYYY-MM-DD).
`before_date`	No	Filter matches played before this date (YYYY-MM-DD).
`player_1_id`	Yes	The ID of the first player in the pair.
`player_2_id`	Yes	The ID of the second player in the pair.
`tournament_id`	No	Filter matches by tournament ID.

Schema Changelog

Changes observed during successful MCP inspections.

First observedOct 30, 2026

TDQS

A3.7/5.0

Behavior4/5

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

Annotations already declare readOnlyHint, idempotentHint and destructiveHint=false, so safety is covered. The description still adds value by enumerating what each returned match contains (tournament, round, teams with seeds, court, status, score, winner, duration) — important because there is no output schema.

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?

Two sentences, front-loaded with the core purpose, then the return shape, then the prerequisite hint. The long field enumeration is justified by the absence of an output schema, so little is wasted.

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 12 parameters (2 required), full schema coverage, and no output schema, the description covers purpose, return contents, and the player-ID prerequisite. It omits pagination behavior, but the `page` parameter description already explains the meta-based paging flow.

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%, including enums for draw, round, sort_by and order_by, so the schema carries parameter meaning fully. The description adds nothing beyond identifying the two required player IDs, which the schema already labels — baseline 3 is appropriate.

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 and resource: 'List matches played by a pair of players'. The pair constraint is clear enough to distinguish it from list-player-matches, but it doesn't name any sibling explicitly (e.g. search-headtohead for head-to-head history) to sharpen the boundary.

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?

Provides a useful prerequisite pointer ('To get the player IDs, use the search-players tool'), which is real guidance. However, it never says when to choose this over list-player-matches or search-headtohead, so the sibling-selection decision is left to inference.

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?