Padel Analyst

list-rankings

Read-onlyIdempotent

Get the ranking list for a given week. Without date returns the latest snapshot; with date returns the snapshot in effect at that day. Each entry includes the ranking type, position, points and diffs against the previous snapshot. Types official and race are FIP points tables; type elo ranks players by Elo rating (carried in points) and only includes players with at least 5 rated matches in the last 12 months (a walkover or a bye never produces a rating). Filter by ranking type, category (men/women) and nationality (2-letter country code). Sort by ranking_diff or points_diff to surface the biggest movers.

Tool call template

This tool declares no required parameters. Add optional parameters from the input schema as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {},
    "name": "list-rankings"
  }
}

Input Schema

Name	Required	Description
`date`	No	Date (YYYY-MM-DD) for which the ranking is requested. Defaults to the latest available snapshot.
`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.
`type`	No	Ranking type. Defaults to `official` when omitted.
`sort_by`	No	Field to sort the rankings by. Use `ranking_diff` or `points_diff` to surface the biggest movers of the week. Defaults to `ranking`.
`category`	No	Filter by player category. Omit to return both.
`order_by`	No	Sort order. Defaults to `asc`.
`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 number one), or 50 to minimize pages when you need the complete list.
`nationality`	No	2-letter country code to filter the players by nationality (e.g. `ES`, `AR`).

Schema Changelog

Changes observed during successful MCP inspections.

First observedOct 30, 2026

TDQS

A4/5.0

Behavior4/5

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

The annotations already declare read-only, idempotent, non-destructive, and closed-world behavior. The description adds useful context beyond that: snapshot semantics, entry fields, Elo eligibility rules, and special cases such as walkovers and byes not producing ratings. It does not discuss auth or rate limits, but those are less central here.

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?

The description is one dense paragraph with useful information front-loaded: what the tool returns, date behavior, entry fields, type semantics, filters, and sorting. It is longer than minimal but each sentence carries relevant content. It could be split or trimmed slightly for readability, but it is not wasteful.

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 8 optional parameters, 100% schema coverage, and rich annotations, the description covers the important call behavior: date handling, type semantics, filtering, sorting, and return entry fields. Pagination is left mostly to the schema, and sibling differentiation is not addressed, but the tool is otherwise well specified for correct invocation.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100%, so a baseline of 3 is appropriate. The description adds meaning beyond the schema by explaining what official, race, and elo mean, how dates select snapshots, and why ranking_diff or points_diff are useful. It does not fully restate every parameter default, but it adds enough semantic value.

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?

The description gives a specific verb and resource: 'Get the ranking list for a given week.' It also explains the snapshot behavior and the ranking types. It does not explicitly distinguish this tool from the sibling list-player-rankings, so it falls short of a 5.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

It clearly explains when date is omitted versus supplied, and how type elo differs from official and race. It also advises sorting by ranking_diff or points_diff to find movers. It does not name alternatives or state when not to use this tool versus list-player-rankings.

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?