FPL Copilot

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

Annotations already cover the safety profile (readOnly, idempotent, non-destructive, closed-world), so the description is free to add value elsewhere — and it does, by disclosing the shape of the returned comparison (expected points, form, price, ownership side by side), which matters because there is no output schema. It does not mention limits or failure modes, so not a 5.

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?

A single front-loaded sentence that opens with the triggering condition ('Use this when...') and then supplies the concrete scenarios and output dimensions. No filler or redundancy.

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?

With no output schema, the description usefully summarizes what the comparison returns and frames the decision contexts. It is complete enough to invoke correctly, though it could say more about the horizon's effect on results or how ties/ranking are presented.

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 description coverage is 100%, so the schema already documents both 'names' and 'horizon' (including the 1-8 range). The description only loosely echoes this with 'two or three players' and 'coming gameweeks'; the baseline of 3 is appropriate, and the 2-3 phrasing is slightly narrower than the schema's maxItems of 10.

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?

States a specific verb+resource ('compare FPL players') and enumerates exactly what is compared (expected points over coming gameweeks, form, price, ownership). This clearly separates it from siblings like get_player or find_players, which return single-player or search results.

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 gives concrete selection scenarios ('Saka or Palmer?', one transfer for another, whether a -4 hit is worth it), so the agent knows when to reach for it. It stops short of naming an alternative tool or an explicit when-not condition, so it doesn't reach the 5 bar.

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

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

Annotations cover the safety profile (readOnlyHint=false, openWorldHint=true, idempotentHint=false), and the description adds what they can't: the output is publicly visible on fplcopilot.com, only server-created cards are eligible, and a link is returned. It does not address whether repeat calls mint fresh links, which matters given non-idempotency.

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?

Three compact sentences with the operative constraint ('App-only') front-loaded, followed by trigger, effect, return value, and scope limit. No sentence is filler.

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 one-parameter tool with no output schema, the description supplies trigger, effect, and return value, and implies the token must be server-issued. It is silent on failure behavior for an invalid/foreign token and on link reuse across repeated calls, which is a minor but real gap given the non-idempotent annotation.

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 coverage is 100%: the token parameter already carries a description and a 40-hex pattern. The description's 'the card's share token'/'as this server made it' restates and slightly reinforces the schema constraint without adding format or syntax detail, so the baseline 3 applies.

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?

States a specific verb (publishes) on a specific resource (the card, as made by this server) with a concrete outcome (a public fplcopilot.com page returning a link). The closing scope limit 'Nothing else can be published' cleanly separates it from every read-only sibling in the list.

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?

'App-only' plus 'the FPL Copilot card's Share button calls this' tells the agent exactly when this tool is legitimately invoked, effectively excluding agent-initiated use. It doesn't name an alternative tool, but no sibling overlaps this capability, so the missing alternatives are moot.

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

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

Annotations already declare readOnlyHint=true, idempotentHint=true, destructiveHint=false and openWorldHint=false, so safety and idempotency are covered. The description adds useful domain context (what xPts means, the classic-vs-draft distinction) but says nothing about result shape or how the 'best' set is bounded beyond the limit parameter.

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 purpose is front-loaded in the opening clause and everything sits in one dense but purposeful sentence with no filler. The stacked parentheticals (xPts definitions) make it slightly heavy but each element maps to a real capability.

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 an 8-parameter, no-required-args query tool with no output schema and full annotation coverage, the description covers purpose, filter axes, sort modes and the game-mode scope. The only gap is the absence of output-shape or result-size hints, which is minor given the limit parameter.

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 coverage is 100%, so the schema already documents all 8 parameters including sort options (xpts/value/differential) and filters. The description restates those same dimensions (position, price, club, ownership; points, value per £m, differentials) without adding syntax or semantics beyond the schema, so the baseline 3 applies.

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 gives a clear verb (find) and resource (FPL players) with a specific ranking basis (xPts / expected points) and the filter/sort dimensions. It states a clear value proposition, but it never distinguishes itself from sibling tools such as compare_players or get_player, so 5 is not warranted.

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?

It says when to reach for it ('to find the best ... players to pick or buy') and adds one exclusion ('Classic FPL, not FPL Draft'), which is a game-mode rather than a tool alternative. It names no sibling alternative and gives no condition that routes the agent between find_players, compare_players or get_player, so usage is only implied.

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

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

Annotations already declare readOnly, idempotent, non-destructive and closed-world, so the safety profile is covered. The description adds genuinely useful behavior: the squad is constrained to £100m and FPL squad rules, produced by an optimiser, and the result links out to Chip Strategies. It stops short of describing output shape, but with no output schema and the link behavior stated, this is strong.

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?

Front-loaded with the core purpose before the exclusions, and every clause earns its place. The second sentence is slightly tangled ('the result links FPL Copilot's Chip Strategies for that'), costing it the top mark.

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 two-parameter, optional-input, read-only tool with no output schema, the description covers scope, constraints (£100m, squad rules) and the redirect path for chip timing. Minor gap: it doesn't state how the 'best right now' variant is selected when gw is omitted.

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 coverage is 100% and both parameters carry their own descriptions (gw defaulting to next, chip accepting wildcard/free_hit with a note on bench_boost/triple_captain). The description restates the chip domain but adds no syntax or default detail beyond the schema, so the baseline 3 applies.

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?

States a specific verb and resource — the best FPL Wildcard or Free Hit squad for any gameweek or right now — plus the source ('FPL Copilot's optimiser'). It also names what it is not (Bench Boost team, chip timing), so the agent can separate it from chip-planning siblings without opening the schema.

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?

Explicit when-to-use ('someone wants the best FPL Wildcard or Free Hit squad for any gameweek, or the best FPL team right now') and an explicit when-not ('Not for a Bench Boost team or when to play a chip'), with a pointer to where chip-planning answers live. Nothing is left to inference.

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

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

Annotations already cover the safety profile (readOnly, idempotent, non-destructive, closed-world). The description adds genuine behavioral context beyond that: it works without a team, ranks the user's own players when a team is known, and scope 'all' ranks the whole game. It stops short of describing output format or ranking criteria, so it is not a 5.

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?

Three tight sentences, front-loaded with the trigger condition, then the no-team and with-team branches. No filler and every clause carries information.

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 two-optional-param, no-output-schema tool, the description covers the trigger, both input branches, and the fallback behavior, which is enough to call it correctly. Only the shape of the returned ranking is unspecified, which is a minor gap.

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 coverage is already 100%, so the baseline is 3, but the description adds meaning by tying 'scope' and 'team_id' together behaviorally (with a team it ranks their players; 'all' ranks the game) rather than merely restating field definitions.

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?

States a specific verb and resource ('who to captain ... in Fantasy Premier League this gameweek') and names the scenario including Triple Captain. An agent can distinguish this from siblings like get_manager_squad or rate_my_team without opening any schema.

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 says when to call it ('when someone asks who to captain'), that it works without a team ID, and how behavior changes with a team ID or scope 'all'. Alternatives and conditions are spelled out rather than left to inference.

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

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

Annotations already declare readOnlyHint=true, idempotentHint=true, destructiveHint=false and closed-world, so safety behavior is fully covered. The description adds only the word 'next', which signals the tool returns the upcoming deadline rather than a list or history. No further behavioral context is warranted for such a simple lookup.

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?

A single short sentence with no waste, front-loading the resource. Minor deduction for the awkward 'Use this for the ... deadline time' construction where a clean verb phrase would read better.

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?

With no output schema, the description does name the payload contents (deadline time and gameweek), which is the key information an agent needs to know what it will receive. For a nullary lookup this is close to complete; the omission of any format or timezone detail is minor.

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 tool takes zero parameters, so there is nothing for the description to clarify. Baseline 4 applies per the zero-parameter rule.

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?

States a specific resource: the next FPL deadline time and gameweek. It is instantly distinguishable from all siblings, none of which concern deadlines. Phrasing is slightly garbled ('Use this for the next ... deadline time'), but the purpose is unambiguous.

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?

There is no explicit when-to-use or when-not-to-use guidance, but for a zero-argument lookup with no competing sibling the implied usage is obvious. Adequate rather than instructive.

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

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

Annotations already declare readOnlyHint, idempotentHint, destructiveHint=false, and openWorldHint=false, lowering the bar. The description adds genuine behavioral detail by stating the ordering ('easiest runs first'), but does not describe the default window, pagination, or response shape beyond that.

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?

A single, front-loaded sentence beginning with 'Use this for' that delivers purpose, scope, and output ordering without filler. Slightly dense but no wasted sentences.

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?

With no output schema, the description usefully conveys what is returned (per-club fixtures, average difficulty, ordering) and there are no required parameters to explain. It is complete for this complexity level, lacking only detail on fixture-count limits beyond what the schema states.

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 description coverage is 100%, so all three parameters (gw_from, gw_to, teams) are already documented in the schema with sensible defaults. The description adds nothing about parameter formats or interactions, so the baseline 3 is appropriate.

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 states a specific verb+resource combination ('Fantasy Premier League fixture difficulty'), plus the payload ('each club's coming fixtures and their average difficulty'). It clearly distinguishes itself from siblings like get_player or get_captain_picks, though it does not name any sibling explicitly.

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 opening 'Use this for Fantasy Premier League fixture difficulty (FDR) and which teams have the easiest or hardest fixtures' gives a clear use context. It lacks any explicit when-not or alternative-tool routing, which keeps it short of a 5.

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

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

Annotations declare readOnlyHint=true, idempotentHint=true, destructiveHint=false, and openWorldHint=false, so safety and idempotency are already covered. The description adds transparency by enumerating the specific outputs of the review, but does not disclose return format, pagination, or error behavior. With annotations carrying the safety burden, a 3 is appropriate for the added output context.

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?

A single, well-structured sentence that front-loads the core action and then lists the review components. No redundant or filler content.

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 review tool with full parameter coverage and annotations covering safety, the description gives a complete picture of what the tool returns. The only minor gap is lack of explicit guidance on when to prefer this tool over alternatives like rate_my_team or get_my_team, but given the specific output enumeration, this is a relatively small omission.

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 coverage is 100%, so both parameters ('gw' and 'team_id') are fully described in the schema itself, including defaults and input formats. The description adds no parameter-level detail beyond what the schema provides, so baseline 3 applies.

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?

States a specific verb+resource (review a manager's gameweek) and lists exact deliverable components: points vs average, captain result, bench points, transfers, and luck vs expected points. Distinguishes from siblings like get_manager_squad or rate_my_team, which do different things.

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 when to use it (post-gameweek review) but does not explicitly state when NOT to use it or name alternatives. No routing guidance like 'use get_manager_squad for raw squad data' is provided.

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

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

Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the safety profile is covered. The description adds the 'App-only' hosting constraint and the UI trigger, which is modestly useful context, but says nothing about what the squad payload contains or the default/edge behavior of the gw parameter.

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?

Two short sentences with the constraint ('App-only') front-loaded and no filler. Efficient, though the second sentence is more UI-narration than agent-facing instruction.

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 tool with full schema coverage, complete annotations, and no output schema, the minimum information is present. Still, the description leaves open where entry_id comes from and what the returned squad looks like, and 'App-only' is never 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?

Schema description coverage is 100%: 'entry_id' is documented as the rival's FPL team id and 'gw' as a played gameweek defaulting to the last. The description adds no parameter meaning beyond the schema, so the baseline of 3 applies.

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 states the outcome clearly — showing a rival manager's squad on a pitch — which lets an agent distinguish this from get_my_team. However, it frames the tool from a UI-trigger perspective rather than naming the verb/resource directly, and it never names a sibling to contrast against.

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 mini-league card calls this when the user taps a rival' implies the usage context (retrieving someone else's squad), and 'App-only' hints at a client restriction. But no explicit when-not to use it, no alternatives, and no prerequisites such as needing a valid entry_id from get_mini_league.

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

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

Annotations already declare readOnlyHint, idempotentHint, non-destructive and closed-world, so the safety profile is covered. The description adds real behavioral value beyond that: with no league ID it degrades to a league-picker listing, and it previews the returned content (standings, gap, captains, differentials) despite there being no output schema.

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?

Two clauses, front-loaded with the primary use case, followed immediately by the fallback behavior. No filler, no repetition of the title, and every element earns its place.

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, two-optional-parameter tool with a fully documented schema and no output schema, the description covers purpose, usage and the zero-argument path. The only gap is that it never clarifies its boundary against get_mini_league_odds, which an agent choosing between the two would need.

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 description coverage is 100% and both parameters are documented there, including that they accept either IDs or full FPL links and can be left empty. The description's mention of omitting the league ID largely restates the schema's own "Leave empty to list the manager's leagues," so it adds little beyond the baseline.

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 names the resource (FPL mini-league) and enumerates what it returns: standings, gap to the leader, rivals' captains and differential picks. That is far more specific than a restatement of the name. It does not, however, distinguish itself from the sibling get_mini_league_odds, which plausibly covers adjacent mini-league 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?

It states the use case explicitly ("Use this for an FPL mini-league or a manager's rivals in it") and explains the no-argument fallback (listing the manager's leagues to choose from). There is no explicit when-not guidance and no alternative tool is named for the odds/rivals overlap.

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

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

Annotations already declare readOnly, idempotent, non-destructive, so safety is covered. The description adds genuinely useful behavioral context beyond that: the result is probabilistic, derived from 5,000 simulations of the rest of the season, which tells the agent to expect modeled probabilities rather than deterministic facts. It says nothing about caching or performance, keeping it below a 5.

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?

A single tight sentence: the usage condition is front-loaded and the output content is appended in a compact clause. No filler or redundant restatement of the name.

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?

With no output schema, the description usefully previews the return shape (win and top-3 probability per manager) and the simulation basis. For a two-optional-param, read-only tool this is nearly complete; only the empty-parameter fallback behavior lives solely in the schema.

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 description coverage is 100% with only two optional params, so the schema already documents that team_id and league_id accept IDs or FPL links and may be left empty. The description adds no parameter-level detail, so the baseline 3 applies.

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 states a specific verb and resource — computing each manager's win and top-3 probability in their mini-league — plus the mechanism (5,000 season simulations). It implicitly separates itself from the get_mini_league sibling by framing the output as odds rather than standings, though it never names the sibling explicitly.

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?

It gives a clear trigger: use when an FPL manager asks their chances/odds of winning their mini-league. No when-not condition or explicit alternative is named, so it stops short of full routing guidance.

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

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

Annotations already declare readOnlyHint, idempotentHint, destructiveHint=false, and openWorldHint=false, so the safety profile is covered. The description adds real value beyond that: it enumerates the return contents (expected points, fixtures, best XI, captain) and states the boundary 'shows the squad and does not score it', plus the input prerequisites. It does not discuss failure modes when the team cannot be resolved.

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?

Three sentences, each carrying distinct load: purpose and inputs first, then output contents, then the negative boundary and fallback input path. Nothing is redundant and the most decision-relevant information is front-loaded.

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?

With no output schema present, the description steps in by enumerating what is returned (expected points, fixtures, best XI and captain) and covers both input paths (team ID/link vs. player names). It is nearly complete for an agent to call it correctly, though it does not note behavior when neither input is supplied, even though both parameters are optional (0 required).

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 description coverage is 100%, and the schema itself already documents the format for players ('11-15 FPL player names... e.g. Palmer CHE') and team_id ('entry ID, or any FPL link containing /entry/<id>/'). The description only restates that a team ID, link, or screenshot-derived player names are needed, so it adds little beyond the schema — the baseline 3 applies.

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?

States a specific verb and resource for a specific scope: showing an FPL manager's own squad for start/bench/captain questions, with concrete output content (Copilot expected points, next-GW fixtures, best XI, captain). It also explicitly carves itself out from the scoring siblings with 'does not score it', so an agent can separate it from rate_my_team without opening either schema.

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?

Gives clear usage context ('use this for start, bench and captain questions about an FPL manager's own squad') and an implicit exclusion via 'does not score it', which routes scoring questions elsewhere. It does not name the alternative tool (rate_my_team) directly, so the routing is inferred rather than explicit.

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

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

Annotations already declare readOnlyHint, idempotentHint, destructiveHint=false and openWorldHint=false, so the safety profile is fully covered. The description adds a small amount of value by disclosing that results include a probability of being the main taker, but says nothing about return format or coverage per club.

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?

A single front-loaded sentence with the action and scope first ('Use this to find who takes penalties, corners and free kicks...'). The trailing clause about main-taker probability is slightly awkward but carries real information, so no meaningful waste.

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?

Low-complexity, read-only tool with one fully documented optional parameter and no output schema, so the description need not enumerate return fields. It covers scope and the headline return value; only the exact output shape is unstated, which is minor here.

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 description coverage is 100% and the single 'teams' parameter is documented in the schema with an example and default ('default: all 20'). The description adds no parameter syntax or default information beyond that, so the baseline 3 applies.

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?

States a specific verb ('find') and a precisely scoped resource: penalty, corner and free-kick takers for Premier League clubs in FPL, plus the output content (chance of being the club's main taker). No sibling tool covers set-piece takers, so an agent can identify it without cross-referencing schemas.

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?

"Use this to find..." implies the context of use but never states when-not to use it or names any alternative. Given that no sibling overlaps with this resource, the implied usage is adequate but no explicit routing guidance is provided.

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

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

Annotations already declare readOnlyHint, idempotentHint and destructiveHint=false, so the safety profile is covered and the bar is lower. The description usefully discloses the card's contents (injury news, price-change progress, penalty-taker chance) since there is no output schema, but says nothing about data freshness, caching, or what happens when more than five names are supplied.

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?

A single front-loaded sentence that opens with the use case before enumerating fields, so the agent gets the trigger first. It is dense but every clause maps to a real returned data point.

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 lookup whose safety profile and parameters are fully covered by annotations and schema, the description is close to complete and compensates for the missing output schema by listing the card's fields. Minor gaps remain around horizon behavior, data recency, and how overflow beyond five names is handled.

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 description coverage is 100%, with both 'names' (1-5, max 15 items) and 'horizon' (1-8 gameweeks) documented in the schema itself. The description echoes the batch size but never mentions the 'horizon' parameter, so it adds no semantic value beyond the schema; baseline 3 applies.

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 states a concrete resource (FPL player card) and enumerates what it returns: expected points per gameweek, fixtures, injury news, price-change progress, ownership, xG/xA and penalty-taker likelihood. It implicitly separates itself from search/find/compare siblings by scoping to 'one to five players', but it never names a sibling tool explicitly.

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?

It gives a clear decision-making context ('whether to buy, sell or start them') and a batch-size constraint of one to five players, which is actionable guidance. It stops short of exclusions or naming alternatives such as compare_players or get_player_breakdown for narrower analyses.

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

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

Annotations already declare readOnlyHint, idempotentHint, destructiveHint=false, and openWorldHint=false, so the safety profile is covered. The description adds a genuine behavioral constraint not in the annotations ("App-only"), but says nothing about return format, latency, or how news/fixtures data behaves when absent.

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?

Two short sentences, with the availability constraint front-loaded before the content list. The single long clause enumerating breakdown sources is dense but every item is informative, so nothing is wasted.

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?

With no output schema, the description correctly compensates by enumerating the returned data (points by gameweek and by source, fixtures, news). For a one-parameter, read-only tool this is nearly sufficient; the only real hole is the lack of differentiation from similarly named siblings.

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 description coverage is 100%, so player_id's meaning and 1-5000 range are already fully documented in the schema. The description adds no parameter-level detail (e.g., where to obtain the element id), which is acceptable given the schema does the work.

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 names the resource (a player's card) and enumerates the content returned: expected points by gameweek and by source, fixtures, and news. It is clear what the tool produces, but it never distinguishes itself from the sibling get_player or the near-identically named get_player_breakdowns, so an agent could easily pick the wrong one.

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?

It supplies a trigger context ("calls this when the user taps a player") and an availability constraint ("App-only"), which implies when it applies. However, it gives no explicit when-to-use vs when-not-to-use guidance against get_player, get_player_breakdowns, or any other sibling, leaving routing to inference.

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

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

Annotations already declare readOnlyHint=true, idempotentHint=true, destructiveHint=false, so the safety profile is covered. The description adds the app-only scoping and the preloading intent, which is useful context, but says nothing about return shape, batching limits, or behavior when ids are missing. With annotations carrying the safety load, a 3 fits.

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?

A single sentence that front-loads the 'App-only' constraint and then the reason. Slightly clunky with 'so a tap opens one at once', but there is no filler or redundancy.

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 one-parameter, non-destructive, annotated read tool with no output schema, the description is broadly adequate, but the 'App-only' framing leaves an agent unsure whether it is even meant to be called, and the batch-vs-singular relationship with get_player_breakdown is unaddressed. Some completeness gaps remain for correct tool selection.

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 coverage is 100% for the single player_ids parameter, and the schema itself documents it as 'FPL player (element) ids' with min/max bounds. The description adds only the informal 'players it shows' framing, which does not extend meaning beyond the schema, so the baseline 3 is appropriate.

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?

It states the tool loads player cards via a batch of ids, but the phrasing 'load the player cards of the players it shows' largely restates the title 'Player cards' and is framed around internal app behavior rather than a precise verb+resource. It never distinguishes this plural/batch tool from the sibling get_player_breakdown (singular) or get_player, which an agent would need to pick correctly.

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?

'App-only' and 'The FPL Copilot card calls this as it opens' give a concrete usage context (preloading cards for instant tap-open), which is more than nothing. However, there is no guidance for an agent on when to prefer this over the singular get_player_breakdown, and no explicit exclusions or alternatives.

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

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

Annotations already establish readOnlyHint, idempotentHint, and destructiveHint=false, so the safety profile is covered. The description adds genuinely useful context beyond that: the data source (FPL Copilot's expected minutes) and the temporal limitation (next gameweek only), which an agent needs to judge staleness.

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?

One dense sentence with no filler; the use case is front-loaded before the supporting detail about content and source.

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 single-optional-param read tool with full annotation coverage, the definition tells the agent when to call it and what data underlies the result. The lack of an output schema means the response shape is slightly unspecified, but the description's content summary largely compensates.

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 description coverage is 100%: the single 'teams' parameter already documents the example format and the default of all 20 clubs. The description adds nothing about the filter parameter, so the baseline 3 applies.

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?

Names a specific resource (predicted Premier League starting XIs and team news) and scope (next FPL gameweek), with parenthetical detail on what it actually reveals — starters, injuries, rotation. No sibling tool covers lineups, so no differentiation is needed and an agent can route to it unambiguously.

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?

Opens with an explicit 'Use this for...' trigger naming the exact scenario (predicted XIs/team news for the next gameweek). It stops short of naming alternatives or when-not-to-use conditions among the many player/team siblings, so it's clear context without exclusions.

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

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

Annotations already declare readOnlyHint, idempotentHint, and destructiveHint=false, so safety is covered. The description adds domain context (predicted vs. realized changes) but says nothing about return shape, ordering, or whether results are capped, leaving the behavioral picture thin 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?

A single front-loaded sentence that names the resource first and the two usage modes second. Every clause carries information and nothing is padded.

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 two-optional-parameter read-only tool with no output schema, the description covers scope and the key tonight/recent distinction. It could note that omitting names returns the full set of price-change candidates, which is the one remaining gap.

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 description coverage is 100%, so both the view enum-like values and the names filter are already documented in the schema. The description restates the tonight/recent distinction but adds no syntax or format detail beyond it, making 3 the correct baseline.

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?

States a specific resource (FPL price rises and falls) and the two data modes (likely tonight vs. already made this gameweek). No sibling tool covers price changes, so the agent can distinguish it immediately.

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?

"Use this for FPL price rises and falls" gives clear usage context, and the description implies the tonight/recent split that the view parameter controls. It does not name alternatives or state when-not to use it, but no sibling overlaps enough to require that.

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

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

Annotations already declare readOnly/idempotent/non-destructive, so the safety profile is covered. The description adds real beyond-schema context: the scoring methodology (0-100 relative to the best possible squad over the next 5 gameweeks) and the shape of the response (biggest fixes, named players).

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?

Front-loaded with the trigger condition, then the effect, then the input options. Two sentences with little waste, though the second sentence is long and packs three separate ideas.

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?

With no output schema, the description carries the burden of describing the result and does so (score plus prioritized fixes). All three parameters are optional with no stated precedence for the ID-vs-players fallback, and the captain input is unaddressed, leaving a small gap.

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 description coverage is 100%, so the baseline is 3. The description restates the accepted inputs (team ID, FPL link, or player names from a screenshot) but adds no format or precedence guidance beyond the schema, and never mentions the captain parameter at all.

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?

States a specific verb and resource ('rate/review their team'), plus the concrete output ('scores the squad 0-100 against the best possible squad over the next 5 gameweeks and lists the biggest fixes'). This is clearly distinguishable from get_my_team and get_manager_squad, which merely retrieve a squad rather than evaluating it.

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?

Gives explicit trigger conditions: a manager wanting a rating/review, or sharing a team ID or FPL link 'without saying more' — a genuinely useful disambiguation for an ambiguous user utterance. It does not, however, name a sibling tool or state when NOT to use this one (e.g., when they only want raw squad data).

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

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

Annotations already declare readOnlyHint, idempotentHint, and non-destructive/open-world=false, so safety is fully covered by structured data. The description adds only that the whole guide is returned 'in full' and that either a slug or a link is accepted — useful but thin 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?

A single front-loaded sentence with no filler; the action, target, and accepted input forms are all in one clause.

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 simple single-parameter read with no output schema and rich annotations, the description covers what an agent needs to invoke it correctly. It could note expected return shape or invalid-slug behavior, but nothing critical is missing.

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?

With one parameter at 100% schema coverage, the schema already documents that slug accepts a guide slug or a blog link. The description restates the same fact without adding format, validation, or error semantics, so the baseline 3 applies.

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?

States a specific verb (read) and resource (one FPL guide) with the scope 'in full', which implicitly contrasts with the sibling search_guides. It does not actually name search_guides, so differentiation is inferable rather than 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?

'Use this to read one guide in full' implies the use case (fetching a single known guide) but gives no explicit when-not or named alternative such as search_guides for discovery. Adequate but leaves routing to inference.

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

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

Annotations already declare readOnly, idempotent, non-destructive, and closed-world, so the safety profile is covered. The description adds genuinely non-obvious behavioral context beyond that: the underlying rules are seasonally volatile (free transfers now roll over up to 5), so results are authoritative over model memory. It says nothing about result count, ranking, or pagination, keeping it below a 5.

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?

Two sentences, front-loaded with the use case and then the rationale. The long parenthetical topic list is dense but earns its place by giving retrieval-relevant vocabulary. Slightly list-heavy, but no filler sentences.

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 zero-required-param, read-only search tool with full annotation coverage and no output schema, the description supplies enough to invoke it correctly: what it searches, when to prefer it, and why freshness matters. Minor omission is guidance on using gw vs query together or what an empty result implies.

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 description coverage is 100% — both gw ('Prefer guides for this gameweek') and query ('What to look for, e.g. bench boost') are already documented in the schema with examples. The description adds no additional syntax, default, or interaction semantics between the two optional parameters, so the baseline 3 applies.

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?

States a specific verb (search) and resource (FPL Copilot guides) and enumerates the covered topic domains: scoring, free transfers, chips, DefCon, FDR, gameweek tips, penalty takers, fixtures. This lets an agent distinguish it from retrieval-by-id siblings like read_guide or single-topic siblings like get_penalty_takers without opening a schema.

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?

Gives an explicit triggering condition — 'Fantasy Premier League rules and how-to questions' — and an explicit anti-pattern: don't rely on model memory because rules change each season. It does not, however, contrast itself with the sibling read_guide, leaving the search-vs-read choice to inference.

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