Skip to main content
Glama
bsovs

FPL Strategy MCP

by bsovs
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Python
Hybrid

fpl_recommend_moves

Return legal FPL transfer moves for the current gameweek, using your squad, chips, and signals to rank hold, transfer, and chip options with reasoning and risk.

Instructions

Return legal FPL transfer moves for the current gameweek using the frozen champion strategy by default. Give a full 15-player current squad. buyable_players is optional: when omitted, the server loads the full current official player pool from the cached bootstrap snapshot/API. Give point-in-time signals or enable auto_official_signals, bank/free transfers, unused chips, and optional mini-league standings context. The default champion ranks hold and legal free transfers; explicit hybrid challengers can rank Wildcard, Free Hit, Bench Boost, and Triple Captain when model-backed. Use weight_overrides to tune the transparent decision layer per request.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
limitNo
configNo
signalsNo
weightsNoAlias for weight_overrides.
gameweekYes
strategyNochampion
chips_usedNoAlternative to chips_available: chips already used this season.
model_pathNo
current_squadYes
bootstrap_pathNo
fetch_officialNoWhen auto_official_signals is true, fetch the current official bootstrap instead of using the local snapshot.
league_contextNo
buyable_playersNoOptional. Omit to load every player from the official bootstrap pool.
chips_availableNoUnused chips at this deadline. If omitted, all four are assumed available.
weight_overridesNoPer-request DecisionConfig overrides, e.g. short_weight, long_weight, lineup_weight, price_weight, ownership_weight, risk_aversion, rank_mode.
auto_official_signalsNoIf true, omitted signals are built from a local bootstrap snapshot or the official API. The server also falls back automatically when signals are omitted.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed6 schema fields changedv0.1.8
    • changedInput schema / properties / auto_official_signals / default
      Previous value: -falseNew value: +true
    • changedInput schema / properties / auto_official_signals / description
      Previous value: -"If true, signals may be omitted and are built from a local bootstrap snapshot or the official API."New value: +"If true, omitted signals are built from a local bootstrap snapshot or the official API. The server also falls back automatically when signals are omitted."
    • addedInput schema / properties / buyable_players / description
      Added value: +"Optional. Omit to load every player from the official bootstrap pool."
    • addedInput schema / properties / weight_overrides
      Added value: +{
+  "description": "Per-request DecisionConfig overrides, e.g. short_weight, long_weight, lineup_weight, price_weight, ownership_weight, risk_aversion, rank_mode.",
+  "type": "object"
+}
    • addedInput schema / properties / weights
      Added value: +{
+  "description": "Alias for weight_overrides.",
+  "type": "object"
+}
    • changedInput schema / required
      Previous value: -[
-  "gameweek",
-  "current_squad",
-  "buyable_players",
-  "config"
-]New value: +[
+  "gameweek",
+  "current_squad"
+]
  2. First observedv0.1.4

TDQS

A4/5.0
Behavior4/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations, the description carries the behavioral disclosure burden. It explains that buyable_players can be omitted and the server loads the official pool, that auto_official_signals fetches signals if not provided, and that hybrid strategies are 'model-backed'. It also mentions a 'transparent decision layer' and weight_overrides. It does not explicitly state read-only nature or side effects, but the nature of a recommendation tool implies safety.

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 moderately sized but front-loaded with the main purpose. It flows logically: primary action, required inputs, optional parameters, strategy details, and tuning. Every sentence adds value without excessive verbosity, though it could be slightly more compact.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness3/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given 16 parameters and nested objects, the description covers the most critical aspects but is not fully complete. It lacks an output schema, so it does not describe the response format beyond 'legal FPL transfer moves'. It also omits details on how errors or edge cases are handled, and some parameters remain unexplained. For a complex tool, more explicit guidance is needed.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 44%, so the description must compensate. It adds meaning to key parameters: buyable_players (optional, loads official pool), auto_official_signals (fetch signals if omitted), chips_available (unused chips), weight_overrides (tune decision layer). However, it does not explain several parameters like limit, config, model_path, bootstrap_path, or league_context, leaving gaps for those.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool's function: 'Return legal FPL transfer moves for the current gameweek' with a specific resource (FPL transfers) and a default strategy. It distinguishes itself from siblings by focusing on recommendations, not scoring or lineup planning, and mentions specific strategy options like 'champion' and 'hybrid'.

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 when to use it: to get transfer recommendations. It provides context on required inputs (full 15-player squad) and optional parameters (buyable_players, auto_official_signals, chips, etc.). However, it does not explicitly compare against sibling tools like fpl_score_moves or fpl_lineup_plan, nor state when NOT to use it.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Deploy Server

Other Tools