The World Cup History MCP server provides grounded, factual access to the complete history of FIFA World Cups (1930–2026) via 15 typed tools, covering 23 tournaments, 1,168+ matches, 2,500+ players, and 206 stadiums.
Tournament exploration: List all World Cups with hosts and champions, get full details for a specific year (brackets, awards, squads, attendance), or compare 2–6 editions side-by-side (goals, attendance, top scorers, champions).
Player search & career: Search players by name across all tournaments, or retrieve a player's full multi-tournament career history (team, position, jersey, goals, captain status, club).
Team histories & rosters: Get a nation's complete World Cup history and cross-tournament summary, or pull the full squad for a specific team and year (jersey number, position, DOB, club, goals, captain status). Filterable by confederation.
Match data: List matches filtered by year, stage, or date; get full details for any match (score, extra time, penalties, attendance, referee, stadium).
Knockout brackets: View the full bracket for any tournament, tracing results from the Round of 16 through the Final.
Group standings: Get computed group tables with FIFA tiebreakers applied for any tournament year and group.
Stadium data: List all 206 venues with capacity, GPS coordinates, elevation, and hosting history, or get details for a specific stadium by slug. Filterable by country.
Trivia & facts: Access curated factual nuggets and historical context for any tournament to avoid AI hallucinations.
Provides tools to access FIFA World Cup history data, including tournaments, matches, players, teams, stadiums, and trivia.
by Zafronix · npm:
@zafronix/wc-mcp· MIT-licensed
Model Context Protocol server giving Claude / Cursor / any MCP-aware agent grounded access to every FIFA World Cup since 1930. 23 tournaments. 1,168+ matches. 2,500+ players. 206 stadiums. All exposed as 15 typed tools so the model stops hallucinating squads, scores, brackets, and stadium altitudes.
Powered by the public Zafronix World Cup API — free tier with key, 1,000 req/day, no card.
LLMs are unreliable on:
Exact tournament results from before the trained-data window.
Roster details (jersey numbers, DOBs, captains).
Knockout-round paths and exact scores.
Stadium facts (capacity, altitude, year opened).
This MCP wraps the Zafronix WC API so the model can call a tool and get the canonical answer instead of guessing.
Related MCP server: World Cup Stats MCP
npm install -g @zafronix/wc-mcpOr run from source:
git clone https://github.com/zafronix/wc-mcp
cd wc-mcp
npm install
npm run buildhttps://api.zafronix.com/signup1,000 requests/day on the free tier, no card.
Edit ~/Library/Application Support/Claude/claude_desktop_config.json (macOS) / %APPDATA%\Claude\claude_desktop_config.json (Windows):
{
"mcpServers": {
"wc": {
"command": "npx",
"args": ["-y", "@zafronix/wc-mcp"],
"env": {
"WC_API_KEY": "zwc_pk_your_key_here"
}
}
}
}Restart Claude Desktop. You'll see a 🔌 icon in the input bar — click it to confirm wc is connected.
Settings → MCP → Add new server:
{
"mcpServers": {
"wc": {
"command": "npx",
"args": ["-y", "@zafronix/wc-mcp"],
"env": { "WC_API_KEY": "zwc_pk_..." }
}
}
}Tool | What it does |
| Every WC 1930→2026 (year, host, champion). |
| Full tournament: teams, brackets, awards, squads. |
| Side-by-side stats for 2-6 years. |
| Player name search across history. |
| Every WC a player appeared in. |
| Every nation that ever played, optional confederation filter. |
| Cross-tournament summary for a country. |
| Full squad for one team in one year. |
| Every WC venue with elevation + coords. |
| Single venue by slug. |
| Filter by year / stage / date. |
| Single match with score + attendance + referee. |
| Curated factual nuggets per year. |
| Computed group tables with FIFA tiebreakers. |
| Full knockout bracket. |
"Compare Pelé and Messi at the World Cup."
"What was the highest-altitude World Cup stadium ever, and how did goal totals there compare to sea-level venues?"
"Show me Italy's 2006 squad with positions and clubs."
"Trace Argentina's 2022 path to the title — every match, every score."
"List every African nation that has reached the World Cup quarter-finals."
npm run dev # tsx watch mode
WC_API_KEY=... npm startThe server speaks stdio. You can test it with the MCP CLI:
npx @modelcontextprotocol/inspector npx tsx src/index.tsMIT.
Side-by-side comparison of 2-6 World Cup tournaments. Returns total goals, goals per match, attendance, top scorer, best player, champion, runner-up, third place for each year. Use this when the user asks "compare 1986 vs 2022" or "what changed between 1990 and 2014". For a single year use get_tournament.
| Name | Required | Description | Default |
|---|---|---|---|
| years | Yes | Years to compare, e.g. [1986, 2002, 2022] |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. It lists returned fields and implies read-only behavior, but does not mention error handling or ordering.
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, no fluff, direct and informative.
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 no output schema, description adequately covers return values and usage constraints. Complete for a comparison tool.
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?
Input schema already describes the 'years' parameter with example. Description adds the constraint of 2-6 tournaments, adding value beyond 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?
Clear verb 'compare' with specific resource 'tournaments', explicit mention of what is returned (goals, attendance, etc.), and distinguishes from get_tournament for single year.
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 (e.g., 'compare 1986 vs 2022') and when not to use (single year use get_tournament), providing a clear alternative.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Full knockout bracket for a tournament — Round of 16 through Final, with each match's teams + result. Use this for "show me the 2014 World Cup bracket" or "trace France's 2018 path to the title".
| Name | Required | Description | Default |
|---|---|---|---|
| year | Yes | Tournament year |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, description carries full burden. It discloses scope (Round of 16 through Final) and content (teams + results). However, it omits operational details like whether it always returns full bracket or if results are always available, and does not mention any authorization or rate limits.
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 defines tool output precisely, second provides concrete usage examples. No wasted words, information is front-loaded and easy to parse.
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 simple single-parameter tool without output schema, description adequately covers purpose and usage. Could be more complete by noting potential limitations (e.g., only works for years with valid tournaments), but overall sufficient.
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 parameter description 'Tournament year'. The tool description adds no extra meaning beyond what the schema provides. Baseline 3 applies.
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?
Description clearly states tool returns full knockout bracket from Round of 16 through Final with teams and results, and provides specific usage examples like 'show me the 2014 World Cup bracket'. This differentiates it from siblings like get_match (single match) or get_tournament (tournament details).
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 usage examples (e.g., 'show me the 2014 World Cup bracket'), indicating when to use. However, it does not explicitly state when not to use or compare with alternative sibling tools, leaving some ambiguity.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Single match by ID. IDs follow {year}-{ordinal} zero-padded — the 1986 final is "1986-052", the 2022 final is "2022-064", the 2026 opener is "2026-001". Returns kickoff, both teams, score, extra time, penalties, stadium, city, attendance, referee, and (with denormalize=true) the full stadium block.
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes | Match ID, e.g. "1986-052" | |
| denormalize | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Discloses returned fields (kickoff, teams, score, etc.) and the effect of 'denormalize=true'. No annotations exist, so description carries burden. Could mention need for valid ID or error handling.
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?
Efficient single sentence with examples and list of fields. Front-loaded with purpose. Could be slightly more structured (e.g., bullet points) but not verbose.
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 simple ID lookup with one optional parameter and no output schema, the description covers purpose, ID format, return fields, and parameter effect comprehensively.
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?
Adds significant meaning: explains ID format with concrete examples and clarifies that 'denormalize=true' returns the full stadium block. Schema coverage is only 50%, but description fully compensates.
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?
Explicitly states 'Single match by ID', identifies the resource and action. Distinguishes from sibling 'list_matches' which lists multiple matches.
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 ID format examples and indicates when to use – when you have a specific match ID. Implicitly distinguishes from list_matches but does not explicitly state when not to use or mention alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get a player's full World Cup career: every tournament they appeared in, with team/position/jersey/goals/captain status per year. Use this when the user wants a "all of Pelé's World Cup matches" or "compare Messi's 4 World Cups" view. The name should be the canonical name (use search_players first if unsure).
| Name | Required | Description | Default |
|---|---|---|---|
| name | Yes | Player name, e.g. "Diego Maradona", "Lionel Messi" |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the burden. It discloses output fields and input requirement (canonical name). It does not mention that it is read-only or any potential limits, but for a simple retrieval tool, it is sufficiently transparent.
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, with two sentences plus a hint, all front-loaded with the core purpose. Every sentence adds value 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?
For a single-parameter tool without output schema, the description covers input usage and lists output fields. It references a sibling tool for name resolution, providing sufficient context. Minor gap: no mention of whether all data is returned at once or paginated.
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 a parameter description, so baseline is 3. The description adds value by providing guidance on using canonical names and referencing search_players, going beyond the schema alone.
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 specifies the verb 'Get' and the resource 'player's full World Cup career', listing exact data fields (team, position, jersey, goals, captain status per year). It distinguishes itself from siblings by focusing on career data across tournaments, not individual matches or tournaments.
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?
Explicit usage examples are given ('all of Pelé's World Cup matches', 'compare Messi's 4 World Cups'), and it advises using search_players first for name canonicalization. This provides clear when-to-use context and an alternative approach.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Single venue details by stable slug ID. Slugs are kebab-case ("estadio-azteca", "maracana", "wembley-stadium-old", "metlife-stadium"). Use list_stadiums first if you need to discover the right ID.
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes | Stadium slug, e.g. "estadio-azteca" |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. It explains slug format but does not specify return fields, read-only nature, or any side effects. Adequate but incomplete.
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 concise sentences: first defines purpose and key detail (slug format), second gives usage guidance. No unnecessary words.
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?
No output schema; description could hint at returned fields. However, tool is simple with one parameter and clear ID source, making it adequate for agents.
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 parameter with example and type. Description adds format detail ('kebab-case') and multiple examples, adding 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?
Clearly states the tool returns single venue details by slug ID. Uses specific verb 'get' and resource 'venue details', and distinguishes from sibling 'list_stadiums' which discovers IDs.
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 'list_stadiums first if you need to discover the right ID', providing clear context on when to use this tool vs an alternative.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Computed group standings with FIFA tiebreakers applied. Returns the order teams finished within each group of the given year, including W/D/L, GF, GA, GD, points. Use this for "show me the 1990 Group F table" or "who finished where in 2022 Group H?".
| Name | Required | Description | Default |
|---|---|---|---|
| year | Yes | Tournament year | |
| group | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must fully convey behavior. It states that standings are computed with FIFA tiebreakers and lists output fields, but does not discuss error handling, data freshness, or what occurs if a group is omitted.
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 concise sentences plus an example. Every sentence adds value, and the most critical information (computed standings with tiebreakers) appears first.
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 lack of an output schema, the description lists expected fields (W/D/L, GF, GA, GD, points). However, it does not clarify the behavior when 'group' is omitted (e.g., returns all groups?) or how missing data is handled.
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 describes 'year' as 'Tournament year', but 'group' has no description. The description provides examples using group letters (e.g., 'Group F') but does not specify the expected format or constraints, leaving some ambiguity.
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 returns computed group standings with tiebreakers applied, and gives specific examples. It distinguishes itself from sibling tools like get_tournament or list_matches which provide different data.
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 example queries that suggest when to use this tool (e.g., 'show me the 1990 Group F table'). However, it does not explicitly mention when not to use it or compare to alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Cross-tournament summary for a national team: every appearance, final position by year, total titles, knockout records. Use this for "Brazil's World Cup history" or "how many times has Argentina reached the final?". For a specific year's squad use get_team_roster.
| Name | Required | Description | Default |
|---|---|---|---|
| name | Yes | Country name, e.g. "Brazil", "West Germany", "England" |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden. It transparently explains the tool's behavior as generating a summary across tournaments. While it doesn't mention read-only nature or potential rate limits, the simple query nature makes this acceptable. Slightly more detail on the output could improve score.
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 extremely concise: two sentences that state the purpose and usage guidance without any filler. Every sentence adds value, and the most critical 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?
Given the tool's simplicity (single parameter, no output schema, clear sibling), the description is complete enough for an agent. It covers what the tool does, provides examples, and notes an alternative. It might be slightly ambiguous whether it covers all tournaments or just World Cup, but the phrase 'cross-tournament' clarifies it.
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 covers the parameter 'name' with 100% description coverage, providing examples like 'Brazil'. The description adds semantic value by providing concrete query examples (e.g., 'Brazil's World Cup history'), which helps an agent understand how to construct input.
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 provides a cross-tournament summary for a national team, listing appearances, final positions, titles, and knockout records. It distinguishes itself from the sibling tool get_team_roster by noting that for a specific year's squad, that sibling should be used instead.
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 provides usage examples like 'Brazil's World Cup history' and 'how many times has Argentina reached the final?', and directs users to use get_team_roster for a specific year's squad, offering clear when-to-use and when-not-to-use guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Full squad for one team in one tournament — every player with jersey, position, DOB, club, goals, captain flag. Use this for "who was on Spain's 2010 squad?" or "show me Italy's 2006 roster".
| Name | Required | Description | Default |
|---|---|---|---|
| name | Yes | Team name, e.g. "Brazil" | |
| year | Yes | Tournament year |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description fully carries the burden. It reveals the output fields and implies it is a read-only query (no mutation language). However, it does not explicitly state idempotency, auth requirements, or that it returns all players. The description adds moderate value beyond the schema.
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 extremely concise: two sentences that front-load the core purpose and data fields, followed by usage examples. Every phrase earns its place with no redundancy or filler.
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 2 required parameters, no nested objects, and no output schema, the description fully covers the tool's functionality: inputs (team name, year), output (detailed roster), and example queries. No missing information for this simple query tool.
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 100% of parameters with clear descriptions ('Team name' and 'Tournament year'). The description's examples ('Spain's 2010 squad') reinforce the schema but do not add new semantic meaning beyond what the schema 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 uses a specific verb ('get') and resource ('full squad for one team in one tournament'), specifies the exact data fields (jersey, position, DOB, club, goals, captain flag), and gives concrete query examples ('who was on Spain's 2010 squad?'). This clearly distinguishes it from siblings like get_team or search_players.
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 states the use case with two example queries, providing clear context for when to invoke this tool. It does not explicitly mention when not to use it or suggest alternatives, but the examples are sufficient for an AI agent to match user intent.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get full details for a single World Cup tournament: every team that played, group stages, knockout brackets, awards (top scorer, best player, best young player, best GK), full squads with DOB/position/club, attendance, and trivia notes. Use this when the user asks about a specific year ("1986 World Cup", "what happened at Italia 90"). For comparisons across multiple tournaments use compare_tournaments instead.
| Name | Required | Description | Default |
|---|---|---|---|
| year | Yes | Tournament year, e.g. 1986 |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. It describes the output as a comprehensive set of details (teams, groups, brackets, awards, squads, attendance, trivia), implying a read operation with no side effects. Does not explicitly state read-only but is clear about returns.
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 lists contents, second gives usage guidance. Front-loaded with key information. Could be slightly tighter, but no wasted words.
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 no output schema and one simple parameter, the description adequately explains what the tool returns and when to use it. It covers the scope of the data (full details) without needing to specify output format.
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?
Only one parameter 'year' with schema description 'Tournament year, e.g. 1986'. Schema coverage is 100%, so description adds minimal value beyond schema. Usage guidance in description reinforces the parameter's purpose but does not add new semantics.
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?
Clearly states it retrieves full details for a single World Cup tournament, including specific elements like teams, groups, brackets, awards, squads, attendance, and trivia. Distinguishes from sibling by specifying 'single' and contrasting with compare_tournaments.
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: when user asks about a specific year ('1986 World Cup', 'what happened at Italia 90'). Also provides when not to use and alternative: 'For comparisons across multiple tournaments use compare_tournaments instead.'
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Curated factual nuggets about a tournament — record-setting moments, oddities, historical context. Each entry is a single fact with category. Use this when the user wants "interesting facts about 1958" or "tell me something I don't know about Italia 90". Far less hallucination-prone than free-recall about old tournaments.
| Name | Required | Description | Default |
|---|---|---|---|
| year | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must disclose behavior. It reveals that each entry is a single fact with category, and emphasizes low hallucination risk. However, it does not specify any limits on year validity or whether results are guaranteed for all tournaments.
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 extremely concise: two main sentences and a usage example. Every sentence adds value—purpose, output format, and usage guidance. No wasted words.
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 simple tool with one parameter and no output schema, the description fully covers what the tool returns (single facts with category), how to use it (year-based queries), and why it is reliable (curated, less hallucination-prone). No additional context is needed.
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 0%, so the description must clarify the parameter. While the examples ('1958', 'Italia 90') strongly imply the 'year' parameter's purpose, the description never explicitly mentions that the year is used as the query input or explains any constraints (e.g., required vs optional, valid range).
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 uses a specific verb ('get') and resource ('trivia' about tournaments), with examples that clearly distinguish it from sibling tools like get_tournament or list_tournaments. It defines the tool as providing 'curated factual nuggets' with categories.
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: when the user wants 'interesting facts about 1958' or 'tell me something I don't know about Italia 90'. It also provides a negative guideline by noting it is 'far less hallucination-prone than free-recall about old tournaments', implying when not to use other tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List World Cup matches. Filterable by year and/or stage (group_a..group_h, round_of_16, quarter_final, semi_final, third_place, final). Returns kickoff time, home/away team, score, stadium, attendance. Use this for "show me all the 1990 group matches" or "list every World Cup final". Pair with get_match for a specific match's full details.
| Name | Required | Description | Default |
|---|---|---|---|
| year | No | ||
| stage | No | ||
| date | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Despite no annotations, it describes the return fields (kickoff time, teams, etc.) and indicates read-only behavior. Lacks details on pagination or limits.
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 that front-load the purpose and provide examples, with no wasted words.
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?
Adequately explains return fields and usage context for a list tool, and references sibling tool for deeper details.
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 has 0% coverage; description explains 'year' and 'stage' filters with examples but does not mention the 'date' parameter.
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 lists World Cup matches, specifies filterable fields (year, stage) with examples, and distinguishes from the sibling get_match tool.
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 query patterns ('show me all the 1990 group matches') and mentions pairing with get_match for details, but does not explicitly state when not to use it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List World Cup venues. 206 stadiums total across history, with capacity, lat/long, elevation in meters, opening year, and the list of WC years each one hosted. Useful for "which stadiums hosted the most World Cup matches?" or "where was the 1986 final?". Filterable by country.
| Name | Required | Description | Default |
|---|---|---|---|
| country | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, description correctly discloses that the tool returns a list of 206 stadiums with specific fields, but does not mention pagination, rate limits, or auth requirements.
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: purpose, details, and examples. No redundant information, front-loaded with key action.
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 no output schema and simple parameter, description covers returned fields, total count, and filter, but lacks details on sorting, default behavior, or how it differs from similar tools like 'get_stadium'.
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 only parameter 'country' has no schema description (0% coverage), but the description adds that it is a filter, providing some semantic 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?
Clearly states 'List World Cup venues' and lists returned fields (capacity, lat/long, etc.), distinguishing it from siblings like 'get_stadium' which likely retrieves a single stadium.
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 example queries ('which stadiums hosted the most World Cup matches?', 'where was the 1986 final?') and mentions filterability by country, giving clear usage context, though does not explicitly state when not to use or name alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List every national team that has ever played a World Cup, with confederation, first/last appearance year, and total appearances. Useful for "which African nations have made the World Cup?" or "list every CONMEBOL team". Pair with get_team for a specific country.
| Name | Required | Description | Default |
|---|---|---|---|
| confederation | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It describes that the tool lists all teams and mentions output fields, though it does not specify pagination or limits. For a simple list, this is sufficient.
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 concise sentences that are front-loaded with the main purpose. No redundant 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?
The tool has one optional parameter and no output schema. The description covers purpose, output fields, and usage examples. It is complete for the tool's simplicity.
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 0%, and the description does not explicitly define the confederation parameter, but the enum values are self-explanatory and examples imply its usage. It adds 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 clearly states it lists every national team that has ever played a World Cup, specifying the fields (confederation, first/last appearance year, total appearances). It distinguishes itself from sibling get_team, which is for a specific country.
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 concrete examples like 'which African nations have made the World Cup?' and suggests pairing with get_team. It lacks explicit when-not-to-use guidance but is clear on context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List every FIFA World Cup tournament (1930 → 2026) with year, host country list, champion (or null for the upcoming 2026 cup). Useful as a starting point when the user is exploring history or needs to disambiguate a year.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the burden. It correctly indicates a read operation (listing). However, it does not disclose any potential pagination, sorting, or ordering behavior, even though the schema has no parameters. The description is adequate but lacks depth on behavioral traits beyond the listing itself.
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 long, clearly front-loaded with the main action, and every word adds value. There is no redundancy or filler.
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 tool with no parameters and no output schema, the description fully explains what the tool does, the data range, and the specific fields returned. It is complete and leaves no ambiguity for an agent.
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 has no parameters, so schema coverage is 100%. The description adds meaning by explaining the fields returned (year, host countries, champion) and the special case of null for 2026. This provides clarity beyond the empty schema, earning a baseline plus increment.
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 explicitly states the tool lists all FIFA World Cup tournaments with specific fields (year, host, champion) across a defined range (1930-2026). This is a specific verb+resource combination that clearly distinguishes from siblings like 'get_tournament' which returns details of one tournament.
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 notes it is useful as a starting point for exploring history or disambiguating a year, which implies contexts for use. However, it does not explicitly mention when not to use it or name alternative tools, though siblings like 'get_tournament' or 'compare_tournaments' are implied alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Search players by name. Returns every World Cup squad row matching the query, with team, position, DOB, club, and tournament-year goals. Use this when the user mentions a player by name. For a player's full multi-tournament career path use get_player_career.
| Name | Required | Description | Default |
|---|---|---|---|
| q | Yes | Name fragment, e.g. "Maradona", "Mbappe", "Klose" | |
| limit | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It discloses that the tool returns 'every World Cup squad row matching the query' with specific fields. While it does not cover edge cases like empty results or query behavior, it provides reasonable transparency for a search tool.
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 pack the purpose, return format, and usage guidance. No unnecessary words or redundancy. Highly efficient.
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 simple search tool with two parameters and no output schema, the description covers the core functionality and usage context. The missing explanation of the 'limit' parameter is a minor gap, but overall it provides sufficient context for an agent.
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 50% because the 'limit' parameter has no description in schema. The tool description does not explain the 'limit' parameter or its purpose. While the 'q' parameter is already described in schema, the description adds no new parameter insights.
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 verb 'Search' and the resource 'players', and specifies the return format including fields like team, position, DOB, club, and goals. It also distinguishes from sibling tool get_player_career by stating the scope (World Cup squad rows vs. multi-tournament career).
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 tells when to use: 'when the user mentions a player by name.' Provides a clear alternative: 'For a player's full multi-tournament career path use get_player_career.' This helps an agent decide between tools.
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.1.2compare_tournamentsget_bracketget_matchget_player_careerget_stadiumget_standingsget_teamget_team_rosterget_tournamentget_trivialist_matcheslist_stadiumslist_teamslist_tournamentssearch_playersScored across 15 tools
Each tool has a clear, non-overlapping purpose. For example, compare_tournaments is for multi-year comparisons while get_tournament handles single years; get_team vs get_team_roster separate summary from roster; search_players vs get_player_career distinguish lookup from career view.
All tools follow a consistent verb_noun pattern (e.g., list_tournaments, get_match, compare_tournaments) using snake_case. There are no mixed conventions or ambiguous names.
With 15 tools, the server is well-scoped for its domain—covering tournaments, teams, players, matches, stadiums, standings, brackets, and trivia without being bloated. The number feels natural for a comprehensive World Cup history API.
The tool set covers the major CRUD-like operations for the domain: listing and getting tournaments, teams, players, matches, stadiums, comparisons, trivia, brackets, and standings. There are no obvious gaps for typical World Cup queries.
Unclaimed servers have limited discoverability.
If you are the server author, to access and configure the admin panel.
MCP tools for FIFA World Cup 2026 football, Formula 1, and IPL cricket — sims, strategy, fantasy.
API-Football MCP — comprehensive soccer/football data
First dedicated rugby MCP — Six Nations, Rugby Championship, World Cup. Fixtures + venues.
Sports MCP — wraps TheSportsDB API (free tier, test key 3, no auth required)