league-loom

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

Annotations already indicate safe read operation, but description adds provider-specific behavior: ESPN uses native waiver filter, Sleeper excludes rostered, Fantrax works when public, with details on ranking and fallback. Also explains token inference of league_id and sport. No contradiction with 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?

Description is well-structured with clear purpose sentence, compact args listing, and provider details. Every sentence adds value, though the args list somewhat repeats schema. Front-loaded with key info.

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 11 parameters and no output schema, description covers core behavior, provider differences, defaults, and credential usage. Lacks explicit return format details but mentions response_format parameter. Sufficient for effective use.

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 has 100% coverage, and description adds value by explaining default sort behavior (ESPN vs Sleeper) and provider-specific nuances for credentials and league discovery. Beyond schema, it clarifies parameter usage in context.

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 verb 'list' and the resource 'available players', specifies league-scoped and distinguishes from sibling 'fantasy_get_players' which is global. Explicitly mentions it returns free agents and waiver players ranked best-first.

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?

Clear context provided: it's league-scoped, works with a token to infer parameters, and advises to call fantasy_list_providers first. Does not explicitly state when not to use, but the sibling differentiation provides implied 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 indicate read-only, non-destructive, idempotent behavior. The description adds useful context: automatic player name resolution, Fantrax URL acceptance, and league inference with bearer token. No contradictions.

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?

Concise three sentences with front-loaded key instruction. Lists arguments efficiently. Every sentence adds value, though the list format could be slightly more structured.

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 complexity (7 params, nested credentials, no output schema), the description adequately explains output structure and mentions important behavioral aspects. Could include more on output format options, but schema covers response_format.

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 covers 100% of parameters, so baseline is 3. The description adds value by stating league_id may be inferred and that Fantrax accepts full URL, going beyond schema details.

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 retrieves draft results with specific details (picks, round, team, player, auction bid). It distinguishes from siblings by emphasizing profile-first inference and referencing fantasy_get_my_setup.

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 advises when connected to a profile to not ask for league URL/ID, and to call fantasy_get_my_setup first. Mentions calling fantasy_list_providers (in schema). Provides clear usage context but does not exhaustively list when not to use.

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 indicate read-only, non-destructive, idempotent. Description explicitly states 'Read-only' and describes what the report returns. It adds context about the report content but primarily confirms the annotation hints.

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 concise sentences: first states what the tool does and its output, second lists use cases, third lists parameters with a special note. Front-loaded and efficient, every sentence 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?

Given the number of parameters (6), full schema coverage, and no output schema, the description sufficiently explains what the tool returns (competitive balance, blowouts, checked-out teams). No additional information 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?

Input schema covers all 6 parameters with descriptions. Description adds value by explaining that league_id can be omitted when exactly one league matches a connected profile, which is not evident from the schema alone.

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?

Description clearly states the tool assesses league health with specific metrics (competitive balance, blowouts, checked-out teams). It lists explicit use cases and distinguishes from sibling tools like fantasy_get_standings and fantasy_get_rosters.

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?

Description mentions specific queries like 'how healthy is my league' and 'who's tanking', providing clear context for use. It does not explicitly exclude alternative tools but implies when to use this report vs. other league data functions.

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 indicate read-only and idempotent behavior. The description adds valuable context: auto-detection of user's team for ESPN/Sleeper, inability for Fantrax, and credential requirements for private leagues. No contradiction with 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?

Well-organized with clear sections and bullet points. Front-loaded with key 'profile-first' advice. Slightly verbose, but each sentence serves a purpose—no wasted words.

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?

Covers all major aspects: league identification, team marking, provider quirks, and credentials. Lacks explicit description of the return structure (though response_format gives some hint). Overall adequate for a read-heavy tool without output 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 coverage is 100%, but the description enriches each parameter with platform-specific details (e.g., league_id accepts Fantrax full URL, team_query required for Fantrax). Adds context on when league_id can be omitted and how response_format affects output.

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 it retrieves league name, teams, and settings. It distinguishes itself from the sibling tool fantasy_get_my_setup by noting that league is inferred when a profile is connected, preventing redundant user questions.

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 instructs to call fantasy_get_my_setup first to see configured leagues, and warns against asking for league id when profile is active. Provides separate guidance for Fantrax, including use of full URL or team_query for team identification.

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?

Disclosures beyond annotations (readOnlyHint=true, etc.): inference of league_id with profile token, Fantrax limitations for private/roto leagues, include_players only works on ESPN/Sleeper, live only for ESPN. No contradictions with 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?

Well-structured with clear sections: profile-first note, general purpose, provider-specific, include_players. Each sentence is informative, but slightly verbose. Could be more concise without losing crucial details.

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 10 parameters, 3 providers, nested credentials, and no output schema, the description is fairly complete. Explains return format via response_format parameter. Covers inference and provider constraints. Minor gap: no explicit description of the matchup data structure beyond team totals vs per-player.

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%, but description adds value: explains that league_id may be inferred with profile, league_query is optional filter, include_players defaults and why, live is ESPN-only. Slightly improves on schema descriptions.

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 'Get head-to-head matchups (or live scoreboard) for a week.' This specific verb+resource combination distinguishes it from sibling tools like fantasy_get_standings or fantasy_get_schedule. The profile-first instruction adds uniqueness.

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 tells when to use fantasy_get_my_setup first to avoid asking for league ID. Lists provider-specific constraints (e.g., Fantrax only for public head-to-head, ESPN/Sleeper normally). Recommends calling fantasy_list_providers for capabilities and required credentials.

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 mark as read-only, idempotent, non-destructive. Description adds behavioral detail: aggregates across providers, matches same player across platforms. No contradictions.

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?

Well-structured with summary, usage examples, and arg list. Slightly lengthy but each sentence adds value. Could be more concise.

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?

Despite no output schema, description explains output (exposure map, player list) and context well. Covers prerequisites and read-only nature. Adequate for a complex cross-league tool.

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% with detailed descriptions. Description reiterates optionality and defaults but adds marginal value beyond schema (e.g., 'omit for all sports'). Baseline 3.

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?

Description explicitly states the tool aggregates every player across all leagues and providers, showing exposure. It clearly distinguishes from single-league tools like fantasy_get_my_team by highlighting cross-platform, cross-league functionality.

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 explicit use cases (e.g., 'who do I have everywhere', 'my exposure') and contrasts with single-league tools. Also mentions prerequisite: 'needs a connected profile.'

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, openWorldHint, idempotentHint, and destructiveHint. The description adds valuable context about returning configured leagues/teams and that no arguments are needed, reinforcing the safe, idempotent nature without contradiction.

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 concise and front-loaded: first sentence states purpose, then usage order, then exclusions, then automatic behavior. Every sentence is necessary, 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?

For a read-only, no-arg tool with rich annotations, the description fully covers what it does, when to use it, and what to expect as output (leagues/teams). No gaps given the simplicity.

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 schema covers the single optional parameter with 100% coverage. The description adds 'No arguments needed,' clarifying the optionality. This adds value beyond the schema, justifying a score above baseline 3.

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 shows 'the leagues and teams already configured in the connected profile.' It distinguishes itself from siblings by specifying 'Call this FIRST' and listing items the agent should not ask about, which are likely needed by other tools.

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 'Call this FIRST in a personalized session to see what's set up.' It also instructs the agent to not ask for configuration details because they are already configured, providing clear when-to-use and when-not-to-use 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 indicate readOnly, idempotent, non-destructive. Description adds context: auto-detection for ESPN/Sleeper, token inference, and that Fantrax requires team_query. No contradictions.

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?

Well-structured with clear introductory paragraph, usage guideline, and parameter list. Every sentence adds value, no fluff.

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 8 parameters, no output schema, the description covers the key behavioral aspects. Explains what is returned (standings, matchup, roster) and provider-specific nuances. Slightly missing explicit mention of return types but adequate.

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%, baseline 3. Description adds value by explaining how team_query works (for Fantrax), league_query as filter, and response_format default. Not all parameters need further elaboration.

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 returns a combined snapshot of 'your standing/record, your current matchup, and your roster' for a single league. It differentiates from the sibling 'fantasy_get_my_teams' by emphasizing SINGLE vs plural leagues.

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 advises when to use this tool vs 'fantasy_get_my_teams' based on singular vs plural league queries. Also explains personalization differences between providers (auto-detect vs team_query).

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, etc. Description adds that it 'needs a connected profile' and returns 'the league, your team, rank/record, and this week's matchup', providing useful behavioral context beyond annotations. No contradiction.

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?

Description is concise (~4 sentences). Front-loaded with 'THE HUB VIEW'. Clear structure: purpose, triggers, args/return, alternative/requirement. No unnecessary words.

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?

No output schema, but description explains return values adequately. Mentions auth requirement. With 3 optional params and clear usage guidance, it is fairly complete. Could mention edge cases like no teams found, but not essential.

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% already. Description adds usage context for 'sport' (e.g., 'NFL' for football teams) and explains optionality. It also notes that omitting provider aggregates across all. This adds value beyond schema descriptions.

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?

Description clearly states it aggregates user's teams across all leagues and providers. Uses specific verb 'aggregate' and resource 'user's teams across ALL their configured leagues and providers'. Distinguishes from sibling 'fantasy_get_my_team' by specifying cross-league scope.

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 lists when to use: 'whenever they ask about "my teams", "my football teams", "how am I doing", "my week", or anything plural/cross-league'. Also states when NOT to use and provides alternative: 'For a single named league, use fantasy_get_my_team instead.'

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 indicate readonly, idempotent, open-world, non-destructive. Description adds behavioral details: returns live data, supports specific providers (ESPN, Fantrax, Sleeper), and explains what each provider returns (e.g., ESPN returns free agents/waivers with % owned and season actual+projected points). No contradictions.

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 long but well-structured with bullet points, bold key phrases, and clear sections for provider-specific information. Every sentence adds value, and the main purpose is front-loaded. Slightly verbose but not wasteful.

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?

Despite no output schema, the description compensates by explaining what each provider returns (free agents, ownership, projections, etc.). It covers the tool's scope, limitations (e.g., Sleeper per-week scoring from box scores via other tool), and parameter usage hints. For a complex tool with 18 parameters and no output schema, this is fairly complete.

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 baseline is 3. The description adds overall context but does not provide per-parameter details beyond what the schema already includes. It mentions that league_id and sport are inferred with a profile token, adding some value, but not enough to raise the score.

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 retrieves 'live, league-scoped player data' with specifics: identity, availability, % owned, season fantasy points, projections. It distinguishes from stale memory/rankings and lists supported providers, making the purpose 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 explicitly instructs to 'PREFER this tool's retrieved stats over your own memory or stale rankings' and notes that per-week scoring from Sleeper comes from fantasy_get_matchups. It provides context for when to use it, though it does not explicitly exclude sibling tools like fantasy_get_available_players.

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, openWorldHint, and destructiveHint=false, covering safety. The description adds minimal behavioral context beyond stating it searches/lists player references. It does not disclose whether results are paginated or how credentials affect the returned data.

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 lines plus a compact arg list with no fluff. The purpose is front-loaded, and every sentence contributes to understanding the tool's function and key constraints.

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?

Despite no output schema, the description indicates the returned mapping (id ↔ name/position/team), which is adequate for a reference tool. It covers required parameters and credential hints, though pagination behavior 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%, so baseline is 3. The description summarizes key parameters (provider, sport required; query optional; limit; season for espn; credentials) in a concise way that aids quick understanding, adding value beyond the schema's individual descriptions.

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 it searches/lists a provider's player reference for a sport, mapping IDs to names/positions/teams. This distinguishes it from siblings like fantasy_get_player_data (specific player data) and fantasy_get_available_players (available players in a league).

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 advises calling fantasy_list_providers first to check capabilities and credentials, and notes that season is required for ESPN and Sleeper. It implies this tool is for player reference lookups rather than game-specific data, but does not explicitly contrast with alternatives like fantasy_get_my_players.

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, openWorldHint, idempotentHint, destructiveHint=false. Description adds context about profile inference, provider-specific constraints (e.g., Fantrax needing sport and team_query for name resolution), and no contradictions.

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?

Description is comprehensive and front-loaded with key guidance. While slightly verbose, every sentence adds value. Could be tightened slightly, but remains clear and well-structured.

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 9 parameters, 3 providers, no output schema, the description thoroughly covers all aspects: profile inference, provider behaviors, parameter roles, and edge cases like Fantrax league URL acceptance. Highly complete.

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%, but description adds significant meaning: explains inferred parameters (league_id, team_query with profile), why team_query is required for Fantrax, and how sport enables name resolution. Enhances agent understanding beyond schema.

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?

Description clearly states 'Get every team's roster with player names, positions, and slot/status.' It distinguishes from siblings by emphasizing profile-first inference and cross-provider nuances.

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 tells agents not to ask for league/team when profile is connected ('don't ask the user for league url/id or team name/id'), directs to fantasy_get_my_setup for setup info, and provides provider-specific guidance for 'My roster' and team_query requirements.

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. The description adds valuable context: the playoff math is exact deterministic arithmetic (not simulation), platform-specific performance (Sleeper is slower), and missing tiebreaker modeling. This goes 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?

The description is well-structured with a clear intro, use cases, argument list, and platform notes. It is front-loaded with the important 'profile-first' instruction. While it is lengthy, every sentence adds value, and the structure makes it easy to scan.

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 10 parameters, no output schema, and nested objects, the description is thorough. It explains what the tool returns (schedule, strength, playoffs), platform differences (Fantrax partial support), and format options. It lacks a detailed output structure but covers essential aspects for effective use.

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%, baseline is 3. The description adds significant meaning: explains team_query usage with star marking, REQUIRED for Fantrax, and how to get team IDs; clarifies credentials per platform; describes view options with examples. This improves parameter understanding.

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 explicitly states that the tool returns the full-season head-to-head schedule, strength of schedule table, and deterministic playoff picture. It clearly differentiates from siblings like fantasy_get_standings or fantasy_get_matchups by focusing on schedule and playoff math, and it provides specific use cases.

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 clear usage context: it mentions profile-first inference and recommends calling fantasy_get_my_setup for configuration. It lists example queries ('who has the easier schedule', 'am I in the playoffs'). It also details platform-specific capabilities and limitations, but does not explicitly compare to all 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?

Annotations indicate readOnlyHint, openWorldHint, idempotentHint, destructiveHint=false. The description adds valuable context: standings are derived from team records, Fantrax league_id accepts full URL, and how 'your team' auto-detection works with ESPN/Sleeper but requires team_query for Fantrax.

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?

Well-structured with front-loaded key behavior (profile-first) and organized parameter explanations. Could be slightly more concise, but no unnecessary 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?

With 8 parameters, 1 required, nested objects, and no output schema, the description adequately covers usage scenarios, provider differences, parameter details, and return format options. Leaves little ambiguity.

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%, providing baseline 3. The description adds extra meaning for team_query (explains why required for Fantrax), league_id (URL accepted), and credentials (directs to fantasy_list_providers), enhancing understanding beyond schema.

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 it retrieves league standings (rank, record, points for/against) and distinguishes itself from siblings by noting the profile-first approach and referencing fantasy_get_my_setup for configuration.

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 explicit guidance: when connected with a profile, league and team are inferred, and advises using fantasy_get_my_setup for setup info. Also gives provider-specific instructions for Fantrax, ESPN, Sleeper.

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 convey read-only, open-world, idempotent, non-destructive. The description adds provider-specific behaviors (Sleeper requires week, ESPN returns recent moves regardless, Fantrax only public leagues) and states it's read-only. No contradictions.

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?

Well-structured: first sentence defines purpose, then bullet points for Args and Coverage. Front-loaded with key info, no fluff. Every sentence serves a clear purpose.

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 10 parameters (many optional), annotations covering safety, and no output schema, the description thoroughly covers provider-specific behavior, credentials, and output format. It leaves no significant gaps for an AI agent.

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 covers all parameters with descriptions (100% coverage). The description adds value by explaining the profile-first approach, clarifying the week parameter per provider, and instructing not to ask for league url/id. This goes beyond schema basics.

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 explicitly states it reads recent league moves (adds, drops, waivers, trades) newest first, clearly distinguishing it from sibling tools that handle players, drafts, or other 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?

Provides clear context: 'Profile-first: the league is inferred when connected, so don't ask for a league url/id.' Also details coverage per provider, indicating when each applies. Could explicitly contrast with tools like fantasy_get_draft or fantasy_get_rosters but overall gives good 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 mark readOnlyHint=true and destructiveHint=false. The description adds that the data is a 'live waiver-wire signal' and explicitly says 'Read-only,' reinforcing safety. No contradictions; the added context is helpful but not extensive.

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 plus a concise argument listing. Every word adds value, no repetition, and the most critical information (use cases and provider limitation) 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?

For a read-only trending tool with no output schema, the description adequately conveys the conceptual result ('most-added or most-dropped players'). It mentions response_format parameter but not pagination; however, the parameter descriptions in the schema cover details. Given 7 parameters and full schema coverage, completeness is sufficient.

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 description summarizes key args (provider, sport, direction, lookback_hours, limit) and notes provider must be 'sleeper', adding context beyond the schema's enum list. No param details are misleading, and the description complements the schema.

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 returns 'most-added or most-dropped players across the whole platform right now,' using a specific verb (get) and resource (trending players). It differentiates from siblings like fantasy_get_available_players and fantasy_get_transactions by focusing on platform-wide waiver trends.

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 advises use cases: 'who's trending', 'hot waiver adds', 'who's everyone dropping'. It also clearly states that Sleeper is the only supported provider, warning that ESPN and Fantrax do not expose platform-wide trends, thus guiding when not to use the tool.

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 no destruction. The description adds that the tool requires a connected profile and is read-only, and that include_waivers=false reduces latency. This adds useful 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?

The description is informative but somewhat verbose, with an initial bold 'THE NEWSLETTER.' and a list of contents. It could be tightened while retaining clarity. Still, it is well-structured 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?

Given no output schema, the description reasonably outlines the return content (standing, matchup, alerts, waivers) and acknowledges the response_format parameter. It covers what the agent needs to know about the digest's scope and optional features.

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 baseline is 3. The description adds value by explaining the trade-off of include_waivers (faster digest), and clarifies that sport and provider are filters that default to 'all'. This goes beyond the schema's minimal descriptions.

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 identifies the tool as a cross-league weekly digest ('newsletter across all your teams'), enumerates the content (standing, matchup, roster alerts, top waiver-wire add), and explicitly distinguishes it from sibling tools like fantasy_get_my_team for single-league queries.

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 provides explicit usage triggers ('weekly newsletter / rundown / recap', 'how did all my teams do'), mentions optional filters for sport and provider, and notes that include_waivers=false yields a faster digest. It also directs to a sibling for single-league use. Lacks a direct 'when not to use' statement but is still 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?

Annotations already indicate safe read operation (readOnly, idempotent, non-destructive). Description adds detail on return content (catalog with availability and capability flags), enhancing transparency beyond 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?

Two sentences plus a 'Returns:' line, front-loaded with key action. No wasted words, concise yet informative.

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?

Tool is simple with one optional parameter. Description explains return value (catalog of providers) which is crucial since no output schema. Positioned well among many sibling tools.

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?

Only one parameter (response_format) with full schema coverage (100%), so baseline is 3. Description does not add extra meaning to the parameter, but schema already covers it sufficiently.

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?

Description clearly states the tool lists supported fantasy platforms with capabilities, sports, and credentials. It distinguishes itself by noting it's the best first call and provides arguments needed for other tools.

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 'ALWAYS the best first call', providing strong guidance on when to use. Also explains it informs arguments for other tools, though no explicit when-not scenario is given.

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?

Beyond annotations (readOnlyHint, openWorldHint, idempotentHint), the description adds behavioral context: bearer token bypasses per-call credentials, and Fantrax may return empty results that don't imply absence of leagues. This supplements the already strong annotation coverage.

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 concise yet comprehensive: one paragraph with clear separation of purpose, credentials, and provider-specific notes. Every sentence adds value, with no redundancy or 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 is complex (multiple providers, varied credentials, edge cases), and the description covers all key aspects. While it lacks explicit output format details beyond the response_format parameter, the parameter itself addresses that. Slightly more detail on returned data structure could elevate it, but overall it's quite complete.

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 baseline is 3. The description adds value by explaining credential requirements per provider, clarifying which params are required (e.g., season for ESPN/Sleeper, not for Fantrax), and describing the response_format default. This goes beyond the schema descriptions.

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 purpose with a specific verb ("Discover") and resource ("leagues a user belongs to on a provider"). It distinguishes itself from siblings like fantasy_list_providers (which lists providers) and other league-specific tools by focusing on user's leagues across providers.

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 provides explicit when-to-use guidance: it explains the bearer token shortcut for authenticated users and gives provider-specific credential requirements. It also addresses edge cases like Fantrax empty results, advising fallback to direct league-scoped tools, and references fantasy_list_providers for capabilities.

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 indicate read-only and non-destructive behavior. The description adds context about the wizard link and reconnect steps, explaining how the read-only constraint is implemented.

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?

Description is concise, front-loads purpose, and provides examples without unnecessary words. Every sentence adds value.

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 low complexity (1 optional param, no output schema), the description covers what the tool does, when to use it, and what it returns (wizard link + steps). Slightly improved by noting response formats, but the param covers that.

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 parameter. The description does not add extra meaning beyond the schema's description of 'response_format' enum. 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 clearly states the tool's purpose: adding, removing, or fixing league/team connections. It distinguishes from sibling 'get' tools by being the only management tool.

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 states when to call with user intent examples (e.g., 'I also have an ESPN league'). Clarifies it returns steps rather than directly mutating, setting clear expectations.

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