Skip to main content
Glama

FPL mini-league standings

get_mini_league
Read-onlyIdempotent

Use this for an FPL mini-league: standings, the gap to the leader, and rivals' captains and differential picks. Without a league ID it lists the manager's leagues to choose from.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
team_idNoThe manager's FPL team ID (entry ID), or any FPL link containing /entry/<id>/. Leave empty if unknown.
league_idNoMini-league ID, or the FPL league standings link. Leave empty to list the manager's leagues.

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observed

TDQS

A3.7/5.0
Behavior4/5

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

Annotations already establish readOnly, idempotent, non-destructive and closed-world, so safety needs no restating. The description adds a genuine behavioral trait beyond that: the no-league-ID path degrades to a league-list/selection mode. It still does not mention auth, rate limits, or result size.

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?

Two sentences, zero filler, with the primary capability front-loaded and the fallback mode second. Nothing redundant, though it is slightly clipped for a tool this data-rich.

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?

No output schema exists, so the description carries the return-value burden, and it does list the four things returned (standings, gap to leader, captains, differentials). With only two optional params and annotations covering safety, the main omissions are scope/pagination and any hint of the odds sibling.

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 100% and both parameters are documented in the schema, including the 'leave empty' semantics and link parsing, so the schema does the heavy lifting. The description's 'without a league ID' sentence largely repeats the schema's league_id note rather than adding syntax or format detail.

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?

States a specific resource (FPL mini-league) and enumerates what it returns: standings, gap to the leader, rivals' captains and differential picks. An agent can tell this is a standings/insight tool. It does not explicitly distinguish itself from the sibling get_mini_league_odds, which is the one plausible confusable tool.

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?

Gives one useful usage rule: omit the league ID to list the manager's leagues and choose from them. That is a conditional entry path, not when-to-use guidance against alternatives, and no exclusions or sibling routing are provided.

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

Try in Browser

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources