FPL Copilot

Mini-league win chances

get_mini_league_odds

Read-onlyIdempotent

Use this when an FPL manager asks their chances (or odds) of winning their mini-league: each manager's win and top-3 probability from 5,000 simulations of the rest of the season.

Tool call template

This tool declares no required parameters. Add optional parameters from the input schema as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {},
    "name": "get_mini_league_odds"
  }
}

Input Schema

Name	Required	Description	Default
`team_id`	No	The manager's FPL team ID (entry ID), or any FPL link containing /entry/<id>/. Leave empty if unknown.
`league_id`	No	Mini-league ID, or the FPL league standings link. Leave empty to list the manager's leagues.

Schema Changelog

Changes observed during successful MCP inspections.

First observedSep 30, 2026

TDQS

A4/5.0

Behavior4/5

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

Annotations already cover read-only, idempotent, non-destructive, closed-world behavior, so the description's job is to add beyond that — and it does: it discloses that results are Monte Carlo estimates from 5,000 season simulations, which tells the agent the output is probabilistic rather than a definitive standing. It doesn't mention runtime cost or edge cases (e.g., a league with too few gameweeks left), which keeps it below 5.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

One sentence, front-loaded with the trigger phrase and closed with a colon-introduced statement of what is returned. Nothing is redundant and nothing is buried.

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?

With only two optional parameters, no output schema, and full annotation coverage, the description supplies what an agent needs: when to call it and what the numbers mean. It could be slightly fuller by noting the empty-argument behavior or what happens when the manager's entry can't be resolved, but the schema handles the former.

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

Parameters3/5

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

Schema description coverage is 100% and both parameters already explain accepted forms (team ID or any /entry/<id>/ link, league ID or standings link, leave empty to list leagues). The description adds no parameter-specific meaning beyond that, so the baseline of 3 applies.

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

Purpose4/5

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

The description states a specific verb and resource — computing a manager's chances/odds of winning their mini-league — and specifies the returned quantities (win and top-3 probability). It is clearly distinguishable from a standings-style tool, but it never names the closest sibling (get_mini_league), so an agent must infer the split.

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?

"Use this when an FPL manager asks their chances (or odds) of winning their mini-league" gives an explicit trigger condition tied to user intent. There are no exclusions or named alternatives, so the when-not clause is missing, but the positive routing guidance is strong.

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

All FPL Copilot tools Inspect

Try in Browser

One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources

Need Help?