Server Quality Checklist

Tool Scores

• compare_playersC
  2.9/5.0
  Behavior2/5

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

  Without annotations, the description carries the full behavioral disclosure burden, but it only rephrases the operation. It does not clarify that the tool is read-only, how it resolves player names, whether it calls external FPL data, or whether it returns live vs cached information.

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

  Conciseness4/5

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

  The description is a single sentence with no repeated terms, filler, or unnecessary clauses. It communicates the core purpose efficiently, though its brevity also contributes to missing contextual details.

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

  Completeness3/5

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

  Given that the tool has only one parameter and an output schema exists, the description is close to adequate for a comparison utility. Still, with no annotations, it would benefit from noting how player names are matched and what exactly is compared, which are not addressed.

  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?

  The input schema provides no descriptions and coverage is 0%, so the description's mentions of 'two or more' and 'by name' add meaningful constraints for the sole 'players' parameter. However, it does not specify exact name formats, matching rules, or the expected array length beyond 'two or more'.

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

  Purpose4/5

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

  The description uses a specific verb ('compare') with a clear resource ('players') and qualifies the comparison as 'side by side by name'. This helps differentiate it from singular lookup tools like get_player, though it does not explicitly name sibling alternatives.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines2/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description provides no explicit when-to-use or when-not-to-use guidance. The 'two or more players' phrase implies a minimum input size, but it does not tell an agent when to choose this tool over search_players, get_player, or other comparison-adjacent tools.

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

• get_fixturesC
  2.9/5.0
  Behavior2/5

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

  No annotations are provided, so the description carries the full burden for behavioral disclosure. It states the tool returns upcoming fixtures and difficulty but does not mention that it is a read-only operation, any authentication requirements, rate limits, or side effects. The example of team names gives minor input-format context, but no behavioral traits are disclosed.

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

  Conciseness5/5

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

  The description is a single, front-loaded sentence with no redundant words. It efficiently communicates the core purpose and includes a useful example. Every word contributes to the meaning, making it an excellent model of conciseness.

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

  Completeness3/5

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

  An output schema exists, so the return format is covered elsewhere. Given the low complexity (2 parameters) and available output schema, the description is partially complete: it clearly states the main purpose, but it leaves the semantics of 'next_n' undocumented and does not disclose behavioral expectations such as read-only status or authentication. An agent could call the tool with the required 'team' parameter but would have to infer 'next_n' behavior.

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

  Parameters2/5

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

  The schema has no descriptions for its parameters (coverage 0%), so the description must compensate. It partially does by providing example values for the 'team' parameter ('Arsenal' or 'ARS'), clarifying accepted formats. However, the optional 'next_n' parameter is never mentioned, and no meaning is added for it beyond the schema's default of 5. With two parameters, only one is addressed.

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

  Purpose4/5

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

  The description clearly identifies the resource (upcoming fixtures and difficulty) and the input (a club), with an example of acceptable team values. It is not tautological and presents a distinct purpose from sibling tools like get_gameweek_status or team_news. It lacks an explicit verb like 'retrieves' or 'lists', but the meaning is unambiguous.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines2/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description provides no guidance on when to use this tool instead of alternatives such as team_news or get_gameweek_status. There are no exclusions, conditions, or mentions of alternative tools. Usage context is only implied by the purpose statement, not explicitly stated.

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

• get_playerB
  3.1/5.0
  Behavior2/5

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

  No annotations are provided, so the description carries the full burden of behavioral disclosure. It discloses the returned content but says nothing about whether this is a read-only operation, whether authentication is required, how missing or ambiguous names are handled, or any rate limits. For a tool with zero annotation coverage, this is a notable gap.

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

  Conciseness5/5

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

  The description is a single concise sentence that front-loads the tool's purpose and enumerates the key output areas. Every word contributes meaning; there is no fluff or repetition.

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

  Completeness3/5

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

  The tool is simple with one parameter, and an output schema exists, so return-value documentation is not required. However, given the absence of annotations and the presence of several sibling tools, the description could have added one or two sentences about when this tool is appropriate and what 'name' should contain. It is minimally viable but not fully complete.

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

  Parameters2/5

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

  Schema description coverage is 0%, and the description does not compensate. The parameter is simply named 'name', and the description only says 'for one player' without clarifying acceptable formats, case sensitivity, or whether partial or fuzzy names are accepted. The parameter is self-explanatory at a basic level, but the description adds no semantic 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?

  The description identifies a specific resource ('one player') and lists concrete output categories: stats, status, and upcoming fixtures. It is distinguishable from siblings like search_players or compare_players because it clearly targets a single player's detailed profile, though it does not explicitly name those alternatives.

  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?

  Usage context is implied rather than stated: the phrase 'for one player' suggests it should be used when a specific player is already identified by name. However, there is no explicit guidance about when to prefer this over search_players or compare_players, and no mention of prerequisites such as being logged in.

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

• play_chipB
  3.2/5.0
  Behavior2/5

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

  With no annotations provided, the description carries the full burden of behavioral disclosure. It mentions the action of activating or canceling, which implies a state change, but does not disclose any side effects (e.g., whether activating one chip deactivates others), prerequisites (e.g., must be a valid gameweek), or response format. This is a gap for a state-changing tool.

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

  Conciseness4/5

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

  The description is concise, with the core action in the first sentence. The parameter details are efficiently given in the args block. No wasted words; though the ASCII aesthetics could be improved, it's still well-structured.

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

  Completeness3/5

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

  Given the tool's simplicity (2 params, one required) and the presence of an output schema, the description is mostly complete. However, it lacks behavioral details like whether chips are mutually exclusive or if there are any restrictions (e.g., certain chips only allowed in certain gameweeks), which an agent might need to know for correct usage.

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

  Parameters3/5

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

  Schema description coverage is 0%, so the description must compensate. It explains the 'chip' parameter by listing allowed values and aliases, which adds meaning beyond the schema's generic string type. For 'team_id', it says 'Optional; detected from your account if omitted', which is helpful. However, it doesn't provide detailed semantics beyond that, but with 2 parameters and 0% coverage, this is a baseline 3.

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

  Purpose4/5

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

  The description clearly states the tool activates or cancels a chip, which is a specific action on a resource (chip). It lists the possible chip values, distinguishing it from siblings that handle transfers or captain changes. However, the phrasing 'Activate a chip, or cancel the active one' is a bit terse but still comprehensible, so not a perfect 5.

  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?

  The description implicitly indicates when to use it: when you need to play a chip or cancel one. It does not explicitly mention when not to use it or compare to alternatives, such as set_captain for captain changes)Skip, but the list of siblings suggests it is the only chip-related tool, so usage is inferred.

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

• get_league_standingsB
  3.3/5.0
  Behavior2/5

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

  The description implies a read-only operation (show), but does not disclose potential side effects, auth requirements, rate limits, or other behavioral constraints. With no annotations, full burden falls on the description.

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

  Conciseness5/5

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

  The description is a single concise sentence with no redundant words, effectively conveying the tool's function.

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

  Completeness3/5

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

  Without an output schema, the description does not detail the response structure (e.g., format of standings). It gives enough for a simple fetch but lacks specifics on return type or error handling.

  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?

  The description adds context that league_id identifies the mini-league, but it largely reiterates the schema's 'League Id' title. It provides some clarification without deep semantic detail.

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

  Purpose5/5

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

  The description clearly states the verb 'Show', the resource 'standings', and specifies 'classic mini-league' and 'by its ID', making it distinct and unambiguous.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines2/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  No explicit guidance on when to use this tool versus alternatives (e.g., analyze_mini_league). It does not mention conditions or exclusions, leaving usage to inference.

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

• suggest_transfersB
  3.4/5.0
  Behavior2/5

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

  There are no annotations provided, and the description does not explicitly state whether the tool modifies data or is read-only. The verb 'suggest' implies it returns recommendations without side effects, but this is not confirmed. There is no mention of authentication, rate limits, or any side effects, leaving behavior largely opaque.

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

  Conciseness5/5

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

  The description is concise and well-structured. The main purpose is stated in one clear sentence, followed by a succinct parameter list. There is no redundant or extraneous information, and the layout is easy to scan.

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

  Completeness3/5

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

  The description covers the purpose and parameters adequately but lacks information about the expected output or return format. It does not explain what the suggested transfers will look like, how many are returned, or how to interpret the suggestions. Given that an output schema is indicated but not shown, the description alone is somewhat incomplete for a caller to fully understand the tool's outcome.

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

  Parameters5/5

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

  Both parameters are well explained in the description. 'mode' is fully elaborated with three distinct options and their meanings, while 'team_id' is described as optional with automatic detection from the account. This goes beyond the schema's type and default values, providing clear semantic guidance for the caller.

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

  Purpose4/5

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

  The description clearly states the tool's purpose: suggesting transfers to improve the squad over the next 3 gameweeks. It uses a specific verb ('suggest') and specifies the resource (transfers) and scope (timeframe). However, it does not distinguish itself from sibling tools that may also deal with transfers or squad management, so it is not fully clear when this is the best choice.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines2/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description provides no guidance on when to use this tool versus alternatives. It does not mention prerequisites, typical use cases, or scenarios where other tools (e.g., transfer_preview or make_transfer) would be more appropriate. The only hint is the parameter descriptions, but they do not constitute explicit usage guidelines.

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

• team_newsB
  3.4/5.0
  Behavior3/5

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

  With no annotations, the description carries the burden of behavioral disclosure. It lists the types of information returned (status, chance of playing, official note) and notes that the player filter works even for fit players. However, it does not mention data source, update frequency, or any limitations. Given the absence of annotations, it provides moderate but not exhaustive transparency.

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

  Conciseness4/5

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

  The description is concise and well-structured, with the core purpose stated first, followed by parameter explanations. It is free of fluff and front-loaded with the key information an agent needs to decide on invocation.

  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?

  For a tool with only two optional parameters and a provided output schema, the description covers the essential content of the response and both parameters clearly. It does not elaborate on edge cases or formatting, but given the low complexity, it is sufficiently complete for an agent to call correctly.

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

  Parameters4/5

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

  Schema description coverage is 0%, so the description must explain parameters. It does: 'team: Optional club filter (e.g. 'Arsenal' or 'ARS')' and 'player: Optional player name; shows that player's status even if fit.' Both are clearly defined with examples and behavior expectations, fully compensating for the schema gap.

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

  Purpose4/5

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

  The description clearly states the tool's purpose: 'Injury and availability news: who is injured, doubtful, or suspended, their chance of playing, and the official note.' This is specific and distinguishes it from general player lookups. However, it does not explicitly contrast with sibling tools like get_player or search_players, so it isn't a 5.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines2/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description implies when to use the tool (for injury/availability news) but provides no explicit guidance on when to choose it over alternatives such as get_player or search_players. There is no mention of use cases or exclusions, leaving the agent to infer context.

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

• blank_double_gameweeksA
  3.5/5.0
  Behavior2/5

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

  No annotations are provided, so the description carries full responsibility for behavioral disclosure. It states the tool lists data but does not mention that it is read-only, any side effects, assumptions about 'upcoming' definitions, or limitations. For a simple list tool this is somewhat acceptable, but without annotations the agent has no safety or side-effect information.

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

  Conciseness5/5

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

  The description is a single, concise sentence with no filler. It front-loads the core action and result, and every word contributes meaning. Excellent brevity.

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

  Completeness3/5

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

  The tool is simple with no parameters and has an output schema (presumably covering return format). The description adequately states what it does. However, it does not explain domain-specific terms like 'blank' and 'double' gameweeks, nor does it clarify the scope of 'upcoming.' These are minor gaps, but for an AI agent without FPL domain knowledge, additional context would improve completeness.

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

  Parameters4/5

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

  The tool has zero parameters, and the schema coverage is trivially 100%. The baseline for 0 parameters is 4, and the description adds no parameter details because none exist. No additional semantic value is needed.

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

  Purpose5/5

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

  The description uses a specific verb ('List') and a clear resource ('upcoming blank and double gameweeks by club'). It is unambiguous and distinct from sibling tools, which all address different FPL actions (login, team management, player search, etc.). No confusion about what this tool does.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines2/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description offers no guidance on when to use this tool versus alternatives. There is no mention of context, prerequisites, or situations where another tool would be more appropriate. An agent must infer usage entirely from the name and description, which is insufficient.

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

• make_transferA
  3.5/5.0
  Behavior2/5

  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 states it's a transfer (mutation) but does not disclose any constraints: whether the transfer is permanent, whether it respects budget rules, whether it checks for injuries/suspensions, whether it requires any prerequisites (like login or team ownership). It also doesn't mention that team_id is auto-detected (which is in the params anyway). The description does not reveal what happens on failure or edge cases. Given no annotations, this is a significant gap for a mutating tool.

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

  Conciseness4/5

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

  The description is concise and front-loaded with the main action ('Transfer one player out and another in'). The parameter details follow in a clear list. No extraneous content. It could be slightly more compact but is efficiently structured.

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

  Completeness2/5

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

  Given the complexity (a roster mutation with financial implications), the description is too thin. It lacks critical context like whether it validates against budget, whether it considers gameweek deadlines, whether it reflects immediately or after a deadline, what happens if the player isn't in the squad. The description doesn't specify what the output schema contains either (though that's structured), but for a consequential action, an agent needs to know side effects. With no annotations and no such context, the completeness is low.

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

  Parameters3/5

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

  Schema description coverage is 0%, so the description must compensate. It does explain sell and buy as names of players ('Name of a player currently in your squad to sell' and 'Name of the player to buy'). This adds semantic meaning. However, it doesn't clarify any validation or constraints (e.g., must be a valid player name, must be a registered FPL player). team_id is explained as optional with auto-detection. It covers the essential parameters adequately but not deeply, so a 3 is appropriate.

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

  Purpose5/5

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

  The description states a clear verb-resource pair ('Transfer one player out and another in') and specifies the scope (by name, in your squad). It distinguishes from siblings like set_captain, substitute, and play_chip, which handle different roster actions. 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.

  Usage Guidelines4/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description clearly indicates the tool is for player transfers, which distinguishes it from other roster actions. However, it does not explicitly state when not to use it or mention alternatives like transfer_preview or suggest_transfers for pre-checking. But the context is clear enough for most agents, especially with the sibling list. Could be stronger with an explicit 'use transfer_preview to simulate' note.

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

• set_captainA
  3.5/5.0
  Behavior3/5

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

  No annotations are provided, so the description must carry the burden of behavioral disclosure. It states that the team_id is optional and detected from account, which is a useful behavioral note. However, it does not disclose whether setting a captain is a mutation with side effects (like changing points multipliers), whether it overwrites existing settings, or the impact on future gameweeks. The description covers the basic mechanism but misses deeper behavioral context.

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

  Conciseness4/5

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

  The description is concise and front-loads the main action and optionality. It lists parameters in a clear docstring format with brief explanations. It is appropriately sized for a simple tool. Slight deduct for the literal Args: section that repeats parameter names, but overall it is well-structured.

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

  Completeness3/5

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

  Given the tool's simplicity alert list. The output schema is present but the description does not explain the return value (e.g., success confirmation, updated team). It also does not mention constraints such as the player must be in the current squad, or that setting a vice is optional. With 0% schema coverage and no annotations, a full explanation of the effect and return is missing, making it incomplete for an agent to know what to expect.

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

  Parameters2/5

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

  The schema description coverage is 0%, meaning the description must explain the parameters. It does provide some semantics for each parameter: player is the name of the squad player, vice is optional name, team_id is optional and auto-detected. However, it does not clarify the exact format of player and vice (e.g., must be exact matches from the squad), nor the requirement that vice must be a squad player. It also doesn't explain the implication of setting vice (does it also set vice-captain for the same gameweek?). The description adds value but leaves gaps.

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

  Purpose5/5

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

  The description clearly states the action (set) and the resource (captain, optionally vice-captain by name). It distinguishes from siblings like make_transfer, substitute, and play_chip which have different purposes. The scope is specific and unambiguous.

  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?

  The description implies usage (setting captain and optionally vice-captain) but does not explicitly state when to use it versus alternatives like substitute or play_chip. It does not mention any prerequisites such as having a team or being in a gameweek, nor does it note any constraints like only one captain per gameweek. The guidance is adequate but not fully explicit.

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

• get_gameweek_statusA
  3.6/5.0
  Behavior3/5

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

  With no annotations, the description must itself convey behavioral traits. It indicates a read operation via 'Show', but it does not state that it is read-only, whether authentication is required, or what the response shape might be. It is minimally transparent but not exhaustive.

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

  Conciseness5/5

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

  The description is a single, direct sentence that front-loads the key action and what it returns. Every word is necessary, with no redundancy or extraneous detail.

  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?

  The description is sufficient for a zero-parameter tool with a simple output. It covers the essential information (what is shown) and does not need to explain return values because an output schema exists (though not shown). Minor gap: it does not clarify what 'gameweek' signifies, but that is domain knowledge.

  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?

  The schema has zero parameters, so there is nothing to describe. Per the rubric, with no parameters the description cannot add value; the baseline of 3 applies because schema coverage is trivially complete.

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

  Purpose5/5

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

  The description clearly states a specific verb ('Show') and resource ('gameweeks' and 'deadline'), making the tool's purpose unambiguous. It distinguishes itself from sibling tools focused on different data (e.g., team, fixtures) by explicitly saying 'current, previous, and next gameweeks'.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines2/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  No explicit guidance is given on when to use this tool versus alternatives. The description lacks conditions like 'when you need the current gameweek' or exclusions for other scenarios. Given the presence of many sibling tools, this absence leaves usage decisions to the agent's inference.

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

• transfer_historyA
  3.7/5.0
  Behavior3/5

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

  With no annotations provided, the description carries the full burden of behavioral disclosure. It does reveal a key behavior: auto-detection of the user's team when logged in, which is beyond the schema. However, it does not mention what happens if not logged in and team_id is omitted, nor does it indicate read-only status (obvious from 'show'), or any side effects. Some value added, but gaps remain.

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

  Conciseness5/5

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

  Two short sentences, fully front-loaded with the primary purpose. No filler or repetition. Every word contributes to understanding. This is an exemplary concise definition.

  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?

  For a tool with a single optional parameter and an existing output schema, the description covers the core behavior and the auto-detection nuance. It doesn't elaborate on error conditions (e.g., not logged in with no team_id) but the simplicity and presence of output schema make it largely complete. A small gap remains around authentication requirements, but overall adequate.

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

  Parameters2/5

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

  Schema description coverage is 0%, so the description must compensate. It only implicitly references team_id via 'Auto-detects your team,' suggesting team_id is optional or overrides the auto-detection. It never explicitly explains that team_id identifies the target team or what value format is expected. The description adds minimal meaning beyond the schema's default null.

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

  Purpose5/5

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

  The description clearly states the tool's function: 'Show a team's transfers this season.' It uses a specific verb (show) and resource (team's transfers) with a scope (this season), which distinguishes it from sibling tools like make_transfer, suggest_transfers, or get_my_team. The purpose is unambiguous and immediately actionable.

  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?

  The description doesn't explicitly contrast with alternatives, but the phrase 'Auto-detects your team if logged in' gives context for usage—implying team_id is only needed when not logged in or for another team. However, it fails to state clear conditions for when to choose this over transfer_preview or suggest_transfers. Usage is implied rather than explicit.

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

• search_playersA
  4/5.0
  Behavior3/5

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

  No annotations are provided, so the description carries the full burden, but it mostly stays on mechanics (filter values) and only hints at behavior with "best first." It does not clarify sorting details (e.g., whether "best" equals sort_by=points), ties, or whether the result is a lightweight summary versus full player objects. That vagueness is acceptable for a read-only query tool but not more.

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

  Conciseness4/5

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

  The description is a short introductory sentence followed by a compact args list; every line carries information and there is no filler. It is slightly longer than a two-sentence summary would be, but the structured list makes it scan well, and the key purpose phrase is front-loaded.

  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?

  An output schema exists, so return-value documentation is not required. The description covers all parameters, their allowed values, and units, which is sufficient for correct invocation. It could mention that filters are all optional and that an empty call returns the top players by the default sort, but defaults already appear in the schema, so nothing critical is missing.

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

  Parameters5/5

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

  Schema description coverage is 0%, so this description is the only documentation for all six parameters. It explains each one concretely: position values (GKP/DEF/MID/FWD), team name formats with an example (ARS or Arsenal), price units (millions), sort_by choices (points, form, price, ownership, goals, assists), and what limit controls. This fully compensates for the empty schema.

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

  Purpose5/5

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

  The description opens with a clear verb-and-resource statement, "Find players by filters, best first," and the args list enumerates exactly what filters exist. It reads as a general-purpose search tool, which is distinct from siblings like get_player (single player), compare_players (comparison), and suggest_transfers (recommendations), so an agent can tell it apart without inspecting schemas.

  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?

  The description implies when to use it (searching/filtering players) but does not state when not to use it or name alternatives. There are no explicit exclusions or cross-references to sibling tools, so the agent must infer the boundary from the overall tool list. It is adequate but leaves routing to the agent's judgment.

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

• transfer_previewA
  4/5.0
  Behavior4/5

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

  With no annotations, the description carries the full behavioral disclosure burden. It explicitly discloses the key behavioral trait: the transfer is NOT submitted and no mutation occurs. It does not add extra context like auth requirements, but for a read-only preview that is less critical.

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

  Conciseness5/5

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

  The description is one short, front-loaded sentence with no wasted words. It communicates the action and the crucial 'no submission' behavior immediately.

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

  Completeness3/5

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

  The description is strong behaviorally, and the presence of an output schema reduces the need to describe return values. However, it leaves a key gap: the format and meaning of sell/buy parameters and team_id are undocumented, so the agent must infer what values to pass.

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

  Parameters2/5

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

  Schema description coverage is 0%, but the description does not clarify what sell/buy expect (e.g., player IDs, names, or player codes), nor what team_id means. The words 'sell' and 'buy' imply a transfer direction, but that is inferred rather than explained.

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

  Purpose5/5

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

  The description identifies the specific action ('Show what a transfer would do') and explicitly states its scope: funds and position, without submitting. This clearly distinguishes it from siblings like make_transfer and transfer_history.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines4/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description clearly positions the tool as a pre-execution preview, so an agent can infer when to use it before making a transfer. It does not explicitly name the alternative tool or provide formal when-not-to-use guidance, so it stops short of the highest tier.

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

• analyze_mini_leagueA
  4.1/5.0
  Behavior3/5

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

  With no annotations provided, the description carries the burden of behavioral disclosure. It reveals that team_id is optional and detected from the account, implying authentication context, and it scopes the analysis to ~10 managers above/below. However, it does not state whether the operation is read-only, if it has rate limits, or any side effects. It gives some context but not comprehensive behavioral transparency.

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

  Conciseness5/5

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

  The description is two sentences plus an Args list, with no fluff. The purpose is front-loaded, and the parameter explanations are compact. Every sentence earns its place. It is well-structured and easy to parse.

  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?

  Given only 2 parameters (1 required) and an output schema that defines the return structure, the description covers the essential information. It clarifies the scope (classic league, ~10 managers) and parameter behavior. A minor gap is the lack of explicit requirement to be logged in, though 'detected from your account' implies authentication. Overall, it is complete enough 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.

  Parameters5/5

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

  Schema description coverage is 0%, so the description must compensate. It does so effectively by adding an 'Args' section that explains league_id ('The mini-league ID') and team_id ('Optional; detected from your account if omitted'). This provides clear meaning beyond the schema's type/title, fully covering both parameters.

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

  Purpose5/5

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

  The description clearly states the tool's function: analyzing a mini-league by providing the user's rank, edge, and threats compared to nearby managers. The verb 'Spy' is informal but conveys a competitive-analysis purpose, and the resource ('classic mini-league') is specific. It distinguishes itself from siblings like get_league_standings (presumably a simple table) and get_my_team (own team).

  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?

  The description explains what the tool does (analyze rank/edge/threats vs. nearby managers) but does not explicitly state when to use it in favor of alternatives. It implies a deep competitive analysis, but there is no mention of 'if you just need standings, use get_league_standings' or any exclusions. The guidance is implicit rather than explicit.

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

• substituteA
  4.3/5.0
  Behavior3/5

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

  With no annotations provided, the description alone carries the burden of behavioral disclosure. It accurately describes the swap action but does not mention side effects, reversibility, permission requirements, or any validation rules. It is neither misleading nor misleading, but lacks extra detail such as whether the change affects the current or future gameweeks.

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

  Conciseness5/5

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

  The description is succinct and well-structured: one clear sentence for the main action followed by an efficiently formatted Args section. Every word adds value, and the most critical information (what the tool does) is front-loaded.

  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?

  For a simple swap operation with an output schema present, the description covers the essential action and parameters. It could add notes on edge cases (e.g., if the player is already in the XI) but is otherwise complete for an agent to invoke the tool correctly.

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

  Parameters5/5

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

  Schema coverage is 0%, but the description's Args block thoroughly explains each parameter, including the optional team_id. It fully compensates for the schema's lack of metadata, ensuring agents understand the purpose and expected values.

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

  Purpose5/5

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

  The description clearly states the tool's function: 'Swap a bench player into the starting XI and move a starter to the bench.' This specific verb+resource formulation distinguishes it from siblings like make_transfer, set_captain, etc., with no ambiguity.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines4/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description provides clear context for when to use the tool—whenever a player substitution is needed—without explicitly naming alternatives or exclusions. While it doesn't reference sibling tools like make_transfer, the distinct purpose and parameter names make the intended use obvious.

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

• get_my_teamA
  4.4/5.0
  Behavior4/5

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

  No annotations are present, so the description carries the full burden. It discloses the authentication requirement (Bearer token) and the auto-detection behavior for team_id, which are behavioral traits beyond the schema. It does not explicitly confirm read-only status or error handling, but the 'get' verb and output schema suffice for a read operation.

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

  Conciseness5/5

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

  Two sentences plus a parameter note. Purpose is front-loaded, no filler, every sentence earns its place. Extremely efficient.

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

  Completeness5/5

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

  The presence of an output schema covers return value details. The description covers authentication, parameter semantics, and the scope of returned data. For a simple single-parameter read operation, nothing essential is missing.

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

  Parameters5/5

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

  The schema has zero description coverage (0%), so the description must compensate. It fully explains team_id: it is optional, and if omitted, it is auto-detected from the authenticated account. This adds crucial semantic value beyond the bare integer/null schema.

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

  Purpose5/5

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

  The description clearly states the tool retrieves an FPL team and lists the specific contents (starting XI, bench, captain, bank, value, chips). This is a specific verb-resource pairing that distinguishes it from siblings like get_player or get_fixtures.

  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?

  The description gives context (authentication required, optional team_id auto-detection) but does not explicitly state when this tool should be used over alternatives. While the purpose is obvious, no exclusions or alternative routing is provided.

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

• login_to_fplA
  4.8/5.0
  Behavior5/5

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

  The description fully discloses the tool's behavior: it opens a real browser window, requires the user to sign in manually, ensures the password is never seen by the tool or model, and captures the session token for later calls. This transparency is exceptional, leaving no hidden side effects or surprises.

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

  Conciseness5/5

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

  The description is concise, consisting of two short sentences. The first sentence states the primary purpose, and the second elaborates on the process, including security aspects. There is no redundant information, and the structure is front-loaded with the key action.

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

  Completeness5/5

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

  The description provides sufficient context for an agent: it explains the user interaction, the security guarantee, and the outcome (token storage). Since an output schema exists, there is no need to describe return values. The description covers all necessary aspects for correct invocation and expectation.

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

  Parameters5/5

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

  There are no parameters in the input schema, so the description does not need to explain any. The schema coverage is effectively 100% because there are no parameters to document. The description appropriately focuses on the process and outcome rather than parameter details.

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

  Purpose5/5

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

  The description clearly states the tool's purpose: it opens a browser to sign in to Fantasy Premier League and saves the token. The verb 'open' and the resource 'Fantasy Premier League' are specific, and the outcome (saving the token) is unambiguous. It is distinct from sibling tools which focus on data retrieval or actions after authentication.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines4/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description implies that this tool should be used before other calls that require authentication, as it stores a token for later use. However, it does not explicitly state when to use it in relation to alternatives or provide a when-not scenario. The guidance is clear enough for an agent to infer the proper sequencing.

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