Cito API

rankings_movers

Read-only

Tennis ranking movers: biggest climbers/fallers between the latest ATP/WTA list and its predecessor, plus new entries and drop-outs.

When to use:

Who climbed or fell this week; new top-100 entrants; who dropped out.

Prefer over: standings (latest snapshot only, no week-over-week delta); raw movers via call_api for agent-normalized rows.

Do not use when: current top-N snapshot → standings with game tennis; player history → player_profile.

Tennis-only. Direction up (climbers, default), down (fallers), or both (largest absolute change). Date pins an older ranking list (YYYY-MM-DD); default is the latest, which the API resolves past zero-diff cloned lists.

The two lists are NOT always one week apart: previousDate is whatever the archive holds next, and the archive has holes. Read gapDays / comparisonWindow (and comparisonsAreWeekly) before describing a delta as weekly — a warning is raised whenever the gap exceeds ten days.

Parallel-safe: yes. Upstream cost: 1.

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": {
      "game": "<game>"
    },
    "name": "rankings_movers"
  }
}

Input Schema

Name	Required	Description
`date`	No	Ranking date to compare against its predecessor (YYYY-MM-DD). Default: latest.
`game`	Yes	Game title: lol \| cs2 \| dota2 \| cod \| ufc \| tennis \| valorant. Example: "cs2".
`tour`	No	ATP or WTA tour; default ATP. Synonym: division.
`limit`	No	Max items to return (default 20, max 500). Example: 20.
`within`	No	Only players inside the top N on either list.
`division`	No	Synonym for tour (ATP or WTA), matching the standings tool spelling.
`direction`	No	up (climbers), down (fallers), or both (largest absolute change).

Output Schema

Name	Required	Description
`ok`	Yes	true if the tool succeeded
`data`	No	Result payload when ok is true; null on error
`meta`	Yes
`error`	No
`partial`	No
`pagination`	No

Schema Changelog

Changes observed during successful MCP inspections.

Changed2 schema fields changedNov 14, 2026

changedInput schema / properties / game / description

Previous value: -"Game title: lol | cs2 | dota2 | cod | ufc | tennis. Example: \"cs2\"."New value: +"Game title: lol | cs2 | dota2 | cod | ufc | tennis | valorant. Example: \"cs2\"."

changedInput schema / properties / game / enum

Previous value: -[
-  "lol",
-  "cs2",
-  "dota2",
-  "cod",
-  "ufc",
-  "tennis"
-]New value: +[
+  "lol",
+  "cs2",
+  "dota2",
+  "cod",
+  "ufc",
+  "tennis",
+  "valorant"
+]

AddedSep 10, 2026

TDQS

A4.5/5.0

Behavior3/5

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

The annotations already declare readOnlyHint=true, destructiveHint=false and openWorldHint=true, so the safety profile is covered upstream. The description nevertheless adds real operational context the annotations cannot: tennis-only scope, date resolution past zero-diff cloned lists, the fact that the archive has holes and the two lists may not be a week apart, plus parallel-safe and upstream-cost notes. It does not describe pagination or output shape, which is acceptable because an output schema exists. Net effect of that mixed detail is average.

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?

Front-loaded one-line purpose followed by labelled blocks for when-to-use, preferred alternatives, exclusions, scope and operational notes. Every line carries decision-relevant information, including the explicit warning to read gapDays/comparisonWindow before calling a delta weekly.

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?

For a seven-parameter read tool with full schema coverage, an output schema and open-world upstream data, the description covers scope, alternatives, semantics, and the archive-gap caveat that could otherwise cause misreporting. Nothing needed 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.

Parameters4/5

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

Schema coverage is 100%, so the baseline is 3. The description still earns extra: it expands the direction values (up = climbers, default; down = fallers; both = largest absolute change) and clarifies that date pins an older list and defaults to the latest list, which the API resolves past zero-diff clones. Minor overlap with the schema wording keeps it below 5.

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?

States a specific verb and resource: biggest climbers/fallers between the latest ATP/WTA list and its predecessor, plus new entries and drop-outs. That scope is precise enough to separate it from the standings snapshot and player-history siblings without opening either schema.

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

Usage Guidelines5/5

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

Explicitly lists when to use (weekly climbers/fallers, new top-100 entrants, drop-outs), names the alternatives it beats (standings has no week-over-week delta; raw call_api requires normalization), and adds a 'do not use when' block routing snapshot requests to standings and history requests to player_profile.

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

All Cito API 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?