Crawlora MCP

wta_rankings

Read-only

Get one WTA ranking view and return ranked rows with the native rank, ranking points, tournaments played, movement, player identity (id, first/last/full name and WTA country code) and the published ranking date on player views; race-doubles rows carry both partner players and no date. view is required: singles, doubles, race-singles or race-doubles. The player views accept country (a code from wta_countries; ALL or omission leaves the nationality filter unset) and at (YYYY-MM-DD; omit it for the latest publication); every view accepts its own native type sort key, sort=asc or desc, and zero-based page/page_size paging with page_size from 1 to 50. race-doubles rejects country and at. Player rows keep the source rankedAt, which may be earlier than a requested at; an empty ranking list is valid and no ranking is computed locally.

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": {
      "view": "<view>"
    },
    "name": "wta_rankings"
  }
}

Input Schema

Name	Required	Description
`at`	No	Optional requested ranking date as YYYY-MM-DD, e.g. 2026-11-02. Omit it for the latest publication. Player views only; race-doubles rejects it. The published rankedAt in the response is the actual source date, which may be earlier than the requested one.
`page`	No	Optional zero-based native results page. Defaults to 0.
`sort`	No	Optional sort direction: asc or desc. Defaults to asc for the player views and desc for race-doubles.
`type`	No	Optional native sort key, scoped by view. singles: rankSingles, LastName, BirthDate, TournCountSingles, PointsSingles. doubles: rankDoubles, LastName, BirthDate, TournCountDoubles, PointsDoubles. race-singles: RankChampSingles, LastName, BirthDate, TournCountChamps, PointsChamps. race-doubles: rank, points. Defaults to the view's rank column.
`view`	Yes	Required ranking view, one of: singles, doubles, race-singles, race-doubles. singles is the current player ranking, doubles the current pair ranking, race-singles the player race (champions race) to date, and race-doubles the pair race table.
`country`	No	Optional exact three-letter WTA country code from wta_countries, e.g. KAZ. ALL, or omitting it, leaves the nationality filter unset. Player views only; race-doubles rejects it because the team table has no country selector.
`page_size`	No	Optional rows per page, 1 to 50. Defaults to 50. This is this API's page bound, not a claim about the upstream's own maximum accepted page size.

Output Schema

Name	Required	Description	Default
`data`	Yes	The tool result payload (shape varies per tool; see each tool's docs resource).

Schema Changelog

Changes observed during successful MCP inspections.

AddedNov 9, 2026

TDQS

A4.1/5.0

Behavior4/5

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

Annotations already cover the read-only and open-world profile, and the description adds real behavioral context beyond them: the returned rankedAt may be earlier than the requested at, an empty ranking list is a valid result rather than an error, and no ranking is computed locally. It stops short of covering auth, rate limits, or error behavior, so it is strong but not exhaustive.

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

Conciseness3/5

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

The return-shape statement is well front-loaded, but the remainder is one dense semicolon-chained paragraph that largely duplicates the schema's own parameter descriptions for view, country, at, sort, and page_size. It is informative yet padded with redundant restatement rather than tightening to the facts the schema cannot express.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

With an output schema present, the description needn't describe return structure in detail, and it still covers view semantics, defaults, cross-view parameter exclusions, the rankedAt-vs-at provenance caveat, and the validity of empty results. For a seven-parameter read tool with annotations, nothing an agent needs in order to call it correctly is missing.

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 every parameter is already documented in structured form, including the per-view type sort keys, defaults, and the race-doubles exclusions. The description restates much of this (view list, country semantics, at semantics, paging bounds) with little syntax or edge-case meaning added on top. Baseline 3 is appropriate when the schema carries the load.

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?

The first sentence states a specific verb and resource ('Get one WTA ranking view') and enumerates exactly what comes back: native rank, points, tournaments played, movement, player identity fields, and the published ranking date. It also names the four valid views and their distinct meanings, so an agent can distinguish this from a generic rankings sibling without opening the schema.

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 gives clear selection context for each view (current vs race, player vs pair) and states constraints such as race-doubles rejecting country and at. It also routes the agent to wta_countries as the source of valid country codes. What is missing is any explicit statement of when to prefer a different rankings tool or when this tool is the wrong choice.

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

All Crawlora MCP 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?