Cito API

h2h_matrix

Read-only

Multi-player tennis head-to-head grid: every pair's series record in one comparison matrix.

When to use:

Draw/field analysis: how each contender fares against every other (e.g. Alcaraz vs Zverev vs Sinner round-robin records)
Group-stage or semifinal-field comparisons

Prefer over: N head_to_head calls for an N-player field; raw matrix via call_api.

Do not use when: a two-player rivalry deep-dive with tiebreak/decider splits → head_to_head; season stat leaders → leaderboard_*; rankings → standings.

Tennis-only. players takes 2-16 ids or names (names resolve via player search). Each matrix cell is "W-L" from the row player's perspective, "-" on the diagonal.

Parallel-safe: yes. Upstream cost: 1 + one search per unresolved name.

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>",
      "players": "<players>"
    },
    "name": "h2h_matrix"
  }
}

Input Schema

Name	Required	Description	Default
`game`	Yes	Game title: lol \| cs2 \| dota2 \| cod \| ufc \| tennis \| valorant. Example: "cs2".
`players`	Yes	2-16 tennis player ids (atp_207989) or names ("Carlos Alcaraz"); duplicates collapse.

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?

Annotations already establish readOnly, non-destructive and open-world behavior, so the safety profile is carried structurally. The description adds genuinely useful operational detail beyond that: parallel-safety, an upstream cost model (1 + one search per unresolved name), and the W-L cell / '-' diagonal output convention. The tennis-only constraint is a helpful domain limit, though it is stated tersely.

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 with a one-line purpose, then labeled sections (When to use, Prefer over, Do not use when) that let an agent scan rather than parse prose. Every line carries actionable information; no filler sentences.

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?

A single-purpose comparison tool with two required parameters, full schema coverage, an output schema, and explicit annotations needs little more. The description covers call cost, parallelism, input resolution, and the matrix cell layout, leaving no material gap 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 the baseline is 3, and the description adds real meaning: names resolve via player search, the 2-16 bound is echoed with a round-robin rationale, and the row-relative cell semantics are explained. Only the game enum's tennis restriction is genuinely new guidance beyond the schema.

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 — a multi-player head-to-head comparison matrix — and immediately scopes it to tennis, so the agent knows exactly what it produces. It actively distinguishes itself from head_to_head and call_api by name, so no schema inspection is needed to tell them apart.

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?

Uses an explicit when-to-use list (round-robin field analysis, group-stage comparisons), a prefer-over rule (instead of N head_to_head calls; raw matrix via call_api), and a do-not-use list routing to head_to_head, leaderboard_* and standings. Both the positive and negative cases are spelled out with named alternatives.

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?