This MCP server provides read-only access to live scores, fixtures, standings, bracket, and prediction-market signals for the 2026 men's football tournament, plus shareable text cards and team-name resolution.
Get today's fixtures with live score/minute overlays (get_today)
Get only matches currently in play (get_live)
Get detailed info for a single match by id (get_match)
Get a specific team's next fixture (get_next_fixture)
Get group standings (by group letter or all) (get_standings)
Get the knockout bracket from R32 to final (get_bracket)
Get read-only prediction-market signals for a match or team (get_market_signal)
Generate shareable plain-text cards for matches, standings, brackets, etc. (get_share_snippet)
Resolve fuzzy team names/codes to FIFA codes, flags, and groups (get_team)
Supports localization (en/es/pt/fr), timezone formatting, and commentary flavor (off/subtle/full)
Live scores for the 2026 men's football tournament — in your terminal, your Claude Code / Cursor CLI statusline, and any MCP client. No API key, no signup; all 104 fixtures ship bundled, so the schedule works offline.
npx @claudinho/cli today # try it in 10 seconds — no install, no key
npx @claudinho/cli live # what's on right now (during match windows)⭐ Like it? Star the repo — a fan project's only scoreboard is its stars. (
claudinho starshows you how anytime.)
While matches are live, your Claude Code or Cursor CLI statusline reads:
⚽ 🇳🇴 1–1 🇫🇷 87' · 🇸🇳 1–2 🇮🇶 86'And claudinho share prints a card made for the group chat:
Group A · standings
1. 🇲🇽 MEX 9 pts · 3-0-0 · +6
2. 🇿🇦 RSA 4 pts · 1-1-1 · -1
3. 🇰🇷 KOR 3 pts · 1-0-2 · -1
4. 🇨🇿 CZE 1 pts · 0-1-2 · -4
Live data: ESPN
#VibingLaVidaLoca · Independent fan project · not affiliated with FIFA or Anthropic.
Try it: npx @claudinho/cli table A⚠️ Not affiliated with, endorsed by, or connected to FIFA or Anthropic. Claudinho is an independent, open-source fan project. It displays factual match data (scores, fixtures, standings) and uses emoji flags only — no logos, emblems, kits, broadcast footage, or player likenesses.
npm i -g @claudinho/cli
claudinho today
claudinho next MEX --tz America/Mexico_City --lang esOne command wires the live-score statusline and prints the MCP config to paste:
npm i -g @claudinho/cli
claudinho init cursor # statusline → ~/.cursor/cli-config.json (+ the MCP paste)Restart your agent session to see it. Prefer to paste it yourself? claudinho init cursor --print
emits the snippets, or copy them straight from here:
Statusline — ~/.cursor/cli-config.json:
{
"statusLine": {
"type": "command",
"command": "claudinho prompt",
"padding": 0,
"updateIntervalMs": 1000,
"timeoutMs": 1500
}
}MCP tools — ~/.cursor/mcp.json (global) or a project .cursor/mcp.json:
{ "mcpServers": { "claudinho": { "command": "npx", "args": ["-y", "@claudinho/mcp"] } } }Optional env — a model + context line below the score, or scope to your team:
export CLAUDINHO_CURSOR_META=auto # model + context % line under the score (recommended)
export CLAUDINHO_TEAM=MEX # show only your team's match
export CLAUDINHO_FLAGS=off # 3-letter codes instead of flag emoji (already automatic in Warp)
export CLAUDINHO_DEBUG=1 # print data-provider failure diagnostics to stderr
export CLAUDINHO_NO_STAR=1 # suppress the occasional "star the repo" nudgeNote: Cursor's
beforeSubmitPrompthook doesn't yet reliably inject context into the model, so the score-aware hook stays Claude Code-only for now — the statusline and MCP server work great in Cursor.
npm i -g @claudinho/cli
claudinho init claude # statusline + live-score hook, then the MCP one-linerinit claude backs up ~/.claude/settings.json first and is idempotent. Prefer the pieces
à la carte? Run init-statusline, init-hook, and:
claude mcp add claudinho -- npx -y @claudinho/mcpRestart Claude Code to activate.
Monorepo / local dev? The
init cursor/init claudealiases wire the globalclaudinho. To point a statusline or hook at a local build, use the granular commands with--command, e.g.claudinho init-cursor-statusline --command "node ./packages/cli/dist/index.js prompt"(andinit-statusline/init-hookfor Claude Code).
codex mcp add claudinho -- npx -y @claudinho/mcp # Codex CLIEverything else takes the standard stdio config:
{ "mcpServers": { "claudinho": { "command": "npx", "args": ["-y", "@claudinho/mcp"] } } }Then just ask, mid-task — the agent calls the MCP server and answers with the score:
Related MCP server: mcp-sports
CLI — today, live, next MEX, table, match <id>, bracket, markets, share, team (name → code, e.g. team "DR Congo") (plus vibe 😎 and star ⭐). --json on everything; TZ-aware via --tz.
Live statusline — Claude Code & Cursor CLI — every live score inline; reads a local micro-cache, never blocks on the network. One command per agent: claudinho init claude / claudinho init cursor (also tmux & Starship via claudinho prompt).
Score-aware hook (Claude Code) — a UserPromptSubmit hook that drops the live score into the model's context during matches; zero tokens off-match. (Cursor parity pending — its hook can't reliably inject context yet.)
MCP server — 9 read-only tools (get_today, get_live, get_match, get_next_fixture, get_standings, get_bracket, get_market_signal, get_share_snippet, get_team) plus my_team / tournament_today prompts.
Prediction-market signals — a read-only "who's favored" line (market-implied percentages, Source: Polymarket), shown only when a reliable market exists. Informational only — not betting advice. Opt out: --no-markets / CLAUDINHO_MARKETS=off.
Shareable cards — claudinho share next MEX --copy puts a plain-text match card on your clipboard; claudinho share table A does the same for a group's live standings; claudinho share bracket for the knockout tree.
Speaks en / es / pt / fr, with optional localized commentary flair (¡GOOOOL!) — dial it down with --flavor subtle|off.
Planned (not shipped yet): a desktop notifier and an AI pundit with a public accuracy scorecard.
Independent coverage and organic attribution include LinuxLinks and SuperIsland's Live Football extension.
Claudinho is also listed in the Official MCP Registry, Smithery, Glama, MCP.so, cursor.directory, awesome-claude-code, and awesome-mcp-servers. The Cursor integration was also discussed in the Cursor Community.
See PUBLIC_FOOTPRINT.md for the full dated record, including community posts, historical listings, automated mirrors, and events.
Do I need an API key or account? No. Nothing to sign up for; npx and done.
Does it work offline? The bundled data does — the full schedule, group fixtures, and the knockout bracket structure (all 104 fixtures ship bundled, no key). Anything live hits the network: scores, group standings, and a team's resolved knockout opponent (next once the draw fills in).
Where does the data come from? Live scores from ESPN's public scoreboard (attributed in output as Live data: ESPN); market signals from Polymarket public data. Rate limits respected.
Is the market line betting advice? No. It's read-only, informational-only market data with attribution — no trading, no links — and it never appears on the statusline or hook.
Why no crests, kits, or player photos? Legal-clean by design: facts and emoji flags only.
Flags show as boxed letters (CH, BA)? Some terminals — notably Warp — don't compose
the regional-indicator pairs into flag glyphs, so 🇨🇭 renders as a boxed CH. claudinho
auto-detects Warp and drops the flags: 3-letter codes on the statusline (MEX 1–0 RSA 67')
and plain team names in the hook, today / live / table, and next. Force it anywhere with CLAUDINHO_FLAGS=off, or keep flags
with CLAUDINHO_FLAGS=on.
Windows? Works, but flag emoji rendering varies by terminal — best on macOS/Linux. See the
flags note above; CLAUDINHO_FLAGS=off gives clean codes on any terminal that can't render them.
Claudinho is a solo, $0, organic fan project — a GitHub star is the only signal that it's worth maintaining, and the nudge to keep shipping through the final. A star also:
surfaces it for other devs hunting live scores during the tournament,
puts new releases in your feed — a desktop notifier, an AI pundit, and other tournaments are on the roadmap,
takes one click → ⭐ star Claudinho.
New here? CONTRIBUTING.md has the layout, the dev loop, and good first issues.
Claudinho collects no personal data — no accounts, no telemetry, no analytics, no tracking. There is no Claudinho server. To show live results it makes read-only requests to public sports-data services (ESPN for scores/standings; Polymarket for informational-only market signals) with no account or personal data attached, and keeps a small cache in your local cache directory (~/.cache/claudinho). Full details: PRIVACY.md.
Found a vulnerability? Please report it privately via GitHub's report form rather than a public issue. SECURITY.md has the disclosure process and the threat model (stdio only, no listener, no credentials, two read-only outbound hosts).
MIT © 2026 Arturo Garrido. All three packages publish with npm provenance via OIDC trusted publishing.
Built while watching the games. #VibingLaVidaLoca ⚽
Knockout bracket from the Round of 32 through the final, with live scores overlaid. Group slots project from live standings once a group has started; winner slots need a confirmed FT result. Pass an optional stage (R32, R16, QF, SF, 3P, F) to filter one round. Falls back to structure-only when live data is unavailable.
| Name | Required | Description | Default |
|---|---|---|---|
| tz | No | IANA timezone for kickoff times, e.g. America/Mexico_City | |
| lang | No | Locale for dates, provider attribution, and commentary: en, es, pt, fr (the summary scaffold stays English; other locales fall back to en) | |
| stage | No | Knockout round to show (omit for the full bracket) | |
| flavor | No | Commentary flair: off, subtle, full (default: full) |
| Name | Required | Description |
|---|---|---|
| view | Yes | |
| source | No | |
| degraded | No | |
| responseTruncated | No | |
| standingsDegraded | No | |
| responseTruncation | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond the readOnlyHint and openWorldHint annotations, the description discloses meaningful runtime behavior: group slots project from live standings only after a group starts, winner slots require a confirmed FT result, and the tool falls back to structure-only when live data is unavailable. This is exactly the kind of non-obvious behavior an agent needs to know.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Four short sentences each add a distinct fact: the bracket scope, live-data projection rules, stage filtering, and fallback behavior. There is no filler, repetition of schema details, or unnecessary preamble.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the read-only annotations, full schema coverage, and presence of an output schema, the description covers all non-obvious behavior an agent needs: live-data dependencies, fallback mode, and optional round filtering. Nothing critical is missing for correct invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema already documents all four parameters with 100% coverage, so the description only needs to add value beyond that. It does so for the stage parameter by enumerating the round codes and stating that omitting it returns the full bracket; tz, lang, and flavor receive no additional prose, but the schema descriptions are sufficient.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly identifies the resource as a knockout bracket from the Round of 32 through the final with live scores overlaid, which distinguishes it from standings or match tools. It lacks an explicit action verb like 'returns' or 'shows', but the tool name and noun phrase make the purpose unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives useful context about when data is available (group started, confirmed FT result) and how the optional stage parameter filters the bracket. However, it does not explicitly route the agent away from siblings like get_standings or get_live, so the choice between tools is left mostly to inference.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Only matches in play right now — each with current score and minute (empty when nothing is live). Use during matches for in-play state; for a full day's schedule including upcoming and finished, use get_today. tz/lang/flavor affect formatting only.
| Name | Required | Description | Default |
|---|---|---|---|
| tz | No | IANA timezone for kickoff times, e.g. America/Mexico_City | |
| lang | No | Locale for dates, provider attribution, and commentary: en, es, pt, fr (the summary scaffold stays English; other locales fall back to en) | |
| flavor | No | Commentary flair: off, subtle, full (default: full) |
| Name | Required | Description |
|---|---|---|
| count | Yes | |
| source | Yes | |
| matches | Yes | |
| degraded | Yes | |
| truncated | Yes | |
| responseTruncated | No | |
| responseTruncation | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations declare readOnlyHint and openWorldHint. The description adds valuable behavioral context: empty when nothing is live, and that tz/lang/flavor affect formatting only (not the match set). This goes beyond the annotations without contradicting them.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences: first sentence front-loads the core behavior and empty case; second sentence gives usage guidance and param note. No wasted words, perfectly structured.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Complete for a read-only list tool. It covers usage, empty response, param scope, and points to the sibling for alternative cases. Output schema exists, so return details need not be repeated. Annotations cover safety profile.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema covers all 3 parameters with detailed descriptions. The description adds the crucial semantic that these parameters affect only formatting, not data selection – a non-obvious behavior that prevents misuse. This elevates it above the schema-only baseline.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description states exactly what the tool does: returns only matches currently in play, with current score and minute. It also clarifies the empty response case when nothing is live. This clearly distinguishes it from siblings like get_today.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly states when to use (during matches for in-play state) and names the alternative (get_today) for a full day's schedule including upcoming and finished matches. No ambiguity remains.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Read-only prediction-market signals for a match (by id), a team's current-or-next fixture, or a date (default: today). Returns market-implied percentages with attribution; complete:false means the provider read was incomplete, not that no signal exists. Shown only before and during a match — finished matches have no market read. Informational only — relay the numbers factually; do not add betting, trading, or 'value' advice, and do not invent links.
| Name | Required | Description | Default |
|---|---|---|---|
| tz | No | IANA timezone for kickoff times, e.g. America/Mexico_City | |
| date | No | Date as YYYY-MM-DD (default: today) for all that day's signals | |
| lang | No | Locale for dates, provider attribution, and commentary: en, es, pt, fr (the summary scaffold stays English; other locales fall back to en) | |
| team | No | 3-letter team code, e.g. MEX — resolves to the team's in-play match when one is live, else their next fixture | |
| flavor | No | Commentary flair: off, subtle, full (default: full) | |
| matchId | No | Match id (most specific) |
| Name | Required | Description |
|---|---|---|
| date | No | |
| team | No | |
| count | No | |
| signal | No | |
| matchId | No | |
| signals | No | |
| complete | No | False when the market provider did not complete every relevant read |
| degraded | No | |
| truncated | No | |
| informationalOnly | Yes | |
| responseTruncated | No | |
| responseTruncation | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond the readOnlyHint annotation, the description explains the semantics of the complete field (incomplete read ≠ no signal), the availability window (only before/during match), and warns not to invent links or add betting advice. These are meaningful behavioral disclosures that annotations alone do not provide.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Three sentences with no wasted words: the first front-loads the core purpose and query modes, the second clarifies a potentially confusing return field, and the third covers availability and usage constraints. Every sentence earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With an output schema present and readOnly/openWorld annotations, the description fills the key gaps: complete:false interpretation, the no-data-for-finished-matches constraint, and the informational-only usage. An agent has enough information to invoke the tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema documents all six parameters with 100% coverage, including descriptions for team, matchId, and date. The description repeats the query-mode mapping but adds no parameter detail beyond what the schema already provides, so baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool returns read-only prediction-market signals and enumerates three query modes: match id, team's current-or-next fixture, and date. It identifies the resource type (market signals) distinctly from sibling data tools, though it does not explicitly name a sibling alternative.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives clear context for when to use the tool: before and during a match, and notes that finished matches have no market read. It also instructs to relay numbers factually and not add advice, which helps an agent decide when and how to invoke it. However, it does not explicitly contrast with siblings like get_match or get_next_fixture.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
One match by its id, with live score/minute overlaid when it's in play. Optional prediction-market enrichment carries marketComplete; false means the read was incomplete, not that no signal exists. Get the id from get_today or get_live; to find a team's match without an id, use get_next_fixture. tz/lang/flavor affect formatting.
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes | Match id | |
| tz | No | IANA timezone for kickoff times, e.g. America/Mexico_City | |
| lang | No | Locale for dates, provider attribution, and commentary: en, es, pt, fr (the summary scaffold stays English; other locales fall back to en) | |
| flavor | No | Commentary flair: off, subtle, full (default: full) |
| Name | Required | Description |
|---|---|---|
| match | Yes | |
| source | No | |
| degraded | No | |
| marketSignal | No | |
| marketComplete | No | False when optional market enrichment did not check this fixture |
| responseTruncated | No | |
| responseTruncation | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already cover readOnlyHint and openWorldHint, but the description adds concrete behavioral context: the live score/minute overlay is conditional on in-play status, and marketComplete=false is explicitly interpreted as an incomplete read rather than a missing signal. This directly enriches the open-world annotation and prevents a likely misinterpretation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Three sentences with zero redundancy. Each sentence carries unique value: main behavior, the marketComplete caveat, and id sourcing/alternative routing. Information is front-loaded and every word earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With an output schema and annotations present, the description covers all necessary missing context: how to get the id, when to choose an alternative, and how to interpret a potentially ambiguous output field. Nothing an agent needs to call this tool correctly is omitted.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the schema already documents all four parameters. The description's only addition is the high-level note that 'tz/lang/flavor affect formatting,' which is a mild summary rather than substantive new semantic detail. Baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description states the exact verb and resource ('One match by its id') and explicitly differentiates from sibling tools: get_today/get_live provide collections, get_next_fixture finds a match without an id. An agent can immediately tell this tool is for a known match id.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
It gives explicit sourcing guidance ('Get the id from get_today or get_live') and names the alternative for id-less team lookup ('use get_next_fixture'). This is clear when-to-use and when-not-to-use guidance with no gaps.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
A team's next match, live-resolved: a confirmed knockout tie (Round of 32 onward) is read from the live overlay, group fixtures from the bundled schedule. Use a 3-letter code, e.g. MEX, BRA, USA. Falls back to the bundled schedule if the provider is unreachable.
| Name | Required | Description | Default |
|---|---|---|---|
| tz | No | IANA timezone for kickoff times, e.g. America/Mexico_City | |
| lang | No | Locale for dates, provider attribution, and commentary: en, es, pt, fr (the summary scaffold stays English; other locales fall back to en) | |
| team | Yes | 3-letter team code, e.g. MEX | |
| flavor | No | Commentary flair: off, subtle, full (default: full) |
| Name | Required | Description |
|---|---|---|
| team | Yes | |
| source | Yes | |
| fixture | Yes | |
| degraded | Yes | |
| responseTruncated | No | |
| responseTruncation | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond the readOnlyHint and openWorldHint annotations, the description discloses meaningful behavior: confirmed knockout ties are read from the live overlay, group fixtures come from the bundled schedule, and there is a fallback if the provider is unreachable. This adds real context about external dependencies and failure modes.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Three concise sentences front-load the core purpose, then cover required input format and fallback behavior. There is no filler or repetition of the title or schema.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description covers purpose, data source selection, fallback behavior, and the required input format. An output schema exists, so return-value details are not the description's responsibility, and the parameter details are fully covered by the input schema.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, and each parameter already has a meaningful description. The tool description only reinforces the 3-letter code with examples like MEX, BRA, USA, adding marginal value beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with 'A team's next match, live-resolved', giving a clear verb+resource and distinguishing it from generic match or today listings. It adds source nuance by separating knockout ties from group fixtures, though it never names sibling tools to draw an explicit contrast.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description clearly instructs the caller to use a 3-letter team code and explains the data-source behavior, but it does not state when to choose this tool over get_match or get_today. Usage is implied rather than explicitly routed against alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Live cumulative group standings — pass a group letter A–L, or omit for all 12. Returns ranked rows (team, played, W/D/L, goal difference, points). Use get_today for fixtures/scores and get_next_fixture for one team. If unavailable, the default World Cup scope returns a roster at zero; competitions without a compatible bundled roster return no tables. Both are flagged degraded.
| Name | Required | Description | Default |
|---|---|---|---|
| tz | No | IANA timezone for kickoff times, e.g. America/Mexico_City | |
| lang | No | Locale for dates, provider attribution, and commentary: en, es, pt, fr (the summary scaffold stays English; other locales fall back to en) | |
| group | No | Group letter A–L (omit for all) | |
| flavor | No | Commentary flair: off, subtle, full (default: full) |
| Name | Required | Description |
|---|---|---|
| source | Yes | |
| tables | Yes | |
| degraded | Yes | |
| responseTruncated | No | |
| responseTruncation | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already mark it read-only and open-world, and the description adds useful degraded behavior context: default scope returns a zero roster when unavailable, and incompatible competitions return no tables. This goes beyond the annotations, though it could define 'degraded' more concretely.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Four tight sentences, front-loaded with the core purpose and scope, followed by sibling routing and edge-case behavior. There is no filler or repetition of schema details.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With an output schema, full parameter documentation, and safety annotations, the description covers what the tool returns, how to scope it, sibling alternatives, and degraded-mode behavior. Minor gap: 'flagged degraded' is not fully explained, but this is a small omission given the rich structured context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema carries the parameter meaning. The description reinforces group behavior ('omit for all 12') but adds no detail about tz, lang, or flavor beyond what the schema already provides.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States exactly what the tool returns: live cumulative group standings with ranked rows (team, played, W/D/L, goal difference, points). It clearly distinguishes itself from siblings by naming get_today for fixtures/scores and get_next_fixture for team-specific info, so an agent can route correctly.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly explains how to scope the call (pass a group letter or omit for all 12) and names the alternatives for related use cases. This gives the agent clear when-to-use-this vs use-that guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Resolve a nation name or 3-letter code to its FIFA code, flag, and group. Fuzzy and forgiving: accepts "Mexico", "mex", "USA", "DR Congo", "Türkiye"/"Turkey", "Holland", etc. Use this FIRST to turn a user's team name into the code the other tools need (get_next_fixture, get_standings, get_market_signal, get_share_snippet). Returns the single confident match (team), plus candidates (matches) when the query is ambiguous (e.g. "south" → South Africa, South Korea). Offline — reads the bundled roster, never the network.
| Name | Required | Description | Default |
|---|---|---|---|
| query | Yes | Team name or 3-letter code, e.g. "Mexico", "MEX", "DR Congo" |
| Name | Required | Description |
|---|---|---|
| team | Yes | |
| count | Yes | |
| query | Yes | |
| matches | Yes | |
| responseTruncated | No | |
| responseTruncation | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint and openWorldHint; the description adds valuable behavioral context: matching is fuzzy and forgiving, the tool is offline and reads the bundled roster, and it returns a single confident match plus candidates for ambiguous queries. There is no contradiction with the annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is front-loaded with the core transformation, then adds examples, usage context, return behavior, and offline status in a logical order. Every sentence earns its place, and the examples are illustrative rather than padding.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a single-parameter lookup tool with an output schema available, the description covers input examples, matching behavior, ambiguous-query output, and offline safety. It also tells the agent where this tool fits in the larger workflow. The only minor omission is explicit no-match behavior, but this does not undermine completeness given the output schema.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the schema already documents the query parameter. The description adds meaning beyond the schema with concrete examples ('Mexico', 'mex', 'USA', 'DR Congo', 'Türkiye'/'Turkey', 'Holland'), explains fuzzy matching tolerance, and clarifies ambiguity handling.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with a specific verb and resource ('Resolve a nation name or 3-letter code to its FIFA code, flag, and group'), making the core purpose immediately clear. It also differentiates itself from sibling tools by explicitly positioning itself as the lookup step that produces the code other tools consume.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly says 'Use this FIRST' and lists the downstream tools that need the resolved code (get_next_fixture, get_standings, get_market_signal, get_share_snippet). It does not explicitly state when not to use it or name a comparable resolution alternative, but the workflow guidance is unambiguous.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
All fixtures for a date (default: today), with live score and minute overlaid on any match in play. Optional prediction-market enrichment carries marketComplete; false means the read was incomplete, not that no signal exists. Use this for a whole day's card; for only in-play matches use get_live, for one team's match use get_next_fixture, for a single match's detail use get_match. Kickoffs render in tz; lang localizes dates, attribution, and commentary (en/es/pt/fr); flavor sets commentary tone.
| Name | Required | Description | Default |
|---|---|---|---|
| tz | No | IANA timezone for kickoff times, e.g. America/Mexico_City | |
| date | No | Date as YYYY-MM-DD (default: today) | |
| lang | No | Locale for dates, provider attribution, and commentary: en, es, pt, fr (the summary scaffold stays English; other locales fall back to en) | |
| flavor | No | Commentary flair: off, subtle, full (default: full) |
| Name | Required | Description |
|---|---|---|
| date | Yes | |
| count | Yes | |
| source | Yes | |
| matches | Yes | |
| degraded | Yes | |
| truncated | Yes | |
| marketSignals | No | |
| marketComplete | No | False when optional market enrichment did not check every relevant fixture |
| responseTruncated | No | |
| responseTruncation | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already provide readOnlyHint=true and openWorldHint=true, lowering the burden. The description adds valuable context beyond that: live score/minute overlay, the meaning of marketComplete=false as an incomplete read rather than absent signal, and locale/flavor behavior. This is strong supplementary behavioral disclosure, though it does not discuss data freshness or pagination.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is dense but every sentence earns its place: core behavior first, sibling differentiation second, and parameter semantics third. It is well-structured and front-loaded without redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With an output schema present, annotations covering safety/open-world semantics, and four optional parameters all documented in the schema, the description provides the remaining context needed: when to use the tool, what the live overlay means, how the marketComplete flag should be interpreted, and how parameters affect output. Nothing critical is missing for correct invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the baseline is 3. The description adds meaning beyond the schema by explaining that tz affects kickoff rendering, lang localizes dates/attribution/commentary, and flavor sets commentary tone. It also clarifies the marketComplete semantics relevant to prediction-market enrichment, which supports parameter understanding.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb and resource ('All fixtures for a date') with a clear default of today. It also explicitly differentiates itself from sibling tools by describing scope as 'a whole day's card' and naming get_live, get_next_fixture, and get_match as alternatives for narrower queries.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides explicit when-to-use guidance ('Use this for a whole day's card') and names the exact sibling tools to use for in-play matches, a single team's fixture, or single-match detail. This leaves no ambiguity about tool selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
v0.10.0get_bracket2 fields changedOutput schema / properties / responseTruncatedAdded value: +{
+ "type": "boolean"
+}Output schema / properties / responseTruncationAdded value: +{
+ "type": "string"
+}get_live4 fields changedOutput schema / properties / responseTruncatedAdded value: +{
+ "type": "boolean"
+}Output schema / properties / responseTruncationAdded value: +{
+ "type": "string"
+}Output schema / properties / truncatedAdded value: +{
+ "type": "boolean"
+}Output schema / requiredPrevious value: -[
- "degraded",
- "source",
- "count",
- "matches"
-]New value: +[
+ "degraded",
+ "source",
+ "count",
+ "truncated",
+ "matches"
+]get_market_signal5 fields changedOutput schema / properties / completeAdded value: +{
+ "description": "False when the market provider did not complete every relevant read",
+ "type": "boolean"
+}Output schema / properties / countAdded value: +{
+ "type": "number"
+}Output schema / properties / responseTruncatedAdded value: +{
+ "type": "boolean"
+}Output schema / properties / responseTruncationAdded value: +{
+ "type": "string"
+}Output schema / properties / truncatedAdded value: +{
+ "type": "boolean"
+}get_match3 fields changedOutput schema / properties / marketCompleteAdded value: +{
+ "description": "False when optional market enrichment did not check this fixture",
+ "type": "boolean"
+}Output schema / properties / responseTruncatedAdded value: +{
+ "type": "boolean"
+}Output schema / properties / responseTruncationAdded value: +{
+ "type": "string"
+}get_next_fixture2 fields changedOutput schema / properties / responseTruncatedAdded value: +{
+ "type": "boolean"
+}Output schema / properties / responseTruncationAdded value: +{
+ "type": "string"
+}get_share_snippet5 fields changedOutput schema / properties / countAdded value: +{
+ "type": "number"
+}Output schema / properties / marketCompleteAdded value: +{
+ "description": "False when optional market enrichment did not check every relevant fixture",
+ "type": "boolean"
+}Output schema / properties / responseTruncatedAdded value: +{
+ "type": "boolean"
+}Output schema / properties / responseTruncationAdded value: +{
+ "type": "string"
+}Output schema / properties / truncatedAdded value: +{
+ "type": "boolean"
+}get_standings2 fields changedOutput schema / properties / responseTruncatedAdded value: +{
+ "type": "boolean"
+}Output schema / properties / responseTruncationAdded value: +{
+ "type": "string"
+}get_team2 fields changedOutput schema / properties / responseTruncatedAdded value: +{
+ "type": "boolean"
+}Output schema / properties / responseTruncationAdded value: +{
+ "type": "string"
+}get_today5 fields changedOutput schema / properties / marketCompleteAdded value: +{
+ "description": "False when optional market enrichment did not check every relevant fixture",
+ "type": "boolean"
+}Output schema / properties / responseTruncatedAdded value: +{
+ "type": "boolean"
+}Output schema / properties / responseTruncationAdded value: +{
+ "type": "string"
+}Output schema / properties / truncatedAdded value: +{
+ "type": "boolean"
+}Output schema / requiredPrevious value: -[
- "date",
- "degraded",
- "source",
- "count",
- "matches"
-]New value: +[
+ "date",
+ "degraded",
+ "source",
+ "count",
+ "truncated",
+ "matches"
+]v0.9.0get_bracket2 fields changedInput schema / properties / lang / descriptionPrevious value: -"Locale for formatting: en, es, pt, fr (other locales fall back to en)"New value: +"Locale for dates, provider attribution, and commentary: en, es, pt, fr (the summary scaffold stays English; other locales fall back to en)"Output schema / (root)Previous value: -nullNew value: +{
+ "$schema": "http://json-schema.org/draft-07/schema#",
+ "additionalProperties": false,
+ "properties": {
+ "degraded": {
+ "type": "boolean"
+ },
+ "source": {
+ "type": [
+ "string",
+ "null"
+ ]
+ },
+ "standingsDegraded": {
+ "type": "boolean"
+ },
+ "view": {
+ "anyOf": [
+ {
+ "additionalProperties": true,
+ "properties": {},
+ "type": "object"
+ },
+ {
+ "type": "null"
+ }
+ ]
+ }
+ },
+ "required": [
+ "view"
+ ],
+ "type": "object"
+}get_live2 fields changedInput schema / properties / lang / descriptionPrevious value: -"Locale for formatting: en, es, pt, fr (other locales fall back to en)"New value: +"Locale for dates, provider attribution, and commentary: en, es, pt, fr (the summary scaffold stays English; other locales fall back to en)"Output schema / (root)Previous value: -nullNew value: +{
+ "$schema": "http://json-schema.org/draft-07/schema#",
+ "additionalProperties": false,
+ "properties": {
+ "count": {
+ "type": "number"
+ },
+ "degraded": {
+ "type": "boolean"
+ },
+ "matches": {
+ "items": {
+ "additionalProperties": true,
+ "properties": {
+ "away": {
+ "$ref": "#/properties/matches/items/properties/home"
+ },
+ "group": {
+ "type": [
+ "string",
+ "null"
+ ]
+ },
+ "home": {
+ "additionalProperties": true,
+ "properties": {
+ "code": {
+ "type": "string"
+ },
+ "flag": {
+ "type": "string"
+ },
+ "name": {
+ "type": "string"
+ }
+ },
+ "type": "object"
+ },
+ "id": {
+ "type": "string"
+ },
+ "kickoff": {
+ "type": "string"
+ },
+ "minute": {
+ "type": [
+ "number",
+ "null"
+ ]
+ },
+ "score": {
+ "anyOf": [
+ {
+ "additionalProperties": true,
+ "properties": {
+ "away": {
+ "type": "number"
+ },
+ "home": {
+ "type": "number"
+ }
+ },
+ "type": "object"
+ },
+ {
+ "type": "null"
+ }
+ ]
+ },
+ "shootout": {
+ "$ref": "#/properties/matches/items/properties/score/anyOf/0"
+ },
+ "stage": {
+ "type": "string"
+ },
+ "status": {
+ "type": "string"
+ },
+ "venue": {
+ "type": "string"
+ },
+ "winnerCode": {
+ "type": "string"
+ }
+ },
+ "required": [
+ "id"
+ ],
+ "type": "object"
+ },
+ "type": "array"
+ },
+ "source": {
+ "type": [
+ "string",
+ "null"
+ ]
+ }
+ },
+ "required": [
+ "degraded",
+ "source",
+ "count",
+ "matches"
+ ],
+ "type": "object"
+}get_market_signal2 fields changedInput schema / properties / lang / descriptionPrevious value: -"Locale for formatting: en, es, pt, fr (other locales fall back to en)"New value: +"Locale for dates, provider attribution, and commentary: en, es, pt, fr (the summary scaffold stays English; other locales fall back to en)"Output schema / (root)Previous value: -nullNew value: +{
+ "$schema": "http://json-schema.org/draft-07/schema#",
+ "additionalProperties": false,
+ "properties": {
+ "date": {
+ "type": "string"
+ },
+ "degraded": {
+ "type": "boolean"
+ },
+ "informationalOnly": {
+ "type": "boolean"
+ },
+ "matchId": {
+ "type": [
+ "string",
+ "null"
+ ]
+ },
+ "signal": {
+ "anyOf": [
+ {
+ "additionalProperties": true,
+ "properties": {},
+ "type": "object"
+ },
+ {
+ "type": "null"
+ }
+ ]
+ },
+ "signals": {
+ "items": {
+ "$ref": "#/properties/signal/anyOf/0"
+ },
+ "type": "array"
+ },
+ "team": {
+ "type": "string"
+ }
+ },
+ "required": [
+ "informationalOnly"
+ ],
+ "type": "object"
+}get_match2 fields changedInput schema / properties / lang / descriptionPrevious value: -"Locale for formatting: en, es, pt, fr (other locales fall back to en)"New value: +"Locale for dates, provider attribution, and commentary: en, es, pt, fr (the summary scaffold stays English; other locales fall back to en)"Output schema / (root)Previous value: -nullNew value: +{
+ "$schema": "http://json-schema.org/draft-07/schema#",
+ "additionalProperties": false,
+ "properties": {
+ "degraded": {
+ "type": "boolean"
+ },
+ "marketSignal": {
+ "anyOf": [
+ {
+ "additionalProperties": true,
+ "properties": {},
+ "type": "object"
+ },
+ {
+ "type": "null"
+ }
+ ]
+ },
+ "match": {
+ "anyOf": [
+ {
+ "additionalProperties": true,
+ "properties": {
+ "away": {
+ "$ref": "#/properties/match/anyOf/0/properties/home"
+ },
+ "group": {
+ "type": [
+ "string",
+ "null"
+ ]
+ },
+ "home": {
+ "additionalProperties": true,
+ "properties": {
+ "code": {
+ "type": "string"
+ },
+ "flag": {
+ "type": "string"
+ },
+ "name": {
+ "type": "string"
+ }
+ },
+ "type": "object"
+ },
+ "id": {
+ "type": "string"
+ },
+ "kickoff": {
+ "type": "string"
+ },
+ "minute": {
+ "type": [
+ "number",
+ "null"
+ ]
+ },
+ "score": {
+ "anyOf": [
+ {
+ "additionalProperties": true,
+ "properties": {
+ "away": {
+ "type": "number"
+ },
+ "home": {
+ "type": "number"
+ }
+ },
+ "type": "object"
+ },
+ {
+ "type": "null"
+ }
+ ]
+ },
+ "shootout": {
+ "$ref": "#/properties/match/anyOf/0/properties/score/anyOf/0"
+ },
+ "stage": {
+ "type": "string"
+ },
+ "status": {
+ "type": "string"
+ },
+ "venue": {
+ "type": "string"
+ },
+ "winnerCode": {
+ "type": "string"
+ }
+ },
+ "required": [
+ "id"
+ ],
+ "type": "object"
+ },
+ {
+ "type": "null"
+ }
+ ]
+ },
+ "source": {
+ "type": [
+ "string",
+ "null"
+ ]
+ }
+ },
+ "required": [
+ "match"
+ ],
+ "type": "object"
+}get_next_fixture2 fields changedInput schema / properties / lang / descriptionPrevious value: -"Locale for formatting: en, es, pt, fr (other locales fall back to en)"New value: +"Locale for dates, provider attribution, and commentary: en, es, pt, fr (the summary scaffold stays English; other locales fall back to en)"Output schema / (root)Previous value: -nullNew value: +{
+ "$schema": "http://json-schema.org/draft-07/schema#",
+ "additionalProperties": false,
+ "properties": {
+ "degraded": {
+ "type": "boolean"
+ },
+ "fixture": {
+ "anyOf": [
+ {
+ "additionalProperties": true,
+ "properties": {
+ "away": {
+ "$ref": "#/properties/fixture/anyOf/0/properties/home"
+ },
+ "group": {
+ "type": [
+ "string",
+ "null"
+ ]
+ },
+ "home": {
+ "additionalProperties": true,
+ "properties": {
+ "code": {
+ "type": "string"
+ },
+ "flag": {
+ "type": "string"
+ },
+ "name": {
+ "type": "string"
+ }
+ },
+ "type": "object"
+ },
+ "id": {
+ "type": "string"
+ },
+ "kickoff": {
+ "type": "string"
+ },
+ "minute": {
+ "type": [
+ "number",
+ "null"
+ ]
+ },
+ "score": {
+ "anyOf": [
+ {
+ "additionalProperties": true,
+ "properties": {
+ "away": {
+ "type": "number"
+ },
+ "home": {
+ "type": "number"
+ }
+ },
+ "type": "object"
+ },
+ {
+ "type": "null"
+ }
+ ]
+ },
+ "shootout": {
+ "$ref": "#/properties/fixture/anyOf/0/properties/score/anyOf/0"
+ },
+ "stage": {
+ "type": "string"
+ },
+ "status": {
+ "type": "string"
+ },
+ "venue": {
+ "type": "string"
+ },
+ "winnerCode": {
+ "type": "string"
+ }
+ },
+ "required": [
+ "id"
+ ],
+ "type": "object"
+ },
+ {
+ "type": "null"
+ }
+ ]
+ },
+ "source": {
+ "type": [
+ "string",
+ "null"
+ ]
+ },
+ "team": {
+ "type": "string"
+ }
+ },
+ "required": [
+ "team",
+ "fixture",
+ "degraded",
+ "source"
+ ],
+ "type": "object"
+}get_share_snippet2 fields changedInput schema / properties / lang / descriptionPrevious value: -"Locale for formatting: en, es, pt, fr (other locales fall back to en)"New value: +"Locale for dates, provider attribution, and commentary: en, es, pt, fr (the summary scaffold stays English; other locales fall back to en)"Output schema / (root)Previous value: -nullNew value: +{
+ "$schema": "http://json-schema.org/draft-07/schema#",
+ "additionalProperties": false,
+ "properties": {
+ "degraded": {
+ "type": "boolean"
+ },
+ "group": {
+ "type": "string"
+ },
+ "informationalOnly": {
+ "type": "boolean"
+ },
+ "kind": {
+ "type": "string"
+ },
+ "marketSignals": {
+ "additionalProperties": {
+ "$ref": "#/properties/tables/anyOf/0"
+ },
+ "type": "object"
+ },
+ "matches": {
+ "items": {
+ "additionalProperties": true,
+ "properties": {
+ "away": {
+ "$ref": "#/properties/matches/items/properties/home"
+ },
+ "group": {
+ "type": [
+ "string",
+ "null"
+ ]
+ },
+ "home": {
+ "additionalProperties": true,
+ "properties": {
+ "code": {
+ "type": "string"
+ },
+ "flag": {
+ "type": "string"
+ },
+ "name": {
+ "type": "string"
+ }
+ },
+ "type": "object"
+ },
+ "id": {
+ "type": "string"
+ },
+ "kickoff": {
+ "type": "string"
+ },
+ "minute": {
+ "type": [
+ "number",
+ "null"
+ ]
+ },
+ "score": {
+ "anyOf": [
+ {
+ "additionalProperties": true,
+ "properties": {
+ "away": {
+ "type": "number"
+ },
+ "home": {
+ "type": "number"
+ }
+ },
+ "type": "object"
+ },
+ {
+ "type": "null"
+ }
+ ]
+ },
+ "shootout": {
+ "$ref": "#/properties/matches/items/properties/score/anyOf/0"
+ },
+ "stage": {
+ "type": "string"
+ },
+ "status": {
+ "type": "string"
+ },
+ "venue": {
+ "type": "string"
+ },
+ "winnerCode": {
+ "type": "string"
+ }
+ },
+ "required": [
+ "id"
+ ],
+ "type": "object"
+ },
+ "type": "array"
+ },
+ "snippet": {
+ "type": "string"
+ },
+ "source": {
+ "type": [
+ "string",
+ "null"
+ ]
+ },
+ "stage": {
+ "type": "string"
+ },
+ "style": {
+ "type": "string"
+ },
+ "tables": {
+ "anyOf": [
+ {
+ "additionalProperties": true,
+ "properties": {},
+ "type": "object"
+ },
+ {
+ "items": {
+ "$ref": "#/properties/tables/anyOf/0"
+ },
+ "type": "array"
+ },
+ {
+ "type": "null"
+ }
+ ]
+ },
+ "target": {
+ "type": "string"
+ },
+ "team": {
+ "type": "string"
+ },
+ "view": {
+ "anyOf": [
+ {
+ "$ref": "#/properties/tables/anyOf/0"
+ },
+ {
+ "type": "null"
+ }
+ ]
+ }
+ },
+ "required": [
+ "kind"
+ ],
+ "type": "object"
+}get_standings2 fields changedInput schema / properties / lang / descriptionPrevious value: -"Locale for formatting: en, es, pt, fr (other locales fall back to en)"New value: +"Locale for dates, provider attribution, and commentary: en, es, pt, fr (the summary scaffold stays English; other locales fall back to en)"Output schema / (root)Previous value: -nullNew value: +{
+ "$schema": "http://json-schema.org/draft-07/schema#",
+ "additionalProperties": false,
+ "properties": {
+ "degraded": {
+ "type": "boolean"
+ },
+ "source": {
+ "type": [
+ "string",
+ "null"
+ ]
+ },
+ "tables": {
+ "anyOf": [
+ {
+ "additionalProperties": true,
+ "properties": {},
+ "type": "object"
+ },
+ {
+ "items": {
+ "$ref": "#/properties/tables/anyOf/0"
+ },
+ "type": "array"
+ },
+ {
+ "type": "null"
+ }
+ ]
+ }
+ },
+ "required": [
+ "degraded",
+ "source",
+ "tables"
+ ],
+ "type": "object"
+}get_teamget_todayv0.8.15get_todayv0.8.4get_bracketget_share_snippet2 fields changedInput schema / properties / bracketAdded value: +{
+ "description": "Knockout bracket card (use with optional knockoutStage)",
+ "type": "boolean"
+}Input schema / properties / knockoutStageAdded value: +{
+ "description": "Filter the bracket card to one round",
+ "enum": [
+ "R32",
+ "R16",
+ "QF",
+ "SF",
+ "3P",
+ "F"
+ ],
+ "type": "string"
+}v0.5.0get_share_snippet1 field changedInput schema / properties / groupAdded value: +{
+ "description": "Group letter A–L for a standings card, e.g. A",
+ "pattern": "^[A-La-l]$",
+ "type": "string"
+}get_market_signal1 field changedInput schema / properties / team / descriptionPrevious value: -"3-letter team code for that team's next fixture, e.g. MEX"New value: +"3-letter team code, e.g. MEX — resolves to the team's in-play match when one is live, else their next fixture"v0.1.0get_liveget_market_signalget_matchget_next_fixtureget_share_snippetget_standingsget_todayScored across 9 tools
Each tool targets a distinct query niche: date-level fixtures, live-only matches, single-match details, standings, bracket, team lookup, market signals, and shareable snippets. The descriptions explicitly cross-reference alternatives, so adjacent tools like get_today and get_live are easy to tell apart.
All nine tools follow the same lowercase snake_case get_ prefix, making the API predictable at a glance. The descriptors are clear nouns or states rather than vague verbs, so naming reinforces each tool's purpose.
Nine tools is a well-scoped size for a focused World Cup data server. The set covers schedule, live state, standings, bracket, market signals, team resolution, and sharing without redundant or unnecessary endpoints.
The main user journeys are covered end-to-end, from resolving a team name to getting fixtures, match details, standings, bracket, market signals, and a shareable card. The only notable gap is a dedicated endpoint for a team's past results or full fixture history, since get_next_fixture only looks ahead.
MCP tools for FIFA World Cup 2026 football, Formula 1, and IPL cricket — sims, strategy, fantasy.
FIFA World Cup 2026 schedule MCP — 104 matches, 62 country teams, jerseys, venues, kickoff times.
ESPN MCP — keyless multi-sport live scores, teams, and news via ESPN's public site API.
Schedules and results for the 2026 FIFA World Cup in natural language: today's matches, kickoff time