A read-only MCP server for live scores, fixtures, standings, and shareable cards for the 2026 men's football tournament — no API key required.
Get today's matches (get_today): Retrieve all fixtures for a given date (default: today) with live scores overlaid.
Get live matches (get_live): See all matches currently in play with real-time scores and match minute.
Get a specific match (get_match): Look up detailed info for a single match by its ID, including live state if available.
Get group standings (get_standings): View the group table for a specific group (A–L) or all groups at once.
Get next fixture for a team (get_next_fixture): Find a team's next scheduled match using its 3-letter code (e.g. MEX, BRA, USA).
Get prediction-market signals (get_market_signal): Retrieve read-only, market-implied win percentages (sourced from Polymarket) for a specific match, a team's next fixture, or all matches on a given date — informational only, not betting advice.
Get a shareable match snippet (get_share_snippet): Generate a polished, copy-pasteable plain-text match card for a specific match, a team's next fixture, a date, or live matches — with optional hashtag, market line, and install cue.
All tools support locales (en, es, pt, fr), IANA time zones, and customizable commentary flair.
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 | |
| standingsDegraded | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint and openWorldHint. The description adds context: 'Falls back to structure-only when live data is unavailable' and explains how group slots and winner slots are populated, providing behavioral details beyond 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?
Three sentences, no wasted words. Front-loaded with the main purpose, then details on optional filtering and fallback. Every sentence adds value.
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 that an output schema exists (not shown but indicated), the description covers all necessary aspects: scope, optional filtering, fallback behavior, and parameter hints. No missing context 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 coverage is 100% with descriptions for each parameter. The description adds meaning by explaining the stage enum values (R32 through F) and the overall behavior (live scores overlaid, structure-only fallback), complementing the schema well.
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 'Knockout bracket from the Round of 32 through the final, with live scores overlaid', clearly specifying the resource and scope. It distinguishes from siblings like get_standings or get_live by focusing on the bracket view.
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 explains when to pass an optional stage to filter and notes the fallback behavior when live data is unavailable. Implicitly guides usage for bracket retrieval, but does not explicitly compare to alternatives.
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 |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint and openWorldHint. The description adds transparency by noting results include current score and minute, and that output is 'empty when nothing is live'. This goes beyond annotations in describing the return format and conditional behavior.
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 two sentences with no wasted words. Critical information (purpose, when to use, alternative) is front-loaded. 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?
Given the tool's low complexity (simple live matches), the presence of an output schema, and annotations covering safety and variability, the description is fully adequate. It covers purpose, usage guidance, parameter semantics, and edge case (empty when live).
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 baseline is 3. The description adds value by stating 'tz/lang/flavor affect formatting only', clarifying that parameters do not affect data content or filtering. This is useful semantic guidance 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 clearly states the tool returns 'only matches in play right now' with current score and minute, and distinguishes itself from sibling 'get_today' which includes upcoming and finished matches. The verb 'get' plus resource 'live' is specific and 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 explicitly says 'Use during matches for in-play state; for a full day's schedule including upcoming and finished, use get_today.' This provides clear when-to-use and when-not-to-use guidance with a named alternative.
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. 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 | |
| signal | No | |
| matchId | No | |
| signals | No | |
| degraded | No | |
| informationalOnly | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description adds behavioral context beyond annotations by stating the read-only nature, the time window for data availability, and the prohibition on advice. Annotations already mark readOnlyHint and openWorldHint, but the description elaborates on use constraints.
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 two sentences with no fluff. It front-loads the core purpose and then adds constraints and advice concisely. 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?
Given the tool's complexity (6 optional params, output schema exists), the description covers the key behaviors: when to use, what it returns, and informational boundaries. It does not detail every edge case but is sufficient for a read-only tool with good annotations.
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%, baseline 3. The description adds meaning by explaining the three query modes (matchId, team, date) and their context, which helps the agent understand parameter interplay without repeating schema details.
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 reads prediction-market signals for a match by id, team, or date, and returns market-implied percentages with attribution. It distinguishes itself from sibling tools that focus on raw match data or brackets.
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 specifies that signals are only shown before and during a match, not after, and warns against adding betting or value advice. It could be improved by explicitly naming sibling tools for alternative queries, but the constraints are clear.
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. 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 |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations (readOnlyHint, openWorldHint) already declare safety and open-world nature. Description adds live score/minute overlay when in play, but this is consistent with annotations and does not disclose further behavioral traits like rate limits or data freshness. Bar is lowered by annotations, so 3 is appropriate.
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: first states core purpose and live overlay, second gives sourcing guidance, third notes formatting parameters. No wasted words, information is front-loaded.
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?
Output schema exists so return values need no explanation. Description covers purpose, id sourcing, and parameter effects. For a read-only tool with good annotations, it is fully complete.
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 parameters are fully documented. Description mentions that tz/lang/flavor affect formatting but does not add meaning beyond what schema provides. Baseline 3 is correct.
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 it retrieves one match by its id, with live score/minute overlay when in play. It explicitly directs users to get the id from get_today or get_live, and differentiates from get_next_fixture for team matches without an 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?
Provides explicit instructions on when to use this tool: get id from get_today or get_live, or use get_next_fixture for team match without id. Also notes that tz/lang/flavor affect formatting, giving context for parameter usage.
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 |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description adds significant behavioral details beyond the annotations: it discloses that the tool fetches live data ('live-resolved'), reads from a live overlay, and has a fallback to a bundled schedule. This complements the readOnlyHint and openWorldHint annotations effectively.
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: the first concisely states purpose and behavior, the second provides a usage example and fallback note. No wasted words, front-loaded with the most critical information.
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 presence of an output schema (not shown but indicated), the description covers all necessary aspects: data source, usage, fallback behavior, and parameter conventions. It is sufficiently complete for an agent to understand and use 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 already covers all parameters with descriptions (100% coverage). The description adds minor value by giving examples for the team parameter (e.g., MEX, BRA) and hinting at the flavor parameter's purpose, but it does not substantially enhance understanding 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 clearly states that it retrieves a team's next match, specifying the distinction between knockout ties (from live overlay) and group fixtures (from bundled schedule). This differentiates it from sibling tools like get_bracket or get_live, providing a specific verb and resource.
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 explicit usage guidance: use a 3-letter team code (e.g., MEX, BRA, USA) and mentions fallback behavior if the provider is unreachable. While it does not explicitly list when not to use this tool, the context is clear enough for an agent to choose appropriately.
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. Falls back to a roster at zero (flagged degraded) if live standings are 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) | |
| 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 |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already provide readOnlyHint=true and openWorldHint=true. The description adds that the tool returns live data and falls back to a roster at zero with a degraded flag if unavailable, providing valuable behavioral context beyond 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?
Two sentences with no wasted words. Front-loaded with the key purpose and immediately usable by an AI agent.
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 presence of a full output schema and high schema parameter coverage, the description covers all essential aspects: purpose, input options, fallback behavior, and sibling tool differentiation. No gaps.
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 baseline is 3. The description adds specific guidance for the 'group' parameter ('pass a group letter A–L, or omit for all'), which adds value beyond the schema's description. Other parameters are adequately covered by 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 clearly states the tool retrieves 'Live cumulative group standings' and specifies the input (group letter A–L or omit for all). It describes output format (ranked rows with team, played, W/D/L, goal difference, points) and distinguishes from siblings like get_today and get_next_fixture.
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 advises when to use alternatives: 'Use get_today for fixtures/scores and get_next_fixture for one team.' Also mentions fallback behavior (roster at zero, flagged degraded) when live standings are unavailable.
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 |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations provide readOnlyHint and openWorldHint. The description adds key behavioral details: fuzzy matching, forgiveness, offline operation, and the return of both a single match and ambiguous candidates. No contradiction with 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 well-structured and efficient. Front-loaded with purpose, followed by usage examples and behavioral notes. Every sentence contributes value with no 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?
Given the tool's fuzzy lookup nature and offline design, the description covers purpose, usage, behavioral traits, and return value expectations. Output schema exists, so return fields are partially inferred; overall complete for its complexity.
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% (single 'query' parameter with description). The description expands with concrete examples (Mexico, MEX, USA, DR Congo) and clarifies fuzzy behavior, adding meaning 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 clearly states the tool resolves a team name to FIFA code, flag, and group using fuzzy matching. It highlights its role as the first step for other tools and distinguishes it from siblings by specifying the coordination pattern.
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 instructs to use this tool first to convert user input to a code for downstream tools (get_next_fixture, etc.). Mentions offline behavior but does not explicitly state when not to use it; however, the intended workflow is clear.
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. 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 | |
| marketSignals | 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: live score overlay, timezone rendering, localization, and commentary tone. No contradictions.
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 concise: one sentence for core functionality and sibling differentiation, one sentence for parameters. Every sentence earns its place with no 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?
All 4 optional parameters are explained, purpose is clear, usage guidelines are explicit, and output schema exists so return values don't need elaboration. The tool definition is fully self-contained.
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?
With 100% schema coverage, baseline is 3. Description adds meaning beyond schema: explains tz for kickoff times, lang with explicit locales and fallback, flavor with default value. This adds moderate value.
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 retrieves all fixtures for a date with live score overlay, and explicitly differentiates from siblings by naming alternatives like get_live, get_next_fixture, and get_match.
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 provides explicit when-to-use guidance: 'Use this for a whole day's card; for only in-play matches use get_live...' and clearly specifies alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Each tool has a clearly distinct purpose: bracket standings, live matches, match details, team lookup, etc. No two tools overlap in functionality.
All tools follow the consistent 'get_' prefix and snake_case naming pattern, making them predictable and easy to use.
9 tools cover the essential operations for a football tournament data server without being excessive or insufficient.
The tool surface covers team lookup, standings, bracket, fixtures, live matches, match details, market signals, and shareable snippets, addressing key user needs.
Unclaimed servers have limited discoverability.
If you are the server author, to access and configure the admin panel.
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
Football-Data.org MCP — soccer competitions, matches, standings
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/arturogarrido/claudinho'
If you have feedback or need assistance with the MCP directory API, please join our Discord server