Provides tools for analyzing Fantasy Premier League data, including player search, fixture analysis, manager comparison, transfer tracking, and strategy prompts.
Click on "Install Server".
Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state.
In the chat, type @ followed by the MCP server name and your instructions, e.g., "@Fantasy Premier League MCP Server show me the best captain pick for gameweek 6"
That's it! The server will respond to your query, and you can continue using it as needed.
Here is a step-by-step guide with screenshots.
A comprehensive Model Context Protocol (MCP) server for Fantasy Premier League analysis and strategy. This server provides AI assistants with powerful tools, resources, and prompts to help you dominate your FPL mini-leagues with data-driven insights.
This MCP server provides comprehensive FPL analysis capabilities through:
19 Interactive Tools - Search players, analyze fixtures, compare managers, track transfers, and more
4 Data Resources - access to players, teams, gameweeks, and current gameweek bootstrap data
10 Strategy Prompts - Structured templates for gameweek analysis, squad analysis, transfer planning, chip strategy, lineup selection, and captain selection
Smart Caching - 4-hour cache for bootstrap data to minimize API calls while keeping data fresh
Fuzzy Matching - Find players even with spelling variations or nicknames
Live Transfer Trends - Track the most transferred in/out players for current gameweek
Manager Insights - Analyze squads, transfers, and chip usage
Fixture Analysis - Assess team fixtures and plan transfers around favorable runs
Related MCP server: FPL MCP Server
The fastest way to get started - no installation required:
{
"mcpServers": {
"fpl": {
"command": "uvx",
"args": ["fpl-mcp-server"],
"type": "stdio"
}
}
}Use the official Docker image from GitHub Container Registry:
{
"mcpServers": {
"fpl": {
"command": "docker",
"args": [
"run",
"--rm",
"-i",
"ghcr.io/nguyenanhducs/fpl-mcp-server:latest"
],
"type": "stdio"
}
}
}For detailed installation instructions and more options, see Installation Guide.
Once configured, you can interact with the FPL MCP server through Claude Desktop using natural language.
For detailed guidance, see:
Tool Selection Guide - Choose the right tool for your analysis task
This server uses the official Fantasy Premier League API, see here for more details.
We welcome contributions! Please see CONTRIBUTING.md for guidelines.
Compare your team against a specific rival manager.
Provides a comprehensive head-to-head analysis including:
Points and Rank comparison
Chip usage history
Captaincy comparison
Key Differentials (players they own that you don't)
Args: params (AnalyzeRivalInput): Validated input parameters containing: - my_team_id (int): Your team ID - rival_team_id (int): Rival's team ID - gameweek (int | None): Gameweek number (defaults to current)
Returns: str: Detailed rival analysis and threat assessment
Examples: - Compare me vs rival: my_team_id=123, rival_team_id=456 - Analyze past GW: my_team_id=123, rival_team_id=456, gameweek=10
Error Handling: - Returns error if either team ID invalid - Returns formatted error message if API fails
| Name | Required | Description | Default |
|---|---|---|---|
| params | Yes |
| Name | Required | Description |
|---|---|---|
| result | Yes |
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.
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.
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.
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.
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.
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.
Analyze upcoming fixtures for a specific Premier League team to assess difficulty.
Shows next N gameweeks with opponent strength and home/away status. Includes average difficulty rating and assessment. Very useful for identifying good times to bring in or sell team assets based on fixture difficulty.
Args: params (AnalyzeTeamFixturesInput): Validated input parameters containing: - team_name (str): Team name to analyze (e.g., 'Arsenal', 'Liverpool') - num_gameweeks (int): Number of gameweeks to analyze, 1-15 (default: 5) - response_format (ResponseFormat): 'markdown' or 'json' (default: markdown)
Returns: str: Fixture difficulty analysis with ratings and assessment
Examples: - Next 5 fixtures: team_name="Arsenal" - Next 10 fixtures: team_name="Liverpool", num_gameweeks=10 - Long-term view: team_name="Man City", num_gameweeks=15
Error Handling: - Returns error if team not found - Returns error if no upcoming fixtures - Returns formatted error message if data unavailable
| Name | Required | Description | Default |
|---|---|---|---|
| params | Yes |
| Name | Required | Description |
|---|---|---|
| result | Yes |
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.
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.
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.
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.
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.
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.
Analyze a potential transfer decision between two players.
Compares the player being transferred out vs the player being transferred in. Analyzes form, upcoming fixtures (next 5), price difference, and overall value. Provides a direct recommendation based on the data.
Args: params (AnalyzeTransferInput): Validated input parameters containing: - player_out (str): Name of player to remove - player_in (str): Name of player to add - my_team_id (int | None): Optional team ID to check budget impact
Returns: str: Detailed transfer analysis and recommendation
Examples: - Analyze move: player_out="Salah", player_in="Palmer" - Check budget: player_out="Saka", player_in="Foden", my_team_id=123456
Error Handling: - Returns error if either player not found - Returns error if players play different positions (unless specified) - Returns formatted error message if API fails
| Name | Required | Description | Default |
|---|---|---|---|
| params | Yes |
| Name | Required | Description |
|---|---|---|
| result | Yes |
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.
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.
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.
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.
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.
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.
Compare multiple managers' teams for a specific gameweek side-by-side.
Shows differences in player selection, captaincy choices, points scored, common players, and unique differentials. Useful for mini-league rivalry analysis and understanding what sets top managers apart.
Args: params (CompareManagersInput): Validated input parameters containing: - manager_names (list[str]): 2-4 manager names to compare - league_id (int): League ID where managers are found - gameweek (int): Gameweek number to compare (1-38)
Returns: str: Side-by-side manager comparison with differentials
Examples: - Compare 2 managers: manager_names=["John", "Sarah"], league_id=12345, gameweek=13 - Compare 4 managers: manager_names=["A", "B", "C", "D"], league_id=12345, gameweek=10
Error Handling: - Returns error if fewer than 2 or more than 4 managers provided - Returns error if any manager not found (with helpful message) - Returns formatted error message if API fails
| Name | Required | Description | Default |
|---|---|---|---|
| params | Yes |
| Name | Required | Description |
|---|---|---|
| result | Yes |
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.
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.
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.
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.
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.
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.
Compare multiple Fantasy Premier League players side-by-side.
Provides detailed comparison of 2-5 players including their stats, prices, form, and other key metrics. Useful for making transfer decisions.
Args: params (ComparePlayersInput): Validated input parameters containing: - player_names (list[str]): 2-5 player names to compare
Returns: str: Side-by-side comparison of players in markdown format
Examples: - Compare wingers: player_names=["Salah", "Saka", "Palmer"] - Compare strikers: player_names=["Haaland", "Isak"] - Compare for transfers: player_names=["Son", "Maddison", "Odegaard"]
Error Handling: - Returns error if fewer than 2 or more than 5 players provided - Returns error if any player name is ambiguous - Returns formatted error message if API fails
| Name | Required | Description | Default |
|---|---|---|---|
| params | Yes |
| Name | Required | Description |
|---|---|---|
| result | Yes |
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.
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.
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.
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.
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.
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.
Find teams with the easiest upcoming fixtures and their best assets.
Analyzes fixture difficulty for all 20 teams over the next N gameweeks. Identifies teams with the most favorable schedule and recommends their top-performing players (filtered by position if requested).
Args: params (FindFixtureOpportunitiesInput): Validated input parameters containing: - num_gameweeks (int): Number of gameweeks to analyze (3-10) - max_teams (int): Number of teams to recommend (1-5) - positions (list[str] | None): Optional position filter
Returns: str: Analysis of best teams to target and their key players
Examples: - Target next 5 GWs: num_gameweeks=5 - Find best attackers: positions=['Midfielder', 'Forward']
Error Handling: - Returns error if data unavailable - Returns formatted error message if API fails
| Name | Required | Description | Default |
|---|---|---|---|
| params | Yes |
| Name | Required | Description |
|---|---|---|
| result | Yes |
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.
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.
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.
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.
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.
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.
Find a Fantasy Premier League player by name with intelligent fuzzy matching.
Handles variations in spelling, partial names, and common nicknames. If multiple players match, returns disambiguation options. More forgiving than exact search.
Args: params (FindPlayerInput): Validated input parameters containing: - player_name (str): Player name with fuzzy support (e.g., 'Haalnd' matches 'Haaland')
Returns: str: Player details if unique match, or list of matching players if ambiguous
Examples: - Find with typo: player_name="Haalnd" (finds Haaland) - Partial name: player_name="Mo Salah" (finds Mohamed Salah) - Surname only: player_name="Son" (finds Son Heung-min)
Error Handling: - Returns helpful message if no players found - Returns disambiguation list if multiple matches - Returns formatted error message if API fails
| Name | Required | Description | Default |
|---|---|---|---|
| params | Yes |
| Name | Required | Description |
|---|---|---|
| result | Yes |
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.
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.
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.
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.
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.
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.
Get captaincy recommendations for the upcoming gameweek.
Analyzes fixtures, form, and home/away advantage to recommend the best captain choices. If team_id is provided, analyzes YOUR specific squad. Otherwise, provides general recommendations from all players.
Args: params (GetCaptainRecommendationsInput): Validated input parameters containing: - team_id (int | None): Your team ID to analyze your specific squad - gameweek (int | None): Gameweek to analyze (defaults to next)
Returns: str: Top 3-5 captain recommendations with analysis
Examples: - Analyze my team: team_id=123456 - General picks for GW15: gameweek=15 - General picks: (no args)
Error Handling: - Returns error if gameweek invalid - Returns helpful message if team ID not found - Returns formatted error message if API fails
| Name | Required | Description | Default |
|---|---|---|---|
| params | Yes |
| Name | Required | Description |
|---|---|---|
| result | Yes |
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.
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.
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.
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.
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.
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.
Get the current or upcoming Fantasy Premier League gameweek information.
Returns the gameweek that is currently active (before deadline) or the next gameweek (after deadline). Essential for determining which gameweek to plan transfers for and understanding the current state of the season.
Args: params (GetCurrentGameweekInput): Validated input parameters containing: - response_format (ResponseFormat): 'markdown' or 'json' (default: markdown)
Returns: str: Current/upcoming gameweek details with deadline and status
Examples: - Check current GW: response_format="markdown" - Get as JSON: response_format="json"
Error Handling: - Returns error if gameweek data unavailable - Returns error if no active gameweek found - Returns formatted error message if API fails
| Name | Required | Description | Default |
|---|---|---|---|
| params | Yes |
| Name | Required | Description |
|---|---|---|
| result | Yes |
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.
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.
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.
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.
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.
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.
Get all Premier League fixtures for a specific gameweek.
Returns complete fixture list with team names, kickoff times, scores (if finished), and difficulty ratings for both teams. Useful for planning transfers based on fixture difficulty and understanding upcoming matches.
Args: params (GetFixturesForGameweekInput): Validated input parameters containing: - gameweek (int): Gameweek number between 1-38 - detailed (bool): Include detailed stats (default: False) - response_format (ResponseFormat): 'markdown' or 'json' (default: markdown)
Returns: str: Complete fixture list with times and difficulty ratings
Examples: - View GW10 fixtures: gameweek=10 - Check upcoming matches: gameweek=15 - Get as JSON: gameweek=20, response_format="json"
Error Handling: - Returns error if gameweek number invalid (must be 1-38) - Returns error if no fixtures found for gameweek - Returns formatted error message if data unavailable
| Name | Required | Description | Default |
|---|---|---|---|
| params | Yes |
| Name | Required | Description |
|---|---|---|
| result | Yes |
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.
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.
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.
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.
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.
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.
Get standings for a specific Fantasy Premier League league.
Returns manager rankings, points, team names, and rank changes within the league. Supports pagination for large leagues. Find league ID in the FPL website URL (e.g., for /leagues/12345/standings/ use league_id=12345).
Args: params (GetLeagueStandingsInput): Validated input parameters containing: - league_id (int): League ID from FPL URL - page (int): Page number for pagination (default: 1) - response_format (ResponseFormat): 'markdown' or 'json' (default: markdown)
Returns: str: League standings with rankings and pagination info
Examples: - View league: league_id=12345 - Next page: league_id=12345, page=2 - Get as JSON: league_id=12345, response_format="json"
Error Handling: - Returns error if league not found - Returns error if page number invalid - Returns formatted error message if API fails
| Name | Required | Description | Default |
|---|---|---|---|
| params | Yes |
| Name | Required | Description |
|---|---|---|
| result | Yes |
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.
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.
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.
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.
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.
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.
Get manager profile and squad information using team ID directly.
This tool provides the same functionality as fpl_get_manager_squad but with a name that better reflects its purpose - getting manager information without requiring league context. Shows the 15 players picked, captain/vice-captain choices, formation, points scored, transfers made, and automatic substitutions.
Args: params (GetManagerByTeamIdInput): Validated input parameters containing: - team_id (int): Manager's team ID (entry ID) - gameweek (int | None): Gameweek number (1-38), defaults to current GW - response_format (ResponseFormat): 'markdown' or 'json' (default: markdown)
Returns: str: Complete manager profile with squad, statistics, and team info
Examples: - View current squad: team_id=123456 - View specific gameweek: team_id=123456, gameweek=20 - Get as JSON: team_id=123456, response_format="json"
Error Handling: - Returns error if team ID not found (404) - Returns error if gameweek not started yet - Returns formatted error message if API fails
| Name | Required | Description | Default |
|---|---|---|---|
| params | Yes |
| Name | Required | Description |
|---|---|---|
| result | Yes |
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.
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.
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.
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.
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.
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.
Get a manager's chip usage showing which chips have been used and which are still available.
Since the 2025/2026 season, FPL provides 4 chips per half-season.
Shows used chips with gameweek and timing, plus remaining available chips. Essential for strategic chip planning and recommendations.
Args: params (GetManagerChipsInput): Validated input parameters containing: - team_id (int): Manager's team ID (entry ID) - response_format (ResponseFormat): 'markdown' or 'json' (default: markdown)
Returns: str: Chip usage summary with used and available chips
Examples: - Check chip status: team_id=123456 - JSON format: team_id=123456, response_format="json"
Error Handling: - Returns error if team ID invalid - Returns formatted error message if API fails
| Name | Required | Description | Default |
|---|---|---|---|
| params | Yes |
| Name | Required | Description |
|---|---|---|
| result | Yes |
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.
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.
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.
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.
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.
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.
Get a manager's team selection for a specific gameweek.
Shows the 15 players picked, captain/vice-captain choices, formation, points scored, transfers made, and automatic substitutions. Find manager by their name or team name within a specific league.
Args: params (GetManagerGameweekTeamInput): Validated input parameters containing: - manager_name (str): Manager's name or team name - league_id (int): League ID where manager is found - gameweek (int): Gameweek number (1-38)
Returns: str: Complete team sheet with starting XI, bench, and statistics
Examples: - View team: manager_name="John Smith", league_id=12345, gameweek=13 - Check transfers: manager_name="FC Warriors", league_id=12345, gameweek=15
Error Handling: - Returns error if manager not found in league - Returns helpful message suggesting correct name if ambiguous - Returns formatted error message if API fails
| Name | Required | Description | Default |
|---|---|---|---|
| params | Yes |
| Name | Required | Description |
|---|---|---|
| result | Yes |
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.
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.
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.
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.
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.
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.
Get a manager's squad selection for a specific gameweek using their team ID.
Shows the 15 players picked, captain/vice-captain choices, formation, points scored, transfers made, and automatic substitutions. This is a simpler alternative to fpl_get_manager_gameweek_team that uses team ID directly instead of requiring manager name and league ID lookup.
Args: params (GetManagerSquadInput): Validated input parameters containing: - team_id (int): Manager's team ID (entry ID) - gameweek (int | None): Gameweek number (1-38), defaults to current GW - response_format (ResponseFormat): 'markdown' or 'json' (default: markdown)
Returns: str: Complete team sheet with starting XI, bench, and statistics
Examples: - View current team: team_id=123456 - View specific gameweek: team_id=123456, gameweek=13 - Get as JSON: team_id=123456, gameweek=15, response_format="json"
Error Handling: - Returns error if team ID not found - Returns error if gameweek not started yet - Returns formatted error message if API fails
| Name | Required | Description | Default |
|---|---|---|---|
| params | Yes |
| Name | Required | Description |
|---|---|---|
| result | Yes |
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.
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.
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.
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.
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.
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.
Get all transfers made by a specific manager in a specific gameweek.
Shows which players were transferred in and out, transfer costs, and timing. Useful for analyzing manager strategy and understanding when/why they made moves. Requires manager's team ID (entry ID) which can be found in the FPL URL.
Args: params (GetManagerTransfersByGameweekInput): Validated input parameters containing: - team_id (int): Manager's team ID (entry ID) - gameweek (int): Gameweek number (1-38)
Returns: str: Complete transfer history for the gameweek with costs
Examples: - View transfers: team_id=123456, gameweek=20 - Check costs: team_id=789012, gameweek=15
Error Handling: - Returns error if team ID invalid - Returns message if no transfers in gameweek - Returns formatted error message if API fails
| Name | Required | Description | Default |
|---|---|---|---|
| params | Yes |
| Name | Required | Description |
|---|---|---|
| result | Yes |
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.
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.
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.
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.
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.
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.
Get comprehensive information about a specific Fantasy Premier League player.
Returns detailed player information including price, form, team, position, upcoming fixtures with difficulty ratings, recent gameweek performance, popularity, and season stats. Most comprehensive player tool.
Args: params (GetPlayerDetailsInput): Validated input parameters containing: - player_name (str): Player name (e.g., 'Mohamed Salah', 'Erling Haaland')
Returns: str: Comprehensive player information with fixtures, form, and stats
Examples: - Get player info: player_name="Mohamed Salah" - Check fixtures: player_name="Bukayo Saka" - Review form: player_name="Erling Haaland"
Error Handling: - Returns error if player not found - Suggests using fpl_find_player if name is ambiguous - Returns formatted error message if API fails
| Name | Required | Description | Default |
|---|---|---|---|
| params | Yes |
| Name | Required | Description |
|---|---|---|
| result | Yes |
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.
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.
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.
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.
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.
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.
Get top 10 Fantasy Premier League performers over recent gameweeks.
Analyzes player performance over the last N gameweeks and returns the top 10 players for each metric: Goals, Expected Goals (xG), Assists, Expected Assists (xA), and Expected Goal Involvements (xGI). Perfect for identifying in-form players for transfers.
Args: params (GetTopPlayersByMetricInput): Validated input parameters containing: - num_gameweeks (int): Number of recent gameweeks to analyze, 1-10 (default: 5) - response_format (ResponseFormat): 'markdown' or 'json' (default: markdown)
Returns: str: Top 10 players for each metric with their stats and team info
Examples: - Last 5 gameweeks: num_gameweeks=5 - Last 10 gameweeks: num_gameweeks=10 - Get as JSON: num_gameweeks=5, response_format="json"
Error Handling: - Returns error if no finished fixtures in range - Gracefully handles API failures for individual fixtures - Returns formatted error message if data unavailable
Note: This tool might take a few seconds to complete due to the number of data points it needs to process.
| Name | Required | Description | Default |
|---|---|---|---|
| params | Yes |
| Name | Required | Description |
|---|---|---|
| result | Yes |
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.
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.
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.
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.
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.
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.
Get the most transferred in and out players for the current gameweek.
Shows live transfer trends to identify popular moves happening right now. Uses real-time data from bootstrap for instant response. Essential for understanding the current template and finding differentials.
Args: params (GetTopTransferredPlayersInput): Validated input parameters containing: - limit (int): Number of players to return, 1-50 (default: 10) - response_format (ResponseFormat): 'markdown' or 'json' (default: markdown)
Returns: str: Top transferred in and out players with net transfers
Examples: - Top 10: limit=10 - Top 20: limit=20 - Get as JSON: limit=15, response_format="json"
Error Handling: - Returns error if no transfer data available - Returns formatted error message if current gameweek unavailable
| Name | Required | Description | Default |
|---|---|---|---|
| params | Yes |
| Name | Required | Description |
|---|---|---|
| result | Yes |
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
Unclaimed servers have limited discoverability.
If you are the server author, to access and configure the admin panel.
NFL analytics tools for AI agents: stats, fantasy, injuries, schedules, and advanced analysis.
Read-only ESPN, Sleeper, and Fantrax fantasy leagues for Claude, ChatGPT, and other AI tools.
Football fixtures, standings, and odds intelligence for AI agents.
Teamfight Tactics data & AI coaching for Claude and ChatGPT — 19 tools, built-in Riot key.
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
