Fantasy Premier League MCP Server

Server Quality Checklist

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

Latest release: v1.0.3
Disambiguation3/5
Tools are mostly distinct but there is clear overlap between fpl_get_manager_squad and fpl_get_manager_by_team_id, which are described as providing the same functionality. Also fpl_get_manager_gameweek_team overlaps partially. This creates ambiguity for an agent.
Naming Consistency4/5
All tools use the 'fpl_' prefix and mostly follow verb_noun pattern. However, inconsistencies exist: fpl_get_manager_by_team_id is verbose and uses a different structure, while fpl_get_manager_squad vs fpl_get_manager_by_team_id are inconsistent naming for same functionality.
Tool Count4/5
19 tools is on the higher side for an MCP server, but the domain of FPL is complex and warrants many tools. Some redundancy (e.g., duplicate squad tools) could be reduced, but overall the count is reasonable.
Completeness4/5
The server covers a wide range of FPL analysis needs: player info, fixtures, transfers, rivalries, leagues, captaincy. Missing write operations (e.g., making transfers) but that's acceptable for an analysis tool. Minor gap: no explicit chip recommendation tool beyond captain.
Average 4.3/5 across 19 of 19 tools scored. Lowest: 3.5/5.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 0 commits in the last 12 weeks
- Last stable release on February 20, 2026
- 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?
Annotations already indicate read-only, non-destructive, idempotent behavior. The description adds context about return format ('str: Detailed rival analysis and threat assessment') and error handling, but does not disclose additional behavioral traits beyond what annotations provide.
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 well-structured with sections (Args, Returns, Examples, Error Handling) and is concise given the tool's complexity. Every section serves a purpose without unnecessary verbosity.
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 read-only analysis tool, the description covers parameters, return type, and error handling. It lacks explicit mention of rate limits or data freshness, but given the annotations and schema richness, it is sufficiently complete for an AI agent to use.
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 provides descriptions for all parameters (my_team_id, rival_team_id, gameweek, response_format), so the description's list of args adds little new semantic value. The examples provided are a minor addition, but overall the description largely restates schema information.
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 'Compare your team against a specific rival manager' and lists specific analysis features (points, rank, chips, captaincy, differentials), which distinguishes it from siblings like fpl_compare_managers.
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 explicit guidance on when to use this tool versus alternatives such as fpl_compare_managers. The description only mentions what it does, not when it is preferred or not.
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?
Annotations already indicate readOnlyHint=true, destructiveHint=false, idempotentHint=true, openWorldHint=true. The description adds behavioral context beyond annotations by detailing what the comparison shows (differences, common players, differentials) and error handling. No contradiction with annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with clear sections (purpose, args, returns, examples, error handling). It is front-loaded with the main purpose. However, the 'Args' section is somewhat redundant with the schema, making it slightly verbose but not excessive.
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 description covers the tool's functionality, parameters with examples, and error handling. Although the output schema exists (not shown), the description provides a high-level return type. The description is adequate for the tool's complexity, though output format could be more detailed.
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 descriptions already cover all parameters (manager_names, league_id, gameweek) with clear text. The description's 'Args' section mostly repeats this information, adding minimal additional meaning. Given schema coverage is effectively 100%, baseline is 3.
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 compares multiple managers' teams for a specific gameweek side-by-side and lists specific outputs (player selection, captaincy, points, common players, differentials). This distinguishes it from sibling tools like fpl_compare_players or fpl_get_manager_gameweek_team.
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 mentions 'useful for mini-league rivalry analysis and understanding what sets top managers apart' but does not explicitly state when not to use or provide alternatives. The guidance is implied but not explicit, missing a clear exclusion or comparison to related 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?
The annotations indicate readOnlyHint=true, destructiveHint=false, idempotentHint=true, and openWorldHint=true, and the description does not contradict any of these. It adds useful behavioral context, such as error handling details and that it returns a formatted string, which goes beyond annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-organized into sections (Args, Returns, Examples, Error Handling) but is somewhat verbose. For a tool with one parameter, it could be more concise. Each section adds value, but there is redundancy (e.g., examples repeated in Args and separate Examples section).
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?
The description mentions that the return value is a string with comprehensive information, but lacks detail on the format or structure. Given the tool has one parameter and good annotations, this is adequate but not exceptional. The lack of an output schema in the provided context (though signaled as present) limits completeness assessment.
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 provides a clear description and examples for the single parameter `player_name`. The tool description repeats these examples in the 'Args' section without adding new semantic information beyond what the schema offers. Baseline of 3 is appropriate given full 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 explicitly states 'Get comprehensive information about a specific Fantasy Premier League player.' This is a specific verb+resource combination, and it distinguishes from sibling tools like `fpl_find_player` by noting it is the 'most comprehensive player 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?
The description includes an 'Error Handling' section that suggests using `fpl_find_player` if the name is ambiguous, providing clear guidance on when to use an alternative. It also implies this is the go-to for detailed player info. However, it does not explicitly state when not to use this tool.
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?
Annotations already declare readOnlyHint=true and idempotentHint=true, indicating safe reads. The description adds value by revealing the analytical inputs (fixtures, form, home/away advantage) and the decision logic, going beyond mere safety traits. No contradictions with annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured: a concise purpose statement, followed by details, parameter explanations, return type, examples, and error handling. Each part contributes meaningfully, and the key information is front-loaded. Slightly longer than necessary due to repeated parameter descriptions, but overall 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?
The description covers all essential aspects: purpose, parameter behavior (with vs. without team_id), return format (top 3-5 recommendations with analysis), and error handling. Since an output schema exists, the return value description is sufficient. For a tool with three parameters and conditional logic, the description is fairly 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 input schema already provides clear descriptions for each parameter (team_id, gameweek, response_format), so the description adds marginal value by restating them with examples. The baseline is 3 given high schema coverage; the examples slightly improve clarity but do not introduce new semantics 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 the verb 'Get' and the resource 'captaincy recommendations' for the upcoming gameweek. It distinguishes this tool from sibling tools like fpl_analyze_rival or fpl_analyze_team_fixtures by focusing exclusively on captain picks.
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 explains when to provide a team_id for personal recommendations versus when to use it for general picks. It includes examples for both cases and mentions error handling for invalid gameweek or team ID, but does not explicitly state when not to use the tool or contrast with 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?
Annotations indicate readOnlyHint=true, destructiveHint=false, idempotentHint=true, openWorldHint=true. The description adds value by detailing error handling (player not found, different positions, API failure) and the output format (detailed analysis and recommendation). This goes beyond the annotations.
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 well-structured with clear sections for purpose, args, returns, examples, and error handling. It is concise with no unnecessary words, front-loaded with the main action.
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 annotations and the presence of an output schema (string), the description provides sufficient detail including examples and error handling. It covers all necessary aspects for an agent to use the tool correctly.
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 includes descriptions for each parameter (player_out, player_in, my_team_id, response_format), so the schema coverage is high. The description adds examples and explains the optional my_team_id and response_format, but does not add significant new 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?
The description clearly states it analyzes a potential transfer decision between two players, comparing form, upcoming fixtures, price difference, and value, and provides a direct recommendation. This distinguishes it from sibling tools like fpl_compare_players which likely just compare stats without the transfer context.
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 indicates to use when considering a transfer between two players, with examples like player_out='Salah', player_in='Palmer'. It does not explicitly mention when not to use or alternatives, but the context is clear. Sibling tools like fpl_compare_players could be an alternative for simple stat comparison, but not mentioned.
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?
Annotations already declare readOnlyHint and idempotentHint, indicating a safe read operation. The description adds value by explaining the behavior: returns active or upcoming gameweek, and details error cases. No contradiction with annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-organized with sections for Args, Returns, Examples, and Error Handling. It is informative without being overly verbose, though the error handling details could be condensed for even greater conciseness. This is a minor nuance.
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 (one parameter, read-only, output schema exists), the description is complete. It covers what the tool does, how to use it, return information, and error scenarios. No gaps are apparent.
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 description thoroughly documents the single parameter (response_format), including default and possible values ('markdown' or 'json') with examples. Although the input schema also provides descriptions, the description enhances understanding with practical usage guidance beyond schema metadata.
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 retrieves 'the current or upcoming Fantasy Premier League gameweek information.' It specifies the exact resource (gameweek) and the verb (get), and distinguishes itself from sibling tools like fpl_get_fixtures_for_gameweek by focusing on the overall gameweek state rather than fixtures or manager data.
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 says it's 'Essential for determining which gameweek to plan transfers for and understanding the current state of the season,' providing context for use. However, it does not explicitly compare with alternatives or specify when not to use this tool (e.g., when fixture details are needed instead). The guidance is implied but not comprehensive.
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?
Annotations already declare readOnlyHint=true, destructiveHint=false, idempotentHint=true. The description adds context about half-season chips but no additional behavioral traits (e.g., auth needs, rate limits). It does not contradict annotations.
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 well-structured with clear sections (Args, Returns, Examples, Error Handling). It is concise yet comprehensive, with 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?
Given the tool's simplicity (one input object with two fields) and the presence of an output schema, the description fully covers what the agent needs to know. Examples and error handling are included.
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 already provides descriptions for both parameters (team_id and response_format). The description adds value by including examples and error handling, which goes 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 states the tool retrieves a manager's chip usage, distinguishing it from sibling tools that handle other FPL data. The verb 'get' and the specific resource 'manager chips' make the purpose explicit.
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 implies usage for strategic chip planning and provides examples, but lacks explicit when-not-to-use or alternatives. It is helpful but not fully comprehensive.
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?
Annotations already declare readOnlyHint=true and idempotentHint=true. The description adds value by noting potential delays, error handling for missing data, and API failure handling, which are beyond the annotations.
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 well-structured with sections (Purpose, Args, Returns, Examples, Error Handling, Note) and front-loaded. It is slightly verbose but every sentence 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?
Given the tool's moderate complexity (API calls, error handling, delay), the description covers usage, parameters, return format, and edge cases. The output is a string, which is sufficiently explained.
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?
Despite schema description coverage being 0% per context, the actual schema has descriptions for both parameters. The description adds usage examples and default values, enhancing clarity 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 'Get top 10 Fantasy Premier League performers over recent gameweeks', specifying verb, resource, and scope. It distinguishes from sibling tools like fpl_find_player and fpl_get_player_details by focusing on aggregate metrics.
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 says 'Perfect for identifying in-form players for transfers', providing clear context for when to use. However, it lacks explicit 'when not to use' or 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?
Annotations already declare readOnlyHint, idempotentHint, etc. Description adds behavioral details like '2-5 players', stats, prices, form, and error handling. No contradiction with annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Well-structured with sections for overview, args, returns, examples, error handling. Not overly verbose, though slightly repetitive in error description.
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 one parameter and existing output schema, description covers purpose, parameter details with examples, and error cases. Return format stated. No notable gaps.
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 has descriptions, but coverage is low per context. Description adds usage context, examples (e.g., player_names variations), and constraints (2-5 players), going 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 'Compare multiple Fantasy Premier League players side-by-side' with explicit verb and resource. It distinguishes from sibling tools like fpl_compare_managers by focusing on 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?
Mentions usefulness for transfer decisions, providing clear context. However, lacks explicit when-not-to-use or alternatives like fpl_get_player_details for single player queries.
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?
Annotations already declare readOnlyHint=true and idempotentHint=true, so the description's behavioral context is complementary. It adds details about error handling (returns error if data unavailable) and output format (analysis string), which are useful beyond annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with sections for purpose, arguments, returns, examples, and error handling. It is informative without being verbose, though the Args section could be slightly more compact.
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 (analysis of 20 teams over multiple gameweeks), the description covers all necessary aspects: purpose, parameters, examples, error handling, and output format. Annotations confirm it is read-only and idempotent, and the output schema exists, so no further return details are 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 input schema provides thorough descriptions for all parameters (e.g., num_gameweeks, max_teams, positions). The tool description does not repeat these but adds practical examples (e.g., 'Target next 5 GWs: num_gameweeks=5'), which add usage context 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 the verb (find/analyze/identify/recommends) and resource (teams with easiest upcoming fixtures and best assets). It distinguishes from siblings like fpl_analyze_team_fixtures (specific team) and fpl_get_fixtures_for_gameweek (raw fixtures) by focusing on analysis and recommendations across all teams.
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 clear context for when to use the tool (analyze fixture difficulty for all teams and get recommendations) but does not explicitly mention when not to use it or compare to alternatives. The examples illustrate typical use cases, enhancing clarity.
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?
Annotations indicate readOnlyHint=true and destructiveHint=false, and the description adds that it returns fixture details, scores if finished, difficulty ratings, and error conditions. This goes beyond annotations to disclose behavior like output format options and 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?
The description is structured with sections (main, args, returns, examples, error handling), making it easy to scan. While informative, it could be slightly more concise; however, it remains efficient and front-loads the purpose.
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 annotations (readOnly, idempotent) and output schema presence, the description explains what the tool returns and handles errors. It does not explicitly differentiate from sibling tools but covers the core functionality well. The description is adequate for selecting and using the 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 input schema provides detailed descriptions for all three parameters (gameweek, detailed, response_format), and the description reinforces them with examples and usage notes. The schema descriptions are thorough, so the tool description adds value with examples and error handling context.
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 all Premier League fixtures for a specific gameweek,' specifying the verb (get) and resource (fixtures) with a specific scope. It distinguishes from sibling tools like fpl_analyze_team_fixtures or fpl_get_manager_squad by focusing on raw fixture 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 usage context: 'Useful for planning transfers based on fixture difficulty and understanding upcoming matches.' It includes examples and error handling. However, it does not explicitly state when not to use this tool or compare it to alternatives, which would strengthen the 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?
Annotations already indicate readOnlyHint=true and idempotentHint=true. The description adds that it uses real-time data from bootstrap for instant response and includes error handling for missing data, providing useful behavioral context beyond the annotations.
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 well-structured with paragraphs for overview, args, returns, examples, and error handling. It is slightly verbose but front-loaded with the purpose, making it effective without being wasteful.
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 simple input schema, clear annotations, and the presence of an output schema (string), the description covers all necessary aspects: purpose, parameters, examples, and error handling, making it fully complete for an agent to use.
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?
Although schema description coverage is 0%, the description includes an 'Args' section that details both parameters (limit and response_format) with ranges, defaults, and examples. This adds value beyond the schema's own 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 verb 'Get' and the resource 'most transferred in and out players' for the current gameweek. This distinguishes it from sibling tools like fpl_get_player_details or fpl_compare_players, which focus on different aspects.
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 explains when to use this tool: to identify popular moves and understand the current template. It does not explicitly mention when not to use it or alternatives, but the context is clear enough for an agent to decide.
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?
Annotations show readOnlyHint=true, destructiveHint=false, idempotentHint=true, openWorldHint=true. Description adds useful behavioral details: pagination support, error handling for missing league or invalid page, and response format options.
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?
Well-structured with clear sections: main purpose, args, returns, examples, error handling. Every sentence is informative without redundancy. Front-loaded with core function.
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 (reading standings with pagination), the description covers all key aspects: pagination, error cases, format options, and example usage. Output schema exists but description explains returns adequately.
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 provides descriptions for each parameter (league_id, page, response_format). Description reiterates these and adds examples (e.g., usage with league_id=12345). Since schema coverage is high, baseline is 3, but examples elevate 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 explicitly states 'Get standings for a specific Fantasy Premier League league.' and lists returned data (manager rankings, points, team names, rank changes). It clearly distinguishes from sibling tools like analyze and compare functions.
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 context on usage: supports pagination, how to find league ID from URL, and gives examples. Does not explicitly state when to avoid using this tool, but the purpose is clear and siblings are distinct.
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?
Annotations already declare readOnlyHint=true and idempotentHint=true. Description adds behavioral details: return format (complete transfer history with costs), error handling (invalid team ID, no transfers, API failure). Does not contradict annotations.
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?
Well-structured with sections: main description, usefulness, requirements, args, returns, examples, error handling. Concise and front-loaded: first sentence states core action.
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 two parameters and schema coverage, description covers all necessary aspects: purpose, parameters, return type, error handling, and examples. No gaps identified.
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 descriptions cover both parameters well. Description adds examples (team_id=123456, gameweek=20) and explains how to obtain team_id from FPL URL, providing extra 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 action: 'Get all transfers made by a specific manager in a specific gameweek.' Specifies resource (transfers), constraints (manager and gameweek), and details shown (players in/out, costs, timing). Distinguishes from siblings such as fpl_analyze_transfer and fpl_get_manager_squad by focusing on transfers per gameweek.
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?
Explains usefulness ('analyzing manager strategy') and prerequisite ('Requires manager's team ID (entry ID) which can be found in the FPL URL'). Does not explicitly exclude alternatives or list when not to use, but provides enough context for appropriate selection among siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate read-only, idempotent behavior. The description adds specific behavioral details: fuzzy matching handling, disambiguation for multiple matches, and error handling messages. No contradiction with annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with a lead sentence followed by bullet points for features, args, returns, examples, and error handling. It is informative but slightly verbose; could be more concise without losing key details.
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 (one parameter, fuzzy search), the description covers input format, usage examples, return types, and error handling. An output schema exists, so return details are not needed in text.
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?
Despite reported 0% schema description coverage, the description compensates by explaining the single parameter 'player_name' with an example ('Haalnd' matches 'Haaland'). This adds practical meaning beyond the schema's basic type and constraints.
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 (Find), resource (Fantasy Premier League player), and key feature (intelligent fuzzy matching). It distinguishes from sibling tools like fpl_get_player_details which likely require exact IDs.
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 explains when to use this tool (fuzzy search for names with typos, partial names, nicknames) vs exact search, and mentions disambiguation. It provides clear context but does not explicitly exclude scenarios where exact search is preferred.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description adds significant behavioral context beyond annotations: it details error handling (manager not found, ambiguous names, API failures) and specifies the return format (complete team sheet with statistics). Annotations already indicate this is a safe read operation (readOnlyHint, idempotentHint), but the description enriches with operational details.
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 well-structured with sections for Args, Returns, Examples, and Error Handling. The first sentence states the purpose. While it is somewhat lengthy, every section adds useful information. It could be slightly more concise but is not overly 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 tool with three parameters and an output schema (not shown), the description covers all essential aspects: input parameters, return value description, usage examples, and error scenarios. The output schema exists to provide formal structure, so the description need not detail every field, but it gives a clear overview of what the tool returns.
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 already provides descriptions for all three parameters (manager_name, league_id, gameweek). The tool description repeats this information in an 'Args' block and adds concrete examples showing parameter values, which enhances understanding. Given high schema coverage, the description adds moderate value via examples.
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 a manager's team selection for a specific gameweek.' It specifies what the output includes (15 players, captain, vice-captain, formation, points, transfers, auto-subs) and distinguishes this from sibling tools by focusing on a single manager's gameweek team sheet.
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 explains how to use the tool: find a manager by name or team name within a specific league. It provides examples and prerequisites (league_id, manager_name, gameweek). However, it does not explicitly state when to prefer this over siblings like fpl_get_manager_squad, but the context is clear enough.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description adds behavioral context beyond annotations, including error handling specifics (e.g., returns error if team not found, no upcoming fixtures, data unavailable) and detailed output characteristics (opponent strength, home/away, average difficulty rating). It does not contradict annotations and enriches the agent's understanding.
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 well-structured with clear sections (purpose, args, returns, examples, error handling). Each sentence adds value, and it is front-loaded with the main purpose. Appropriate length for the tool's complexity.
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 has an output schema (not shown), the description still covers key return elements (opponent strength, home/away, rating) and error conditions. It is complete for an agent to understand inputs, outputs, and failure modes.
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?
Despite schema description coverage being 0% (the top-level params parameter lacks schema description), the tool description compensates by thoroughly documenting parameters: team_name with examples, num_gameweeks with range and default, response_format with options and default. It adds examples and error handling, providing meaning beyond the schema's property 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 purpose: 'Analyze upcoming fixtures for a specific Premier League team to assess difficulty.' It specifies the output (next N gameweeks, opponent strength, home/away, average difficulty rating) and distinguishes implicitly from siblings like fpl_find_fixture_opportunities which focus on cross-team opportunities.
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 when to use: 'Very useful for identifying good times to bring in or sell team assets based on fixture difficulty.' It provides clear context but does not explicitly mention when not to use 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.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations declare readOnlyHint=true, destructiveHint=false, idempotentHint=true. Description adds detailed behavioral context: shows 15 players, captain, formation, points, substitutions, and error handling conditions. No contradiction with annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Well-structured with separate sections for Args, Returns, Examples, Error Handling. Every sentence adds value. Front-loaded with core purpose.
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 annotations (rich), output schema present, and description covers purpose, usage, parameters, examples, and error handling, it is fully complete for an AI agent to correctly invoke the 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?
Despite schema description coverage being 0%, the description fully explains each parameter (team_id, gameweek, response_format) with types, defaults, and purpose, plus examples. Compensates for missing 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?
Clear verb+resource+method: 'Get a manager's squad selection for a specific gameweek using their team ID.' Distinguishes from sibling tool fpl_get_manager_gameweek_team by noting it's a simpler alternative using team ID directly.
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 contrasts with sibling tool for when to use this tool (team ID available vs need manager name/league lookup). Provides examples but lacks explicit '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.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, destructiveHint, idempotentHint, and openWorldHint. The description adds behavioral details such as showing '15 players picked, captain/vice-captain choices, formation, points scored, transfers made, and automatic substitutions.' It also explains error conditions. No contradiction with annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with sections: main purpose, functionality, args, returns, examples, and error handling. Every sentence is informative and no redundancy. Front-loaded with the core purpose.
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 rich annotations and output schema, the description covers all necessary aspects: purpose, parameters, usage, examples, and error cases. It is fully complete for a read-only, idempotent tool with open world semantics.
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 already has descriptions for team_id, gameweek, and response_format, so schema coverage is effectively 100% (despite the context signal indicating 0%, which seems inconsistent). The description adds value by explaining defaults ('defaults to current GW') and providing examples, but the schema alone is sufficient.
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 manager profile and squad information using team ID directly,' with a specific verb and resource. It distinguishes itself from the sibling tool fpl_get_manager_squad by noting it has a 'name that better reflects its purpose' and that it works without league context.
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 'without requiring league context,' contrasting with fpl_get_manager_squad. It provides examples for different gameweeks and output formats, and mentions error handling for invalid team IDs or gameweeks not started.
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:

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

Score Badge

Copy to your README.md:

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

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/nguyenanhducs/fpl-mcp-server'

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