OpenApps

Cito API MCP server — tools & history

Cito API MCP server: observed open status, tool schemas, linked apps and version history.

Cito API

Endpoint: https://api.citoapi.com/mcp

Observed status: open. Checked: 2026-10-12T05:09:37+00:00.

Linked apps

  • Cito API

    Live and post-match esports data for agents. League of Legends (LEC, LCK, LPL, Worlds), UFC / MMA fight cards, fighter records, and live stats. Resolve teams and players, live matches, upcoming schedule, standings, match summaries, and head-to-head. Requires a Cito API key from https://citoapi.com/dashboard

Observed tools

  • api_health — API reachability, API key validity, plan tier, rate-limit headers, and best-effort included games. When to use: - Once per session before heavy work - After 401/403/UNSUPPORTED_GAME/RATE_LIMIT - App scaffolding entitlement checks Prefer over: probing random game endpoints to test the key. Do not use when: you only need live scores — use live_matches. Parallel-safe: yes. Upstream cost: 1–6. Example: { "includeGameProbes": true }
  • call_api — Power escape hatch: allowlisted Cito REST call with unshaped raw JSON in data.raw. When to use: - Long-tail paths not yet curated (Fortnite, CS2 leaderboards, niche stats) - Debugging payloads while building an app - User explicitly knows an OpenAPI path Prefer curated tools for all standard jobs (live, schedule, profiles, standings, H2H, previews). Do not use when: a curated tool covers the outcome. Avoid parallel storms; same plan rate limits apply. Path must start with / and match allowlisted prefixes: /health, /lol, /cs2, /dota2, /cod, /ufc, /fortnite, /tennis, /raf, /bkfc. Rejects absolute URLs and path traversal → PATH_NOT_ALLOWED. Parallel-safe: yes but discouraged in bulk. Upstream cost: 1. Example: { "method": "GET", "path": "/cs2/rankings/teams", "queryJson": "{\"page\":1,\"limit\":20}" }
  • combat_athlete — COMPOSITE RAF athlete / BKFC fighter page: profile + recent bouts + career stats. When to use: - "Kyle Snyder's RAF record", "Arlovski BKFC stats", athlete/fighter profile pages athlete accepts a slug ("kyle-snyder") or a name ("Andrei Arlovski"); names are resolved through the league's search, and several matches return AMBIGUOUS_ENTITY with candidates. Profile carries record, division, nickname, country, official headshot (+ its credit — show it with the image). Career stats need the Starter plan; on Free they come back as a partial note while profile and history still return. Prefer over: call_api profile + history + stats separately. Parallel-safe: yes. Upstream cost: 2–4. Example: { "league": "raf", "athlete": "Kyle Snyder", "historyLimit": 5 }
  • combat_bout — One RAF or BKFC bout in full, with its scoring breakdown. RAF: winner, method (decision / tech fall / pin / injury), final score, takedowns, and per-PERIOD scores. BKFC: winner, method, round, time, and per-ROUND punch stats for red and blue (landed/thrown, head/body, distance/clinch, knockdowns). BKFC round stats need the Starter plan; on Free they come back as a partial note. Get boutId from combat_card or combat_athlete (e.g. "raf13--belal-muhammad--colby-covington"). Parallel-safe: yes. Upstream cost: 1–2. Example: { "league": "bkfc", "boutId": "bkfc-fight-night-bethlehem--gregoris-cisneros--ryan-petersen" }
  • combat_card — COMPOSITE fight card for one RAF or BKFC event: event identity + bouts in running order with results. When to use: - "RAF 14 card", "BKFC 95 results", "who won the main event at the last BKFC?" - Event pages and results pages event accepts a slug (e.g. "raf13", "bkfc-95-newark") or "next" / "last". Bouts come main event first; each carries weight class, title stakes, both sides (athletes for RAF, red/blue fighters for BKFC with punch totals), and once finished the winner and result (RAF: score, takedowns, method; BKFC: method, round, time). Prefer over: combat_events + call_api per bout. Do not use when: you need one bout's period/round breakdown (combat_bout). Parallel-safe: yes. Upstream cost: 2–3. Example: { "league": "raf", "event": "last" }
  • combat_events — RAF wrestling or BKFC bare-knuckle events: upcoming cards or recent results. When to use: - "When is the next RAF / BKFC card?", "recent BKFC results", schedule pages - Getting an event slug for combat_card Each event carries slug, name, date, local start time + timezone, venue/location, status and bout counts. Prefer over: call_api /raf/events or /bkfc/events. Do not use when: you already have the event slug and want its bouts (combat_card). Parallel-safe: yes. Upstream cost: 1. Example: { "league": "bkfc", "when": "upcoming", "limit": 5 }
  • combat_h2h — Head-to-head between two RAF athletes or two BKFC fighters: record and every meeting. Accepts slugs or names for both sides (names resolve through the league's search). Parallel-safe: yes. Upstream cost: 1–3. Example: { "league": "bkfc", "athleteA": "ryan-petersen", "athleteB": "gregoris-cisneros" }
  • combat_rankings — Champions and rankings: RAF title holders per division, BKFC official rankings + champions. BKFC: omit division for every division's ranked list (champion, interim champion, ranked fighters), or pass one (e.g. "heavyweight", "womens-flyweight"). RAF has no ranked lists; it returns every title and its holder, or one division's detail when division is given (e.g. "men-heavyweight"). Parallel-safe: yes. Upstream cost: 1. Example: { "league": "bkfc", "division": "heavyweight" }
  • cs2_clutches — 1vX clutch situation success records. Pass playerId for a specific player's clutch breakdown (1v1, 1v2, 1v3, 1v4, 1v5 attempted vs won), or omit to view the global clutch leaderboard.
  • cs2_live_scoreboard — Live real-time in-game scoreboard for an active CS2 match. Returns current round, bomb status, team scores, and individual player stats (K/A/D, ADR, HS%, alive status, HP, armor, weapon, and equipment value).
  • cs2_opening_duels — First blood and opening duel statistics. Pass playerId to view a pro player's First Kills (FK), First Deaths (FD), and opening duel conversion %, or omit playerId to view the global CS2 opening duel leaderboard.
  • cs2_roster_transfers — Recent professional CS2 roster changes, player benchings, stand-ins, and team transfers.
  • cs2_round_economy — Round-by-round tactical economy for a CS2 map. Classifies every round buy type (Full Buy, Force Buy, Semi-Eco, Full Eco), team equipment spend, freeze-time equipment values, and loss bonus counter.
  • cs2_team_map_stats — Team win rates, round win rates, and CT/T side win splits across the competitive map pool (Mirage, Inferno, Nuke, Dust2, Ancient, Anubis, Vertigo) over the last 30 or 90 days.
  • cs2_utility_leaderboard — Sub-second cached leaderboard of CS2 utility and flashbang efficiency. Returns pro player rankings for effective blind duration per flash, enemy blind time, flashes thrown, and grenade ADR.
  • cs2_veto_sequence — Map pick/ban veto sequence for a CS2 match. Shows which team banned which map, map picks, and decider map in chronological order.
  • event_card — COMPOSITE event / fight-night card: identity, bout or match list, optional standings snippet. When to use: - UFC fight night / numbered event page ("UFC 300 card", "Fight Night") - CS2 event hub with match list - Tournament/event overview before match_preview drill-down Bouts come back in card order — main event first, then prelims, then early prelims. Each bout carries weightClass, titleBout, card placement, and (once fought) result { method, round, time, referee, winnerSlug }. Each corner carries images { headshotUrl, bodyImageUrl, imageUrl, proxiedImageUrl }, record, nickname, rank, championStatus, country and flag when upstream supplies them. Use proxiedImageUrl in browsers — the image host sends no CORS header. You do not need call_api per fighter for faces. Prefer over: agent-side resolve + call_api /ufc/events + bout expansion; N+1 match_summary for the card list only; per-fighter call_api just to fetch headshots. Prefer match_preview for one bout/match briefing; match_summary for completed recaps; live_matches for live-only strips; standings alone for pure tables. Do not use when: you only need live scores (live_matches); single finished match recap (match_summary); no event name/id yet and game unknown. Tennis: pass a tournament id/slug to get the draw bracket — rounds carry a round code (Q1..R128, QF, SF, F) with each match's players and score. Set is the primary tennis path here; there is no separate draw tool. Parallel-safe: yes. Upstream cost: 1–4. Example: { "game": "ufc", "eventIdOrSlug": "ufc-300", "includeMatches": true, "includeStandings": false }
  • h2h_matrix — 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.
  • head_to_head — Composed head-to-head record between two teams, two UFC fighters, or two tennis players. No first-class REST H2H exists — this tool filters match history server-side. When to use: - Rivalry / series record questions - Supporting context for previews Prefer over: agent-side double match-list filtering. Do not use when: single-side form only → team_profile or player_profile. Caveat: Dota filters are weaker; expect meta.warnings when data is sparse. Parallel-safe: yes. Upstream cost: 2–4. Example: { "game": "cs2", "sideA": "faze", "sideB": "navi", "limit": 20 }
  • leaderboard_aces — Tennis season aces leaderboard: most aces served in a season, from real match-stats aggregates. When to use: - Who leads the tour in aces this season; season serving-leader tables. Prefer over: raw leaderboard via call_api for agent-normalized rows. Do not use when: ranking position → standings with game tennis; week-over-week movement → rankings_movers; one player's recent form → player_form. Tennis-only. Season defaults to 2026; tour (ATP|WTA) is optional — omit it for the combined board. Rows carry aces + matches played, ordered most aces first. Parallel-safe: yes. Upstream cost: 1.
  • leaderboard_break_conversion — Tennis season break-conversion leaderboard: Share of break opportunities converted per player, from real match-stats aggregates read return-side, ordered highest pct first. When to use: - Share of break opportunities converted per player, from real match-stats aggregates read return-side, ordered highest pct first. season tables; clutch/serve-efficiency leader queries. Prefer over: raw leaderboard via call_api for agent-normalized rows. Do not use when: ranking position → standings with game tennis; week-over-week movement → rankings_movers; one player's recent form → player_form. Tennis-only. Season defaults to 2026; tour (ATP|WTA) is optional — omit it for the combined board. Only players with at least 50 break opportunities qualify. Parallel-safe: yes. Upstream cost: 1.
  • leaderboard_break_points_saved — Tennis season break-points-saved leaderboard: Share of break points saved per player, from real match-stats aggregates, ordered highest pct first. When to use: - Share of break points saved per player, from real match-stats aggregates, ordered highest pct first. season tables; clutch/serve-efficiency leader queries. Prefer over: raw leaderboard via call_api for agent-normalized rows. Do not use when: ranking position → standings with game tennis; week-over-week movement → rankings_movers; one player's recent form → player_form. Tennis-only. Season defaults to 2026; tour (ATP|WTA) is optional — omit it for the combined board. Only players facing at least 50 break points qualify. Parallel-safe: yes. Upstream cost: 1.
  • leaderboard_comeback_wins — Tennis season comeback-wins leaderboard: Share of matches won after losing the first set per player, from real first-set rows joined to completed matches, ordered highest pct first. When to use: - Share of matches won after losing the first set per player, from real first-set rows joined to completed matches, ordered highest pct first. season tables; clutch/serve-efficiency leader queries. Prefer over: raw leaderboard via call_api for agent-normalized rows. Do not use when: ranking position → standings with game tennis; week-over-week movement → rankings_movers; one player's recent form → player_form. Tennis-only. Season defaults to 2026; tour (ATP|WTA) is optional — omit it for the combined board. Only players with first-set data on at least 20 matches qualify. Parallel-safe: yes. Upstream cost: 1.
  • leaderboard_deciding_set_record — Tennis season deciding-set-record leaderboard: Share of deciding sets (full-length final sets) won per player, from real match rows, ordered highest pct first. When to use: - Share of deciding sets (full-length final sets) won per player, from real match rows, ordered highest pct first. season tables; clutch/serve-efficiency leader queries. Prefer over: raw leaderboard via call_api for agent-normalized rows. Do not use when: ranking position → standings with game tennis; week-over-week movement → rankings_movers; one player's recent form → player_form. Tennis-only. Season defaults to 2026; tour (ATP|WTA) is optional — omit it for the combined board. Only players contesting at least 10 deciders qualify. Parallel-safe: yes. Upstream cost: 1.
  • leaderboard_finals_record — Tennis season finals-record leaderboard: Share of finals won (titles clutch) per player, from real completed finals rows, ordered highest pct first. When to use: - Share of finals won (titles clutch) per player, from real completed finals rows, ordered highest pct first. season tables; clutch/serve-efficiency leader queries. Prefer over: raw leaderboard via call_api for agent-normalized rows. Do not use when: ranking position → standings with game tennis; week-over-week movement → rankings_movers; one player's recent form → player_form. Tennis-only. Season defaults to 2026; tour (ATP|WTA) is optional — omit it for the combined board. Only players contesting at least 3 finals qualify. Parallel-safe: yes. Upstream cost: 1.
  • leaderboard_first_serve_won — Tennis season first-serve-won leaderboard: Share of first-serve points won per player, from real match-stats aggregates, ordered highest pct first. When to use: - Share of first-serve points won per player, from real match-stats aggregates, ordered highest pct first. season tables; clutch/serve-efficiency leader queries. Prefer over: raw leaderboard via call_api for agent-normalized rows. Do not use when: ranking position → standings with game tennis; week-over-week movement → rankings_movers; one player's recent form → player_form. Tennis-only. Season defaults to 2026; tour (ATP|WTA) is optional — omit it for the combined board. Only players with at least 300 first serves in qualify. Parallel-safe: yes. Upstream cost: 1.
  • leaderboard_return_games_won — Tennis season return-games-won leaderboard: Share of return games won per player (breaks over opponent service games played), from real match-stats aggregates read return-side, ordered highest pct first. When to use: - Share of return games won per player (breaks over opponent service games played), from real match-stats aggregates read return-side, ordered highest pct first. season tables; clutch/serve-efficiency leader queries. Prefer over: raw leaderboard via call_api for agent-normalized rows. Do not use when: ranking position → standings with game tennis; week-over-week movement → rankings_movers; one player's recent form → player_form. Tennis-only. Season defaults to 2026; tour (ATP|WTA) is optional — omit it for the combined board. Only players with at least 100 return games played qualify. Parallel-safe: yes. Upstream cost: 1.
  • leaderboard_tiebreak_win_pct — Tennis season tiebreak-win-pct leaderboard: Share of classic 7-point tiebreaks won per player, from real match-set aggregates, ordered highest pct first. When to use: - Share of classic 7-point tiebreaks won per player, from real match-set aggregates, ordered highest pct first. season tables; clutch/serve-efficiency leader queries. Prefer over: raw leaderboard via call_api for agent-normalized rows. Do not use when: ranking position → standings with game tennis; week-over-week movement → rankings_movers; one player's recent form → player_form. Tennis-only. Season defaults to 2026; tour (ATP|WTA) is optional — omit it for the combined board. Only players contesting at least 10 tiebreaks qualify. Parallel-safe: yes. Upstream cost: 1.
  • list_capabilities — Curated catalog of cito-mcp tools, games, jobs, and builder recipes. When to use: - Session start or "what can you do?" - Mapping app screens to tools - Filtering by game or job (live_board, match_page, team_page, player_form, standings, h2h, schedule, preview, event_card, app_scaffold) Prefer over: guessing from memory; exploring raw OpenAPI via call_api. Do not use when: you already know the tool and have IDs — call that tool directly. Parallel-safe: yes. Upstream cost: 0. Example: { "game": "cs2", "job": "live_board", "includeExamples": true }
  • list_routes — Index of raw REST routes from the live OpenAPI spec: method, path, summary, tag. When to use: - You need a long-tail path for call_api and do not want to guess - Checking whether an endpoint exists before building around it - Mapping what raw data backs a curated tool Prefer curated tools for standard jobs — this indexes the escape hatch, it is not a replacement for list_capabilities. Do not use when: a curated tool already covers the outcome (call list_capabilities instead). Note: the spec omits /lol entirely, though LoL routes work. Filtering by game=lol returns that caveat rather than an empty list. Parallel-safe: yes. Upstream cost: 1. Example: { "game": "ufc", "q": "rankings" }
  • live_matches — Live matches board across primary games, or a single game filter. Normalized labels, scores, and matchIds. When to use: - "What's live right now?" - Ops/dashboard live strip Prefer over: sequential per-game call_api live probes. Do not use when: user wants upcoming fixtures → upcoming_schedule; historical results → match_summary. CS2 live path is /cs2/live; UFC is included in multi-game fan-out. UFC empty board: section.note + emptyReason + health (workerAlive/lag) + optional supervisor/nextCard (non-live); never fake match items from events[]. Parallel-safe: yes. Upstream cost: 1–5 (allSettled). Example: { "game": "all", "limitPerGame": 10 }
  • match_details — Deep match package: optional timelines, advanced stats, live state/snapshots, full map/game tree, media inventory. When to use: - Analyst deep dive - Live in-game window (LoL/CS2/UFC) - Full demo list Prefer over match_summary only when summary is insufficient. Prefer match_summary for short answers and default cards. Do not use when: first-pass live board (use live_matches + match_summary). Section selection: pass includeTimeline / includeLiveState / includeAdvanced booleans, OR an explicit sections[] list. UFC betting lines: sections:["odds"] (opt-in, never in the default set). If sections[] is non-empty it wins (booleans are ignored). LoL liveState/advanced require gameId. Parallel-safe: yes. Upstream cost: 1–8 (section-gated). Example: { "game": "lol", "matchId": "lol-match-1", "includeTimeline": true, "includeLiveState": false }
  • match_preview — COMPOSITE pre-match briefing: sides, roster/form snippets, H2H stub, event context — for pick'ems, articles, and match-page before state. When to use: - Upcoming match deep link - "Who should I watch before this game?" - App scaffold for preview cards Prefer over: manually chaining team_profile ×2 + head_to_head + schedule. Prefer match_summary when match is completed; match_details for live in-game. Do not use when: user wants final score/recap of a finished match. Parallel-safe: yes. Upstream cost: 4–8. Tennis H2H accepts an optional surface filter (Hard, Clay, Grass). Example: { "game": "lol", "teamA": "t1", "teamB": "gen-g", "includeH2H": true, "recentLimit": 5 }
  • match_summary — COMPOSITE match card: scoreline, key context, player performances, and VOD/demo links when available. When to use: - Match recap / default match UI - After user selects a live or completed matchId Prefer over match_details for chat answers and default UIs. Prefer match_details for timelines, full map trees, live state, advanced packages. Do not use when: no matchId yet (resolve from live/schedule); pure pre-match → match_preview. Parallel-safe: yes. Upstream cost: 2–5. Example: { "game": "cs2", "matchId": "cs2-match-123", "view": "summary", "includePlayerStats": true }
  • player_form — Tennis player form: W/L record over the last N completed matches, current win/loss streak, and per-match rows (opponent, score, surface). Optional surface filter (Hard/Clay/Grass). When to use: - "How is X playing lately?"; current streak; surface-specific record (e.g. clay last 5). Prefer over: player_profile (identity + career aggregates, no streak); raw form via call_api for agent-normalized rows. Do not use when: career totals/titles → player_profile with game tennis (wires /stats); ranking deltas → rankings_movers. Tennis-only. Limit defaults to 10 (max 50, matching the API). Upstream rows arrive newest-first; the streak is the leading run of that order. Parallel-safe: yes. Upstream cost: 1.
  • player_matches — Tennis player match log: every archived match for one player, newest first, with opponent, tournament, round, surface and score. When to use: - "Show me Shelton's last 20 matches"; full match history; every match at a given tournament; filtering a player's record by surface. Prefer over: player_form (a W/L summary with a small window and a streak, not the log); call_api for /tennis/players/{id}/matches. Do not use when: aggregate totals, titles, or win% → player_stats; identity → player_profile; one match's box score → match_details. Tennis-only. Limit defaults to 20 (max 50). Rows arrive newest-first. Use surface to narrow to Hard/Clay/Grass; tournamentId pins one event. Parallel-safe: yes. Upstream cost: 1.
  • player_profile — Player or UFC fighter profile: identity, current team, recent matches, and form/trends/radar when available. When to use: - "How is X playing lately?" - Player page scaffold; form inputs for previews Prefer over: manual multi-call career/trends/matches via call_api. Do not use when: full team roster needed → team_profile; unresolved name → resolve_entity first. Parallel-safe: yes. Upstream cost: 2–5. Example: { "game": "cs2", "playerId": "cs2-player-1", "recentLimit": 10, "includeTrends": true }
  • player_rankings_history — Tennis player ranking trajectory: every published ranking date for one player, plus career-high and weeks at No.1. When to use: - "Show Alcaraz's ranking over time"; career-high rank and when it was reached; how a player climbed; plotting a rank chart. Prefer over: standings (latest snapshot only); rankings_movers (week-over-week delta for a whole tour); player_profile (has career-high but no per-date series). Do not use when: the current top-N table → standings with game tennis. Tennis-only. Rows arrive oldest-first (chronological), which is the order a chart wants; the newest entries are the tail. limit keeps the most RECENT N rows (the route itself ignores ?limit=, so the bound is applied here) — hasMore and oldestReturned/newestReturned say exactly which window came back, and omittedOlder counts the rows left behind at the old end. Parallel-safe: yes. Upstream cost: 1.
  • player_stats — Tennis player career statistics: W/L totals, win percentage, titles, Grand Slam and Masters titles, plus per-surface and per-level breakdowns. Optional surface/year filters. When to use: - "How many titles does Alcaraz have?"; career win%; Grand Slam title count; record on clay; a season-scoped record. Prefer over: player_profile (identity + a summary block, no breakdowns); player_matches (individual rows, no aggregates). Do not use when: the match log → player_matches; ranking over time → player_rankings_history. Tennis-only. Filters are surface (Hard/Clay/Grass/Carpet) and yearFrom/yearTo. Upstream cost: 1.
  • rankings_movers — 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.
  • resolve_entity — Natural-language / fuzzy query → best typed entity ID(s) + game (player, team, event, tournament, match, fighter). When to use: - User named an entity without an ID ("T1", "s1mple", "IEM Cologne", "Islam Makhachev") - Need a canonical id/slug before profile or match tools Prefer over search_entities when you want one best match (or small ranked set) to chain. Prefer search_entities when browsing many results with pagination. Do not use when: you already have a stable id/slug from a prior tool. Empty/ambiguous results still return ok:true with best=null or needsDisambiguation=true — pick from candidates or refine q/game/type. Does not emit AMBIGUOUS_ENTITY as a hard error. Parallel-safe: yes. Upstream cost: 1–5. Example: { "q": "T1", "game": "lol", "type": "team", "limit": 5 }
  • search_entities — Browse/search teams, players, tournaments, events, fighters with type filter and pagination. When to use: - Typeahead / pickers - "List teams matching…" - Exploring entities without committing to one ID - UFC fighter lookup by name/nickname (uses /ufc/search + client re-rank) Prefer over resolve_entity when the user wants a list. Prefer resolve_entity when chaining one name into a profile tool. Do not use when: fetching a known entity profile — use team_profile or player_profile. UFC: with q set, results are ranked (exact name > multi-token match > nickname). "Jon Jones" should return jon-jones first — never the generic P4P list. Parallel-safe: yes. Upstream cost: 1–3. Example: { "game": "ufc", "q": "Jon Jones", "type": "fighter", "limit": 10 }
  • standings — League/event standings or world/division rankings normalized to ranked rows. When to use: - Table / playoff picture - UFC rankings; CS2 world or event standings; CDL standings; LoL league/tournament tables Prefer over: raw standings via call_api for agent-normalized rows. Do not use when: single team form → team_profile; live scores → live_matches. Dota has no first-class standings (may NOT_IMPLEMENTED or weak worldRanking). Required scope keys by game: - lol: leagueId OR tournamentId - cs2: omit for world rankings; eventId for event standings - cod: optional season/stage - ufc: optional division (scope=division) - tennis: optional division (ATP or WTA tour; default ATP) - dota2: best-effort worldRanking only Parallel-safe: yes. Upstream cost: 1–2. Example: { "game": "cod", "season": "2026", "limit": 50 }
  • team_profile — Team/org card: identity, roster, recent matches, and form/trends/radar when available. When to use: - Team page / "who is on this roster?" - Builder team screen sample Prefer over: separate roster + matches + detail via call_api. Do not use when: UFC fighters → player_profile; unknown name → resolve_entity first. Dota may return partial roster (API gap). Prefer slug for lol/cod; teamId for cs2. Parallel-safe: yes. Upstream cost: 2–4. Example: { "game": "lol", "slug": "t1", "recentLimit": 10 }
  • tennis_schedule — One day of tennis: the day's schedule and/or the matches completed that day, across ATP and WTA. When to use: - "What tennis is on today?"; a specific day's fixtures; results completed on a given date; building a daily digest. Prefer over: call_api for /tennis/schedule and /tennis/matches/completed (both require ?date=, which this tool supplies and validates); live_matches (in-progress only, right now); upcoming_schedule (a forward window, not a specific day). Do not use when: matches currently in play → live_matches; a named player's history → player_matches. Tennis-only. 'date' defaults to today (UTC) and MUST be YYYY-MM-DD. Choose with 'include': both (default), scheduled, or completed. Both halves are fetched in parallel, so either can fail on its own without losing the other. 'limit' bounds EACH half (the completed route ignores ?limit= upstream, so the bound is applied here); scheduledCount/completedCount report how many rows the day held and *Returned how many came back. The two halves overlap: the day's list includes matches already played, so the same matchId can appear in both — see the overlap block before de-duplicating or counting. Parallel-safe: yes. Upstream cost: 1 or 2.
  • tournaments — 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.
  • upcoming_schedule — Upcoming matches/events for one game, with game-specific filters. When to use: - "What's on this week?" - Calendar UI; team next matches Prefer over: live_matches for not-yet-started fixtures. Do not use when: only in-progress matches needed → live_matches. Filter support (unsupported params are ignored with meta.warnings — do not assume filtering worked): - lol: hours, team (slug), league (slug) - cs2: team, from, to (ISO); hours not applied upstream - cod: team, tournamentId - dota2: limit/cursor primarily; team may be client-filtered where data allows - ufc: hours / from / to applied client-side after bout expansion (API has no hours); event shells labeled by event name; bouts use fighters[] corners Parallel-safe: yes. Upstream cost: 1–2. Example: { "game": "lol", "hours": 72, "team": "t1", "limit": 20 }

Data as of 2026-10-12T05:09:37+00:00.

OpenApps records store listings and observed changes. Store ranks are not download counts; launch dates may be derived or use the first observation. Coverage gaps are shown in the interactive catalog.

REST API specification · Guide for AI clients · Manage API keys and MCP connections