openfoot-mcp

Server Quality Checklist

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

Latest release: v0.1.2
Disambiguation4/5
Each tool targets a distinct data domain, from standings and lineups to events and xG. Minor overlap exists between match_context and odds since both derive probabilities, but the descriptions clarify that context is a broader dossier while odds is dedicated betting-market output.
Naming Consistency5/5
All tools follow a consistent openfoot_ prefix followed by a clear resource or action name, using snake_case throughout. Whether a tool describes matches, standings, or quota, the naming pattern is predictable and unambiguous.
Tool Count5/5
Twelve tools is a well-scoped number for a football data API. Each tool represents a meaningful data product, including meta tools like quota and health, with no redundant or filler endpoints.
Completeness4/5
The surface covers the core football data workflow: identifying competitions, searching teams, fetching matches, standings, lineups, events, xG, and odds. It lacks detailed team or player profile endpoints, but for the apparent match-analysis focus, the coverage is strong with only minor gaps.
Average 3.8/5 across 12 of 12 tools scored.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 6 commits in the last 12 weeks
- No stable releases found
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI status not available
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.
Add a glama.json file to provide metadata about your server.
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.
Add related servers to improve discoverability.

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?
With no annotations, the description carries the burden of behavioral disclosure. It usefully reveals that values are 'fair' model-derived probabilities based on team form, Elo delta, and xG performance, not market odds. However, it does not state the output format, what happens when no parameters are provided, pagination, or any rate-limit/safety context.
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?
The description is a single tight sentence with no filler, and it front-loads the key deliverable: fair 1X2 and over/under 2.5 probabilities. It is concise and readable, though it could be slightly expanded to include usage context without hurting clarity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
All three parameters are optional and there is no output schema, yet the description does not explain default behavior, response shape, or how to choose among parameters. Given this ambiguity, the description is not complete enough for an agent to invoke the tool confidently in all valid cases.
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 100%, so the parameters date, matchId, and competition are already documented. The description adds no additional parameter semantics beyond the schema. Baseline 3 is appropriate because the schema does the heavy lifting.
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 states a specific resource and output: fair 1X2 and over/under 2.5 probabilities for matches. This clearly differentiates it from sibling tools like lineups, events, xG, or standings, none of which provide odds. The title reinforces the purpose, making the tool's function unmistakable.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is given for when to use this tool versus siblings such as openfoot_matches or openfoot_match_context. It does not mention alternative tools, exclusions, or context for which odds/probabilities would be appropriate. The only implied use is from the name and title.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It adds the useful fact that authentication is not required, but it does not mention that the call is read-only, free of side effects, or how the operational status is represented in the response. Transparency beyond the auth requirement is largely missing.
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 a single sentence that is front-loaded with the core purpose and immediately identifies the key requirement of no authentication. There is no redundancy or filler, and every word earns its place.
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?
For a zero-parameter tool, the description adequately states the purpose and auth requirement. However, because there is no output schema and the description does not explain what a healthy response looks like or how an agent should interpret the result, the definition is not fully complete for an agent making decisions based on the response.
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 zero parameters and schema description coverage is 100%, so there is nothing for the description to explain. The baseline of 4 applies because no parameter documentation is needed for an empty 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 uses a specific verb ('check') with a concrete resource ('operational status of OpenFootAPI'), making the tool's purpose unambiguous. This clearly distinguishes it from sibling data-access tools like openfoot_matches and openfoot_standings, which return domain data rather than service health.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It does not explicitly say to use it as a prerequisite before calling other endpoints, nor does it mention any exclusions. An agent must infer the usage context entirely from the tool name and the phrase 'without authentication.'
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 behavioral disclosure burden. It does reveal that the output is shot-level and enumerates included attributes such as pitch coordinates, shot type, situation, outcome, and cumulative xG. However, it does not describe response structure, availability limitations, or error behavior, making this partial rather than full transparency.
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 a single sentence with no filler, and the core concept 'shot-level Expected Goals data' is front-loaded. The list of included data elements is compact and informative, making the description appropriately sized for the tool's simplicity.
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?
With no output schema and no annotations, the description must supply return-value expectations, and it does enumerate the main fields. However, it omits the exact response shape, how cumulative xG is represented, and any edge-case behavior, so completeness is moderate even for a low-complexity 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 only parameter, matchId, is fully described in the schema as being returned by openfoot_matches, giving 100% schema description coverage. The description itself adds no additional parameter semantics, but the schema already handles this dimension adequately.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly identifies the tool as returning shot-level Expected Goals data with coordinates, shot type, situation, outcome, and cumulative xG, and the title reinforces that this is a match shot map/xG tool. It does not explicitly distinguish itself from siblings like openfoot_league_xg, but the match-specific and shot-level focus is clear.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies this tool is for retrieving shot-level xG data for a specific match, but it never states when to use it versus openfoot_match_events or openfoot_league_xg. There are no explicit when-to-use or when-not-to-use instructions, so the agent must infer usage from the name and description.
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, the description carries the burden and does signal a read-oriented, computed dossier rather than a raw feed. It does not explain whether the dossier is generated on demand, how missing data is handled, or what 'complete' guarantees.
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 one dense sentence that leads with the resource and then gives a concrete list of what the dossier contains. Every phrase adds signal; there is no repetition of the title or schema.
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 is simple (one required parameter, no output schema), and the description compensates by naming the major returned dimensions. It stops short of specifying response shape or value formats, but that is a minor gap for a single-input dossier 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 single matchId parameter is already fully documented in the schema, including its source tool (openfoot_matches). The description adds no parameter-level detail, but none is needed at 100% schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly identifies a match-context dossier resource and enumerates its contents (recent form, Elo delta, rest days, head-to-head, model probabilities), which distinguishes it from lineup/events/xg/odds siblings. It lacks an explicit action verb like 'retrieves' but the title provides the verb.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The phrase 'assembled for analysis' implies the tool's use case, and the listed fields suggest it is the aggregating alternative to narrower match-data tools. However, it never explicitly states when to choose this over openfoot_match_lineups, openfoot_match_xg, or openfoot_matches.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure, but it only adds the word 'confirmed' and lists data categories. It does not mention lineup availability timing, behavior for unconfirmed or postponed matches, or response shape.
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 a single concise phrase that front-loads the key content and contains no filler. Every word adds value.
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 one-parameter read-oriented tool, the description is largely complete and sufficient for correct invocation. Minor gaps such as lineup confirmation timing or response format are not critical given 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?
The single parameter matchId is already fully documented in the schema as the ID returned by openfoot_matches, so the schema provides complete parameter semantics. The description adds nothing further about the parameter, making the baseline 3 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 states exactly what the tool returns: confirmed starting XI, benches, and formations for a match. This clearly differentiates it from sibling tools like openfoot_match_events, openfoot_match_xg, and openfoot_standings.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit when-to-use or when-not-to-use guidance is provided, and no alternatives are named. However, the description makes the purpose obvious enough that an agent can infer when to select this tool over related match-data siblings.
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, the description carries the behavioral burden. It does disclose that the tool returns scores, kickoff times, status, and teams, and that it supports filters. However, it does not mention pagination, default limits, ordering, or any response-level behavior beyond the basic listing semantics.
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 short, front-loaded sentences: the first states the action and output contents, the second lists the filter dimensions. There is no filler or redundant restatement of the tool name.
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 straightforward listing tool with 7 optional parameters and no output schema, the description plus schema covers the essentials: what is returned and what can be filtered. It could add ordering/pagination behavior, but the schema documents the limit parameter, so the overall context is mostly complete.
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 already covers 86% of parameters with clear descriptions and examples. The description's mention of filtering by competition, team, status, date, or season maps to existing schema fields but adds no new semantic detail beyond that mapping.
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 ('List') with a clear resource ('matches') and enumerates the returned data (scores, kickoff times, status, teams) plus filter dimensions. This clearly distinguishes it from siblings like openfoot_standings, openfoot_match_lineups, and openfoot_competitions.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Usage is implied rather than explicit: the agent can infer this tool is for listing fixtures/results and filtering them. However, it does not mention when to prefer alternatives such as openfoot_search or a match-detail sibling, nor does it state any exclusions.
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 transparency burden. It does disclose the output nature: a timeline of goals, cards, substitutions, VAR checks, and live commentary. But it doesn't mention edge cases, response format, match-status behavior, or whether the data is read-only, though 'Get' and 'Timeline' imply a non-destructive read.
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?
One sentence with zero filler. It front-loads the main purpose and then enumerates concrete contents, making it easy for an agent to parse quickly.
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 is simple: one required parameter, no output schema, no nested objects. The description provides enough context to know what data will be returned and when to use it. The only minor gap is the lack of any detail about the response envelope or ordering guarantees, but 'Timeline' sufficiently implies chronological order.
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 100%: the single matchId parameter is fully documented by the schema with a useful origin hint ('returned by openfoot_matches'). The tool description adds no parameter-specific meaning, but none is necessary given the schema's clarity.
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 resource and outcome: 'Timeline of events in a match' followed by concrete event types. This clearly distinguishes the tool from siblings like match_lineups, match_xg, and match_context, which cover different aspects of a match.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description makes it clear that this tool is for match events and commentary, so the usage context is implied. However, it does not explicitly state when not to use it or name an alternative for other match-related data, leaving some routing up to the agent.
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 full behavioral burden. It does disclose the core return content (ranking dimensions), but it omits behavioral details such as what happens when season is omitted, whether data availability varies by league, or how invalid league codes are handled. The read-only nature is only implied by the name 'get' and the word 'analytics.'
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?
A single sentence that front-loads the scope ('Season-level... for a league') before enumerating the four output dimensions. Every phrase earns its place; there is no repetition of the title or filler.
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 2-parameter tool with 100% schema coverage, the description is largely complete: it substitutes for the missing output schema by naming the return dimensions. The only notable gaps are the unstated season-default behavior and the absence of explicit guidance distinguishing it from the match-level xg tool, which are minor given the tool's low complexity.
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 100%: both 'league' (with example codes) and 'season' (with format example) are already documented in the input schema. The description adds no parameter-specific guidance beyond what the schema provides, so the baseline of 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?
The description states a specific resource (Expected Goals analytics), a precise scope (season-level, league-wide), and the output contents (teams ranked by xG generated, conceded, over/underperformance, shot efficiency). The 'Season-level' and 'for a league' framing clearly differentiates it from the match-level xg sibling, openfoot_match_xg.
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 context for when to use this tool is clear: 'Season-level' signals aggregate league analytics rather than single-match data, which distinguishes it from openfoot_match_xg and openfoot_matches. However, it does not explicitly name alternatives or state when not to use it, so it falls one step short of the explicit-routeing bar.
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, the description carries full behavioral burden. It discloses fuzzy matching and canonical-ID output, which covers the essential behavior. It does not mention result limits, multiple-match handling, or empty results, but those are minor 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?
A single, front-loaded sentence with no filler. Every word contributes meaning: search, teams/competitions, fuzzy name, canonical IDs.
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 two-parameter search tool with thorough schema coverage, the description adequately communicates the task and return concept. It lacks detail on pagination or result limits, but this is a minor gap with no output schema required.
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 100%, and both parameters have useful descriptions with examples. The description adds context around fuzzy matching and canonical IDs, but the schema already handles parameter meaning, so the baseline of 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?
States a specific action (search), specific resources (teams or competitions), and the outcome (canonical OpenFootAPI IDs). This clearly differentiates it from sibling tools that consume IDs for matches, standings, or odds.
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 clearly implies when to use the tool: when you need to resolve a fuzzy team/competition name into a canonical ID. It does not explicitly list alternatives, but the purpose is specific enough that the intended use case is obvious.
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 and delivers useful behavioral context by specifying exactly what data the tool returns. It does not mention what happens when 'season' is omitted or when standings data is unavailable, but the read-only nature is clear from 'Get'.
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?
A single, front-loaded sentence states the action and resource, followed by a compact list of valuable return fields. There is no filler, repetition, or unnecessary detail.
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 read-only tool with no output schema, the description adequately describes the principal return content and scope. Minor gaps include not explaining how competition IDs are obtained and not specifying the default season behavior, but the schema examples and simple scope keep it largely complete.
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%, so the baseline is 3 because both parameters are already documented with examples. The description adds no new parameter semantics beyond confirming that standings relate to a competition, which is adequate given the schema's clarity.
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 a clear resource 'league table for a competition', then enumerates the exact columns returned (rank, points, played, goals, form). This makes it easy to distinguish from sibling tools like openfoot_matches or openfoot_league_xg.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies this tool is for retrieving full league standings for a competition, and the required 'competition' parameter reinforces that. However, it does not explicitly mention when not to use it or compare it to alternatives such as openfoot_league_xg, openfoot_competitions, or openfoot_search.
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 full burden of behavioral disclosure. It clearly frames the operation as a read-only 'check' and specifies the exact information returned, including reset date. It does not explicitly state that the call does not consume quota or describe error/authentication behavior, but for a no-parameter status endpoint the description is reasonably 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 a single sentence that front-loads the action and resource ('Check your API key's tier'), then enumerates the return values clearly. There is no filler, repetition, or unnecessary detail.
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 no-parameter quota tool, the description covers what it does and what it returns, and the sibling list makes the distinction from data tools clear. It is slightly incomplete in that it does not state when to check quota or whether the operation is free of quota impact, but these are minor gaps for this tool shape.
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 tool has zero parameters and the schema reflects that with 100% coverage, so there is no parameter documentation burden on the description. The description correctly implies that no inputs are needed by focusing entirely on what the call reports. This meets the baseline for a no-parameter tool.
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 ('Check') and identifies the exact resource (API quota) and the concrete data points returned: tier, monthly allowance, requests used, and reset date. This clearly distinguishes it from the sibling data-fetching tools, all of which are about football content rather than account/API status.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The intended use is implied: call this tool to inspect API quota and usage. However, there is no explicit guidance on when to use it versus alternatives, no mention of prerequisites such as authentication, and no statement about whether it should be called before other operations. The context makes the distinction obvious but the description does not state it.
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 full burden. It discloses the output fields (IDs, country codes, tiers, provider coverage), informing the agent about return behavior. However, it does not mention pagination, authentication, or data freshness; for a simple read-only list operation this is a minor gap.
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 with no filler. The first sentence front-loads the function and output attributes; the second adds usage guidance. Every clause earns its place.
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 no-argument list tool with no output schema, the description is complete: it names the resource, lists the returned fields, and positions the tool in the workflow with 'Use this first.' Nothing an agent needs to call it correctly is missing.
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?
With zero parameters and 100% schema coverage, there are no parameter semantics to explain. The description adds value by explaining how to use the results (to obtain a valid competition ID), effectively covering the input-less invocation. The baseline for 0 params is 4.
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 the verb 'List' with a specific resource, 'competitions OpenFootAPI supports,' and enumerates the returned attributes (IDs, country codes, tiers, provider coverage). It also identifies itself as the source for valid competition IDs, distinguishing it from sibling tools like openfoot_matches and openfoot_standings.
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 second sentence provides explicit guidance: 'Use this first when you need a valid competition ID.' This tells the agent when to invoke this tool relative to others. It does not name alternatives or when-not-to-use cases, but for a zero-parameter list endpoint this is sufficient context.
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:

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

Score Badge

Copy to your README.md:

[![openfoot-mcp MCP server](https://glama.ai/mcp/servers/bartokulus/openfoot-mcp/badges/score.svg)](https://glama.ai/mcp/servers/bartokulus/openfoot-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/bartokulus/openfoot-mcp'

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