Cito API

tournaments

Read-only

Tennis tournament catalog: find tournaments by year, tour, level, surface, or country.

When to use:

"Which ATP 500s are on clay in 2026?"; "list the WTA 1000 events"; "what Grand Slams are in 2026?"; finding a tournament id before calling event_card.

Prefer over: event_card when you do NOT already have a tournament id (event_card needs one); call_api for /tennis/tournaments.

Do not use when: the draw bracket or a specific edition → event_card with the id this returns; the season calendar by month → event_card.

Tennis-only. Levels accept names (Grand Slam, WTA 1000, ATP 500, Challenger, ITF World Tennis Tour, Davis Cup, ...) or raw tier codes (G, M, A, C, D). A level name that starts with ATP or WTA also fixes the tour (and conflicts with a contradicting tour= argument are rejected), so "WTA 1000" cannot return ATP Masters events even though the upstream filter is not tour-aware. Note the source does not separate ATP 500 from ATP 250 — both are ATP Tour.

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": "tournaments"
  }
}

Input Schema

Name	Required	Description
`q`	No	Case-insensitive name search, e.g. "open".
`game`	Yes	Game title: lol \| cs2 \| dota2 \| cod \| ufc \| tennis \| valorant. Example: "cs2".
`page`	No	Page number (1-indexed).
`tour`	No	ATP or WTA.
`year`	No	Edition year, e.g. 2026. Omit for all years.
`level`	No	Filter by level. Names: Grand Slam, Masters 1000, ATP Tour, ATP 500, ATP 250, WTA 1000, ... or codes G\|M\|A\|C\|D.
`limit`	No	Max items to return (default 20, max 50). Example: 20.
`status`	No	Valorant event status filter: ongoing \| upcoming \| completed.
`surface`	No	Hard, Clay, Grass, or Carpet.
`countryCode`	No	3-letter IOC country code, e.g. FRA.

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.

Changed3 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"
+]

addedInput schema / properties / status

Added value: +{
+  "description": "Valorant event status filter: ongoing | upcoming | completed.",
+  "examples": [
+    "ongoing"
+  ],
+  "type": "string"
+}

AddedSep 12, 2026

TDQS

A4.4/5.0

Behavior3/5

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

Annotations already declare readOnlyHint, openWorldHint and destructiveHint, so the safety profile is covered by structured data. The description still adds real behavioral context the annotations cannot: parallel-safety, upstream cost of 1, and the notable server-side rule that a level name beginning with ATP/WTA pins the tour and contradicts a conflicting tour= argument. It stops short of describing pagination/return shape, though an output schema exists.

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?

Front-loaded with the resource line, then cleanly sectioned into when-to-use, prefer-over, do-not-use, and caveats. Nearly every sentence carries information, with only minor redundancy between 'Tennis-only' and the game enum and repeated mentions of event_card in two separate sections.

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 10-parameter filtered-list tool with full schema coverage, an output schema, and annotations, the description covers selection, alternatives, exclusion routing, and the two non-obvious semantic traps (level/tour coupling and the collapsed ATP 500/250 tier). 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.

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 earns an extra point by adding semantics absent from the schema — level names imply tour and conflicting tour= is rejected, and the upstream source does not separate ATP 500 from ATP 250. A small gap remains: the tool is framed as 'Tennis-only' while game is a required enum including lol, cs2, dota2, cod, ufc and valorant, and the description never explains how game should be supplied.

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 resource (tennis tournament catalog) and the exact facets it can be queried by (year, tour, level, surface, country). It also names the sibling it must not be confused with (event_card) and the reason — event_card needs an id this tool produces — so the boundary is unambiguous.

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?

Gives explicit when-to-use examples in natural query form ('Which ATP 500s are on clay in 2026?'), an explicit 'prefer over' rule versus event_card and call_api with the selecting condition (no tournament id yet), and an explicit 'do not use when' routing bracket and season-calendar questions back to event_card.

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?