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

No annotations are present, so the description carries the full behavioral burden. It discloses two execution modes and the exact parameter combination needed to replicate the research candidate, which is meaningful. However, it does not describe what the backtest returns, whether it is read-only, what data prerequisites exist, or what failure modes might occur, leaving notable gaps.

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 earn their place: the first states the purpose and the two mode routes, the second gives a compact reproducible recipe. It is front-loaded with the core action and uses no filler or repetition, which is exemplary for a tool with 21 parameters.

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 complex 21-parameter tool with no output schema and no annotations, the description is not complete enough. It explains two modes and a recipe, but an agent still does not know what the backtest returns, whether one of the two modes is required, which combinations of optional parameters are valid, or what the results look like. The description is a helpful starting point, not a complete invocation guide.

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 only 10% schema description coverage, the description must compensate, and it partially does: it adds meaning to scenarios/scenarios_path, history_root, season, forecast_model, policy, and initial_squad_modes. But 21 parameters exist, and many (seed, objective, candidates, depths, beam widths, cocktail_config, etc.) get no semantic help from either the schema or the description, so compensation is incomplete.

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 opens with a specific verb+resource: 'Backtest and compare tunable strategies.' It clearly identifies the tool's core function and distinguishes it from sibling tools like fpl_recommend_moves or fpl_strategy_info by virtue of the backtesting action, but it never explicitly names or contrasts those siblings, so it stops short of full differentiation.

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 explicit routing between two modes: use scenarios/scenarios_path for point-in-time replay versus history_root plus season for the Vaastav-format simulator. It also names a precise parameter recipe to reproduce the published 2,486-point candidate. It lacks explicit 'when not to use' guidance against sibling tools, but the intra-tool guidance is strong.

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?

With no annotations, the description carries the behavioral burden, and it does frame the tool as a non-mutating inspection operation ('Return', 'inspect'). However, it does not disclose fetch/caching behavior implied by parameters like fetch_official and auto_official_signals, nor whether signals are computed on demand.

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 two purposeful sentences: the first states the return value and content, the second states the intended usage. It is front-loaded with the core operation and contains no 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?

The tool has 9 parameters, nested objects, no output schema, and no annotations, yet the description only covers the high-level purpose. An agent would still be unable to determine how to set config, signals, bootstrap_path, fetch_official, or auto_official_signals, or what the returned signal table's shape is.

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 only 11%, so the description must compensate, but it only clarifies current_squad and buyable_players ('supplied squad and buyable pool'). Parameters such as config, signals, bootstrap_path, fetch_official, auto_official_signals, and limit receive no semantic explanation in the description.

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 a specific verb ('Return') and a specific resource ('point-in-time signal table for the supplied squad and buyable pool'), and enumerates the signal content. The closing phrase 'before asking for a decision' differentiates it from decision-oriented siblings like fpl_recommend_moves and fpl_score_moves.

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 it to inspect the underlying inputs before asking for a decision' provides clear situational guidance and implies it should precede decision tools rather than replace them. It does not explicitly name alternatives or state when not to use it, but the context is clear.

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?

No annotations are provided, so the description carries the full burden. It discloses non-obvious behavior: it only chooses/plans rather than executes, and it reports projected bench points for Bench Boost while clarifying that normally only the XI scores. This meaningfully helps an agent understand the tool's output semantics, though it does not mention side effects or data-fetching behavior.

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, no filler, with the main action front-loaded and the Bench Boost nuance placed second. Every clause adds useful 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?

The tool has 7 parameters, no output schema, and no annotations, yet the description leaves most parameter behaviors unexplained. It covers the expected outputs well but omits how optional inputs like fetch_official, signals, and auto_official_signals affect the result, making it insufficient for predictable invocation.

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 only 14%, so the description must compensate, but it only loosely implies gameweek and current_squad. It does not explain signals, bootstrap_path, fetch_official, auto_official_signals, or the relationship between buyable_players and the official universe. An agent would struggle to select correct values for most optional parameters.

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 a specific verb ('Choose') and resource ('legal current-week formation, starting XI, bench order, captain and vice-captain') from a 15-player squad, and even adds the return nuance about Bench Boost points. This is clearly distinct from sibling tools about moves, strategy, search, scoring, or backtesting.

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 this is the tool for current-week lineup planning from a supplied squad, but it never names sibling alternatives or gives conditions for when to use this tool instead of fpl_recommend_moves or fpl_score_moves. There is no exclusion or when-not 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?

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.

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.

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.

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.

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.

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.

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

With no annotations, the description carries full responsibility for behavioral disclosure. It indicates this is a read-only ranking tool (no side effects mentioned) and clarifies it uses transparent weights. However, it does not disclose the output format, pagination behavior, or what happens on invalid inputs (e.g., missing required params). While not misleading, it leaves notable gaps.

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 two sentences with zero fluff. The primary purpose is stated in the first sentence, and the second sentence adds the key contrast with fpl_recommend_moves plus a list of relevant factors. It is appropriately sized and 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?

The tool has 10 parameters, nested objects, and no output schema, yet the description covers only purpose and a high-level comparison. It does not explain required parameters (gameweek, current_squad), how to use config, signals, weight_overrides, limit, fetch_official, or auto_official_signals, nor what the ranking output looks like. The description is too sparse for a tool of this complexity.

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 only 10% (only buyable_players has a description). The description mentions several evaluation factors (short/long points, price economics, ownership leverage, etc.) that likely correspond to config or weight_overrides, but it does not explain how to structure these parameters or what values are expected. It provides some high-level semantic context but fails to compensate for the low 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 clearly states the tool's function: 'Rank legal one-transfer moves under explicit transparent weights.' It uses a specific verb (rank) and a distinct resource (one-transfer moves), and explicitly differentiates from sibling fpl_recommend_moves by saying it is for tuning/explanation rather than final action. This leaves no ambiguity about its role.

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 this tool versus alternatives: 'use fpl_recommend_moves for the final action including chips and the learned policy.' It also lists the factors it evaluates (short/long points, price economics, etc.), giving clear context for when this tool is appropriate. No inference is required.

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?

With no annotations, the description carries the full behavioral burden. It usefully discloses that results include current price, expected points, form, ownership, status, and transfer signals, and that the pool is cached. However, it does not explain the behavioral impact of non-obvious options such as fetch_official or bootstrap_path.

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 with no filler: the first identifies what the tool searches and by which criteria, and the second states the intended use and returned data. Every sentence contributes useful guidance.

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?

Adequate for a search tool with no required parameters, but there are meaningful gaps: no output schema, no annotation coverage, and undocumented semantics for bootstrap_path and fetch_official. The description tells the agent what it will get back but not all the operational details needed to invoke it in more advanced 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?

Schema description coverage is only 22%, so the description must compensate. It does map several filter dimensions to parameters (name, position, team, price, availability), but it does not clarify the meaning of fetch_official or bootstrap_path, and several parameters still lack any semantic guidance beyond defaults.

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 a specific resource ('full cached official FPL player pool'), and lists the main search dimensions. The description clearly separates this from its sibling tools, which are about recommendations, strategies, lineups, forecasts, and backtesting rather than searching players.

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 clear context: 'Use this to construct or inspect buyable candidates.' It does not explicitly name alternatives or say when not to use it, but the stated use case is actionable and distinct enough from the sibling tools.

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?

With no annotations, the description must carry the full burden. It says 'Return', which indicates a read operation, but it does not explicitly state that it has no side effects or require any authentication. Given that it is a catalog tool with no parameters, the ambiguity is low, but the description does not go beyond the bare action to disclose any edge cases or data semantics. It is adequate but not richly transparent.

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 a single, information-dense sentence that front-loads the action ('Return all available') and enumerates the catalog contents. It is concise and avoids fluff, though the list of items makes the sentence a bit long. Overall it is well-structured for the task.

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 no parameters and no output schema, the description covers all it needs: it enumerates the types of information returned (strategy profiles, action kinds, configs, signal components, tunable fields). Nothing an agent would need to call it successfully is missing, though it could optionally mention whether the output is a schema or an array, but that is likely self-evident. It is complete enough.

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 is empty (0 parameters). Per the rubric, a baseline of 4 applies for 0 params. The description does not need to explain parameters, and it correctly focuses on the output content, which is the meaningful part. No additional parameter context is required.

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 uses a specific verb ('Return') and a clear resource ('all available strategy profiles, action kinds, default decision/cocktail configs, signal components, and the fields that can be tuned'). It explicitly says 'all available', which distinguishes it from sibling tools like fpl_strategy_info (likely a single strategy lookup) and action-oriented tools like fpl_recommend_moves. The purpose is unmistakable.

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 makes the tool's role as a catalog/overview apparent, but it does not explicitly state when to use it versus alternatives, nor does it provide any 'when not to use' guidance. The usage is implied by the word 'catalog' and the sibling names (e.g., fpl_recommend_moves for actions), but no explicit routing is offered. This matches the 'implied usage' level.

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?

With no annotations, the description carries the full behavioral burden. It indicates a read-only action by using 'Return' and lists 'known limitations' as an output, but it does not disclose specifics such as data sources, staleness, or what the benchmark status is compared against.

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 a single sentence that lists exactly what is returned, with no filler or repetition. It is front-loaded and easy to parse.

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 parameterless info tool with no output schema, the description names all four return categories and gives a reasonable expectation of the payload. It could add context about how 'selected' is determined, but nothing is missing that would prevent an agent from invoking it.

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 has zero parameters, so the schema is trivially complete and there is nothing for the description to clarify. The baseline of 4 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 uses a specific verb ('Return') and names the resource: the selected strategy, benchmark status, research sources, and known limitations. It is clear what the tool produces, though it does not explicitly differentiate itself from the sibling fpl_recommend_moves.

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 guidance is given about when to use this tool versus fpl_recommend_moves, and no conditions or exclusions are mentioned. The intended use is only implied by the tool name and the noun phrase 'selected strategy,' but the description never states the decision context.

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