Padel Analyst

search-headtohead

Read-onlyIdempotent

Search head-to-head matches between two teams, or all matches of one team (one or two player IDs per team). Returns each match with its tournament, round, both teams with their players and seeds, scheduled time, court, status, score, winner and duration, most recent first. 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": {
      "team_1": "<team_1>"
    },
    "name": "search-headtohead"
  }
}

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.
`team_1`	Yes	IDs of players in the first team. At least one player is required.
`team_2`	No	IDs of players in the second team. If not provided, only matches for team_1 will be returned.
`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).

Schema Changelog

Changes observed during successful MCP inspections.

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 declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so safety is covered. The description adds useful behavioral context beyond annotations: results are returned most recent first, and each match includes tournament, round, teams, players, seeds, scheduled time, court, status, score, winner, and duration. It does not discuss pagination or rate limits, but the schema covers pagination.

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 sentences, front-loaded with the core purpose and followed by return-shape and helper-tool guidance. The return-field list earns its place because there is no output schema, and there is no redundant restatement.

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?

For a read-only search tool with full input-schema coverage and no output schema, the description supplies the return shape, sort order, and where to get player IDs. It is sufficiently complete to call correctly, though it lacks explicit routing guidance versus sibling match-search 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%, so the schema already documents all eight parameters, including draw, level, date filters, and pagination. The description adds semantic context about player IDs and one-or-two-player teams, but leaves most parameter meaning to the schema; 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: search head-to-head matches between two teams, plus the one-team variant. It clarifies that each team uses one or two player IDs, but does not explicitly distinguish this tool from sibling match-listing tools such as list-player-matches or search-matches.

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?

Gives one clear routing instruction: use the "search-players" tool to get player IDs. It also explains that omitting team_2 returns only team_1's matches. However, it does not state when to use this tool instead of list-player-matches, list-pair-matches, or search-matches, so guidance is only 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?