目录 / cito-api
MCP
需 API Key
未评级
已上架
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 odds-adjacent 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
该来源不提供完整文件导出(国内平台多为平台内托管),仅存元数据与原链
模型生成摘要(rules/v1 · 2026-09-27 16:42):Live and post-match esports data for agents
这是模型对公开材料的总结,不是官方声明,请以原链内容为准。
这是模型对公开材料的总结,不是官方声明,请以原链内容为准。
接入信息
- 传输形态
- http
- 鉴权方式
- 需 API Key(需要配置:apiKey)
- 端点
https://cito-api--support-a2on.run.tools
该服务需要凭证,请按官方文档申请后替换占位符
{
"mcpServers": {
"cito-api": {
"headers": {
"Authorization": "Bearer \u003cYOUR_KEY\u003e"
},
"url": "https://cito-api--support-a2on.run.tools"
}
}
}
能力清单
| 工具 | 说明 |
|---|---|
| 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 } |
| 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 } |
| 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 } |
| 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 } |
| 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 } |
| 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 } |
| 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. 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 } |
| 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 } |
| 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 } |
| head_to_head | Composed head-to-head record between two teams (or two UFC fighters). 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 } |
| 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) - dota2: best-effort worldRanking only Parallel-safe: yes. Upstream cost: 1–2. Example: { "game": "cod", "season": "2026", "limit": 50 } |
| 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. Example: { "game": "lol", "teamA": "t1", "teamB": "gen-g", "includeH2H": true, "recentLimit": 5 } |
| 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 — ufc.com 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. Parallel-safe: yes. Upstream cost: 1–4. Example: { "game": "ufc", "eventIdOrSlug": "ufc-300", "includeBouts": true, "includeStandings": false } |
| 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" } |
| 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. 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}" } |
纠错与举报(发现条目失效、署名有误或涉及侵权?)
提交举报 / 纠错
侵权举报经核验成立后,我们会即时下线该条目并删除已存的内容副本。