FPL Intelligence

by dohyung1

Overview Schema Related Servers Score Discussions

Python

Local

Server Quality Checklist

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

Latest release: v0.22.0
Disambiguation4/5
Most tools have distinct purposes, but fpl_manager_hub subsumes many others like transfer_suggestions and squad_scout, causing some overlap. Descriptions help differentiate, but an agent might initially be confused between the hub and specific tools.
Naming Consistency3/5
All tools use snake_case, but naming patterns vary: some are noun_verb (captain_pick, league_analyzer), others noun_noun (chip_strategy, fixture_outlook) or even a question (is_hit_worth_it). While consistent in casing, the lack of a uniform verb_noun pattern reduces predictability.
Tool Count5/5
13 tools cover the major aspects of FPL management without being excessive. Each tool addresses a specific need, and the count is well-scoped for the domain.
Completeness5/5
The tool set covers nearly all common FPL tasks: captain picks, chips, differentials, fixtures, transfers, hits, leagues, live points, player comparisons, price predictions, rivals, and deep scouting. No significant gaps are apparent.
Average 4.3/5 across 13 of 13 tools scored.
See the Tool Scores section below for per-tool breakdowns.
- 0 of 1 community issues answered or closed in the last 6 months
- 0 commits in the last 12 weeks
- Last stable release on March 23, 2026
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI is failing
This repository is licensed under MIT License.
This repository includes a README.md file.
Tools from this server were used 4 times in the last 30 days.
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?
No annotations are provided, so the description carries the burden of disclosing behavior. It lists scoring factors (xG/90, xA/90, etc.) and mentions reasoning. However, it does not state whether the tool is read-only, if it has side effects, or any limitations like data freshness or API dependencies.
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 7 sentences, front-loaded with purpose and usage examples. It is efficient but includes a docstring-style Args section that could be integrated. Still, it avoids unnecessary details.
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 simplicity (1 non-required parameter, no output schema), the description provides essential context: what it does, when to use it, and how scoring works. It could mention that results are read-only, but that is implied.
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 0% description coverage, but the description adds meaning: 'Gameweek number (1-38). Defaults to next gameweek if not specified.' This clarifies the range and default behavior beyond the schema's type and nullability.
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's purpose: 'Get top 5 captain recommendations for a given FPL gameweek.' It uses a specific verb ('Get') and resource ('top 5 captain recommendations') and distinguishes from sibling tools like squad_scout and transfer_suggestions by focusing on captaincy.
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?
Explicitly instructs 'USE THIS WHEN...' with example queries like 'Who should I captain?' and 'Best captain this week?' It covers the typical use cases but does not provide explicit when-not-to-use or alternative tool names.
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 burden. Mentions projecting points over N gameweeks with factors like form, fixtures, home/away, playing chance, and default 5 gameweeks. Does not disclose limitations or edge cases (e.g., what if player is not owned, or if IDs are invalid).
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?
Description is concise, front-loaded with purpose, followed by usage guidance and parameter explanation. No unnecessary sentences.
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 exists, but description fails to mention what the tool returns (e.g., a recommendation string or numeric value). Adequately distinguishes from siblings and explains inputs, but missing output info leaves agent unclear on expected result.
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 0%, but description explains each parameter: player_out_id and player_in_id as FPL element IDs, gameweeks_ahead with range and default. Adds meaning beyond schema's integer type and title.
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 analyzes whether a -4 point hit for a transfer is worth it, using a specific verb and resource, and distinguishes from sibling tools like transfer_suggestions and player_comparison.
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?
Explicitly says 'USE THIS WHEN' with example queries, and advises using player_comparison first to find IDs. Lacks explicit when-not-to-use or alternative tool suggestions.
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 provided, the description carries the full burden. It states the tool's purpose (price prediction) and implications for user actions, but it lacks details on how predictions are made, update frequency, data sources, or any limitations. For a prediction tool, more behavioral context would be beneficial.
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 (3 sentences). The first sentence states the purpose, the second gives usage triggers, and the third provides actionable advice. Every sentence 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.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has no parameters, no annotations, and no output schema, the description is the sole source of information. It covers purpose and usage adequately but fails to describe the output format or any technical details (e.g., whether results are a list, probabilities, etc.). This leaves the agent with incomplete guidance on how to handle the tool's 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 tool has zero parameters, so the description does not need to explain any. Schema coverage is 100%, and the description adds no param-specific info, which is appropriate. Baseline for 0-param tools 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 clearly states the tool predicts which FPL players are likely to rise or fall in price. It uses specific verbs ('predict', 'rise', 'fall') and identifies the resource ('FPL players'). This distinguishes it from sibling tools like transfer_suggestions or squad_scout, which do not focus on price predictions.
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 provides example user queries that should trigger this tool ('Who's about to rise in price?', etc.) and explains the consequence of using it ('Buy before a rise...'), giving clear context. However, it does not mention when not to use the tool or suggest alternatives, which keeps it from a top score.
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 must cover behavioral traits. It states the tool ranks teams by fixture difficulty, which is the core behavior, but does not disclose any additional traits such as data freshness, ranking methodology, or side effects. This is adequate but minimal.
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, with one sentence for the main purpose, a usage guideline section, and clear parameter descriptions. It is front-loaded with the key information and contains no unnecessary 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 the simplicity of the tool (2 parameters, no output schema), the description covers the main functionality and usage context well. It lacks details on the ranking method or output format, but for a straightforward ranking tool, it is mostly complete.
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 schema has 0% parameter description coverage, so the description adds essential meaning. It explains gameweeks_ahead as a range of 1-10 with default 5, and position as a filter with values GKP, DEF, MID, or FWD. This compensates well for the lack of schema descriptions.
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's function: 'Rank all 20 Premier League teams by upcoming fixture difficulty.' This is a specific verb+resource combination that distinguishes it from sibling tools like captain_pick or chip_strategy, which focus on different aspects of FPL.
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 explicit usage guidance by stating 'USE THIS WHEN the user asks: ...' and listing example queries. This gives clear context for when to invoke the tool, though it does not explicitly mention when not to use it or name alternative tools.
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 provided, the description carries full burden for behavioral transparency. It mentions what the tool does (compare squads, find differentials, identify weaknesses, predict transfers, suggest strategies) but lacks details on side effects, authentication needs, or rate limits. The description is adequate but not thorough.
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 concise, using a clear structure with a usage guideline section and parameter explanations. It avoids unnecessary fluff, though the 'Args:' section could be formatted more cleanly. Overall, it earns its length.
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 complexity (multiple analysis aspects) and lack of output schema, the description covers the main purpose, usage triggers, and parameter details. It does not describe the return format or depth of analysis, but it is sufficient for an AI agent to select and use the tool correctly.
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?
The input schema has 0% description coverage, so the description must compensate. It provides clear, actionable guidance for each parameter: league_id is explained with an example URL format, and team_id is described as 'the number in your FPL URL'. This fully explains the parameters beyond the schema titles.
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's purpose: analyzing mini-league rivals and providing strategies. It uses specific verbs ('analyze', 'get strategies') and distinguishes itself from sibling tools like 'league_analyzer' by focusing on rivals and actionable counter-strategies.
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 lists example user queries that trigger this tool, providing clear usage context. It also specifies required inputs (league_id, team_id) and explains where to find them. However, it does not mention when NOT to use it or alternative tools for similar tasks.
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, and the description does not explicitly state the tool is read-only or non-destructive, though it is implied by the query nature.
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, front-loaded with usage guidance, and contains no unnecessary 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?
Covers purpose, parameters, and usage, but missing explicit return value description; acceptable as it is a finding tool.
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?
Both parameters are described with defaults and usage context within the description, fully compensating for the 0% schema description coverage.
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 finds underowned FPL players outperforming ownership, distinguishing it from sibling tools like captain_pick or transfer_suggestions.
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 USE THIS WHEN examples and default values, but could be improved by specifying 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.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description discloses the factors considered (points gap, squad quality, chips, etc.) and that it doesn't require team ID, but lacks details on output format or any limitations, and there are no annotations to provide additional context.
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, well-structured with purpose, usage guidance, and args clearly separated. Every sentence contributes meaning 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 tool with one simple parameter and no output schema, the description covers purpose, usage, and parameter meaning adequately. Missing details on the format of the prediction output, but overall sufficient.
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?
The schema has zero description coverage for the single parameter, but the description fully explains the 'league_id' parameter, including where to find it in the URL, adding significant value beyond the bare 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 explicitly states it predicts mini-league winners based on specific factors, lists example user queries, and implicitly distinguishes from sibling tools by noting it doesn't require a team ID.
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 explicit usage triggers like 'USE THIS WHEN the user asks...' and clarifies that no team ID is needed, but does not mention when not to use or suggest 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?
No annotations are provided, so description carries burden. It mentions fuzzy matching and lists output metrics, but does not disclose error handling for invalid names, rate limits, or side effects. Safe operation is implied but not explicit.
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, front-loaded with purpose, and includes usage, behavioral notes, and parameter details in a single well-structured paragraph with no waste.
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 comparison tool with fuzzy matching and multiple outputs, the description covers purpose, usage, parameters, and output list without an output schema. It is mostly complete, though could mention error cases for invalid inputs.
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?
Schema description coverage is 0%, but the description fully compensates by detailing player_names as a list of 2-4 names with fuzzy matching, and gameweeks_ahead as fixture count (1-10, default 5), significantly adding value beyond the bare 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 compares 2-4 FPL players head-to-head across key metrics, using specific verbs like 'Compare' and listing metrics. It distinguishes from siblings by focusing on head-to-head comparison versus other tools like captain_pick or differential_finder.
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 provides usage triggers with examples like 'Salah vs Palmer?' and 'Which midfielder should I pick?', and mentions fuzzy matching. However, it does not explicitly state when not to use it or compare with siblings.
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 fully bears the burden of disclosure. It details auto-detection of available chips, handling of mid-season resets, and scanning the next 10 gameweeks for scoring—transparency beyond a basic 'recommend' statement.
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: three sentences plus example usage. It front-loads the core purpose, then immediately provides usage guidance and parameter info without any redundant or filler content.
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 moderate complexity (auto-detection, scoring over 10 weeks), the description covers the main behavioral aspects and usage context. However, it lacks details on the output format or any edge cases, which would be beneficial but not critical.
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 only defines team_id as an integer with no description. The tool description adds semantic value by explaining 'team_id: FPL team ID (the number in your FPL URL),' which clarifies how to obtain and use the 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 explicitly states 'Recommend when to use each remaining FPL chip for maximum impact,' providing a clear verb+resource purpose. This tool is distinct from siblings like captain_pick or fixture_outlook, as no other tool covers chip strategy.
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 includes a 'USE THIS WHEN' section with example user queries, making the usage context very clear. However, it does not explicitly mention when not to use this tool or name alternative siblings, which prevents a top score.
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?
Without annotations, the description fully discloses that it auto-detects bank balance, free transfers, chips, and squad, and runs all analyses in parallel. It explains the purpose of the 'gameweeks_ahead' parameter. It does not mention side effects or rate limits, but for a read-only FPL tool, 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.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is efficient: front-loaded with key emojis and bold text, uses two short paragraphs, and includes arg details. Minor redundancy with ALL CAPS but overall well-structured.
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 complexity as a hub that runs multiple analyses, the description provides adequate context: what it does, when to use it, and parameter details. It does not specify output format, but the scope is clear for a starting point tool.
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?
The description adds significant meaning beyond the schema: it explains how to obtain the team_id from the FPL URL and defines the range for gameweeks_ahead (1-10). Since schema description coverage is 0%, the 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?
The description clearly states 'Complete FPL intelligence report for a manager's team' and distinguishes itself from siblings by declaring it 'THE BEST STARTING POINT' and listing the analyses it runs in parallel (captain pick, transfers, etc.), which are sibling tool names.
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?
It explicitly advises to 'USE THIS FIRST when the user provides their team ID or asks for a full analysis', giving clear context for when to use. It does not explicitly list when not to use or name alternatives, but the guidance is strong.
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 discloses that the tool gets live points, mentions auto-subs and bonus points, and specifies the temporal constraint (active gameweek). This provides good behavioral context beyond just the name.
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 brief (3 sentences) and well-structured with a clear purpose line, usage section, and parameter definition. Every sentence adds value with no redundancy.
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 the tool's simplicity (1 param, no output schema), the description is fully complete. It covers what the tool does, when to use it, and what the parameter means. No additional context is needed.
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 only parameter team_id is described with its meaning: 'FPL team ID (the number in your FPL URL).' The schema has no description, so the description adds significant value by explaining what the integer represents and how to find it.
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 'Get live points for a specific FPL team during an active gameweek.' It provides specific verb and resource, and gives examples of user queries that trigger its use. It distinguishes itself from sibling tools by focusing on live gameweek 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 explicitly says 'USE THIS WHEN' with concrete examples like 'How's my team doing?'. It also implies when not to use by stating 'Only useful during an active gameweek'. No explicit alternatives among siblings are listed, but the context is clear.
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 description carries full burden. It describes input parameters but does not specify what the output contains (e.g., list of players, expected points, costs). It does not mention read-only nature, permissions, or rate limits. Adequate but lacks detail on return value.
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?
Description is front-loaded with purpose, then usage guidance, then parameter details. Every sentence is informative and necessary. No redundancy or fluff. Length is appropriate for the tool's complexity.
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 there is no output schema, description covers purpose, usage, and parameters well but omits description of the output format (e.g., what recommendations look like). For a tool returning suggestions, this is a notable gap. Otherwise complete for the simple parameter set.
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?
Schema has 0% description coverage, but description compensates fully. It explains team_id as 'the number in your FPL URL', free_transfers as 'Number of free transfers available (1 or 2)' with default, and bank with example 'e.g. 1.5 means 1.5m' and defaults. Provides meaningful context 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?
Description clearly states 'Get transfer recommendations for a specific FPL team' with explicit verb and resource, and gives example user queries. It distinguishes from sibling tool fpl_manager_hub by recommending it for full analysis.
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 ('USE THIS WHEN the user asks...') and provides specific example queries. Also advises preferring fpl_manager_hub for a full analysis, offering a clear when-not guideline.
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 explains the kind of data returned (blank GW warnings, FPL's expected points, ICT breakdown, etc.) but does not mention any side effects, safety, rate limits, or potential errors.
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 and well-structured. It uses a clear opening line, usage guidelines, a bullet list of surfaced insights, and a parameter explanation. Every sentence adds value.
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 the tool's complexity and the absence of an output schema, the description comprehensively covers purpose, when to use, what data it surfaces, and the parameter description. It provides enough context for an AI agent to select and invoke correctly.
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?
The only parameter, team_id, has no description in the schema. The description adds meaningful context: 'FPL team ID (the number in your FPL URL)'. This fully compensates for the 0% schema coverage.
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's a 'Deep scout report' using hidden FPL data and lists specific insights (blank GW warnings, expected points, set piece duties, etc.). It differentiates from sibling tools by mentioning it goes beyond what fpl_manager_hub provides.
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 says 'USE THIS WHEN' and provides example user queries ('Any hidden insights?', 'Set piece takers?', etc.). It also hints at when not to use by contrasting with fpl_manager_hub.
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:

[![x402-fpl-api MCP server](https://glama.ai/mcp/servers/dohyung1/x402-fpl-api/badges/card.svg)](https://glama.ai/mcp/servers/dohyung1/x402-fpl-api)

Score Badge

Copy to your README.md:

[![x402-fpl-api MCP server](https://glama.ai/mcp/servers/dohyung1/x402-fpl-api/badges/score.svg)](https://glama.ai/mcp/servers/dohyung1/x402-fpl-api)

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/dohyung1/x402-fpl-api'

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