World Cup History MCP

Server Quality Checklist

Profile completionA complete profile improves this server's visibility in search results.

Latest release: v0.1.4
Disambiguation5/5
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.
Naming Consistency5/5
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.
Tool Count5/5
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.
Completeness5/5
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.
Average 4.3/5 across 15 of 15 tools scored.
See the Tool Scores section below for per-tool breakdowns.
- 1 of 1 community issues answered or closed in the last 6 months
- 0 commits in the last 12 weeks
- Last stable release on May 10, 2026
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI is passing
This repository is licensed under MIT License.
This repository includes a README.md file.
No tool usage detected in the last 30 days. Usage tracking helps demonstrate server value.
Tip: use the "Try in Browser" feature on the server page to seed initial usage.
This repository includes a glama.json configuration file.
If you are the author, simply .
If the server belongs to an organization, first add glama.json to the root of your repository:
```
{
  "$schema": "https://glama.ai/mcp/schemas/server.json",
  "maintainers": [
    "your-github-username"
  ]
}
```
Then . Browse examples.
View related servers

How to sync the server with GitHub?

Servers are automatically synced at least once per day, but you can also sync manually at any time to instantly update the server profile.

To manually sync the server, click the "Sync Server" button in the MCP server admin interface.

How is the quality score calculated?

The overall quality score combines two components: Tool Definition Quality (70%) and Server Coherence (30%).

Tool Definition Quality measures how well each tool describes itself to AI agents. Every tool is scored 1–5 across six dimensions: Purpose Clarity (25%), Usage Guidelines (20%), Behavioral Transparency (20%), Parameter Semantics (15%), Conciseness & Structure (10%), and Contextual Completeness (10%). The server-level definition quality score is calculated as 60% mean TDQS + 40% minimum TDQS, so a single poorly described tool pulls the score down.

Server Coherence evaluates how well the tools work together as a set, scoring four dimensions equally: Disambiguation (can agents tell tools apart?), Naming Consistency, Tool Count Appropriateness, and Completeness (are there gaps in the tool surface?).

Tiers are derived from the overall score: A (≥3.5), B (≥3.0), C (≥2.0), D (≥1.0), F (<1.0). B and above is considered passing.

Tool Scores

Behavior3/5
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.
Conciseness5/5
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.
Completeness3/5
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.
Parameters3/5
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.
Purpose5/5
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.
Usage Guidelines4/5
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.
Behavior3/5
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.
Conciseness5/5
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.
Completeness3/5
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.
Parameters3/5
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.
Purpose5/5
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.
Usage Guidelines4/5
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.
Behavior3/5
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.
Conciseness5/5
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.
Completeness4/5
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.
Parameters3/5
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.
Purpose5/5
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.
Usage Guidelines4/5
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.
Behavior3/5
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.
Conciseness5/5
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.
Completeness5/5
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.
Parameters3/5
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.
Purpose5/5
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.
Usage Guidelines4/5
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.
Behavior4/5
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.
Conciseness5/5
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.
Completeness4/5
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.
Parameters3/5
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.
Purpose5/5
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.
Usage Guidelines4/5
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.
Behavior4/5
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.
Conciseness5/5
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.
Completeness4/5
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.
Parameters3/5
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.
Purpose5/5
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.
Usage Guidelines4/5
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.
Behavior3/5
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.
Conciseness5/5
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.
Completeness3/5
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.
Parameters4/5
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.
Purpose5/5
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.
Usage Guidelines5/5
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.
Behavior4/5
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.
Conciseness4/5
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.
Completeness4/5
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.
Parameters3/5
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.
Purpose5/5
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.
Usage Guidelines5/5
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.
Behavior3/5
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.
Conciseness5/5
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.
Completeness5/5
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.
Parameters4/5
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.
Purpose5/5
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.
Usage Guidelines4/5
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.
Behavior4/5
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.
Conciseness5/5
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.
Completeness4/5
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.
Parameters2/5
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.
Purpose5/5
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.
Usage Guidelines5/5
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.
Behavior4/5
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.
Conciseness4/5
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.
Completeness5/5
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.
Parameters5/5
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.
Purpose5/5
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.
Usage Guidelines4/5
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.
Behavior4/5
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.
Conciseness5/5
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.
Completeness5/5
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.
Parameters3/5
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.
Purpose5/5
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.
Usage Guidelines5/5
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.
Behavior4/5
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.
Conciseness5/5
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.
Completeness4/5
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.
Parameters4/5
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.
Purpose5/5
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.
Usage Guidelines5/5
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.
Behavior4/5
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.
Conciseness5/5
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.
Completeness4/5
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.
Parameters4/5
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.
Purpose5/5
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.
Usage Guidelines5/5
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.
Behavior4/5
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.
Conciseness5/5
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.
Completeness5/5
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.
Parameters4/5
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.
Purpose5/5
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.
Usage Guidelines5/5
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.

GitHub Badge

Glama performs regular codebase and documentation scans to:

Confirm that the MCP server is working as expected.
Confirm that there are no obvious security issues.
Evaluate tool definition quality.

Our badge communicates server capabilities, safety, and installation instructions.

Card Badge

Copy to your README.md:

[![wc-mcp MCP server](https://glama.ai/mcp/servers/zafronix/wc-mcp/badges/card.svg)](https://glama.ai/mcp/servers/zafronix/wc-mcp)

Score Badge

Copy to your README.md:

[![wc-mcp MCP server](https://glama.ai/mcp/servers/zafronix/wc-mcp/badges/score.svg)](https://glama.ai/mcp/servers/zafronix/wc-mcp)

Latest Blog Posts

Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)
By Om-Shree-0709 on July 25, 2026.
mcp
Agent Identity
OAuth 2.1
Your AI Chatbot Just Exposed Your CEO's Salary to an Intern
By Om-Shree-0709 on July 2, 2026.
Agent Identity
MCP Security
OAuth Delegation
Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)
By Om-Shree-0709 on June 30, 2026.
Agentic Ai
Prompt Injection
WebAssembly

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/zafronix/wc-mcp'

If you have feedback or need assistance with the MCP directory API, please join our Discord server