league-loom

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

Annotations already declare readOnlyHint/idempotentHint/destructiveHint, so the safety profile is covered. The description adds genuinely useful platform-specific behavior: ESPN ranking by % owned + projected points, Sleeper relevance rank, and the Fantrax ADP-backed fallback for non-public leagues — value beyond what annotations provide.

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 compact paragraphs with every sentence earning its place; purpose and scope are front-loaded in the first sentence, sibling routing follows immediately, and the platform-support paragraph adds concrete data without 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 an 11-parameter, three-platform tool with no output schema, the description covers scope, exclusions, platform behavior, fallback, and sibling routing. The main omission is explicit return-format details, though the response_format parameter and platform data descriptions largely mitigate this.

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

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

Schema description coverage is 100%, so the schema carries the parameter documentation. The description adds platform-specific ranking semantics for the 'sort' parameter (ESPN % owned, Sleeper relevance rank) and the Fantrax fallback, which the schema's enum alone cannot convey, but it does not elaborate individual parameters. 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 opens with a specific verb+resource ('Browse the pool of players you can ADD') and states the one-league scope explicitly, then names sibling tools (fantasy_get_player_data, fantasy_get_weekly_digest) for adjacent cases and excludes rostered players, making selection unambiguous.

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

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

Explicitly names alternatives with the conditions that select them: fantasy_get_player_data for a specific named player, fantasy_get_weekly_digest for cross-league waiver suggestions. The 'in ONE league' scope further clarifies when this applies versus roster views (fantasy_get_rosters/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 cover read-only/idempotent behavior. The description adds non-schema value: profile-first league inference, automatic player-name resolution, and season-based lookup for past drafts.

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 tight sentences: the first states the result shape, the second gives usage examples and behavior. Key information is front-loaded with no repetition of schema 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 full schema coverage and an annotations safety profile, the description supplies what is missing: output fields, profile-first behavior, and past-season usage. It does not route against sibling tools, but sibling names make that less critical.

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 7 parameters in depth, so the description is free to add only natural-language meaning: season as 'show my draft from last year' and 'where applicable' for auction bids. This modestly exceeds 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?

States a specific verb and resource: returns draft results with picks (round/overall), team, player, and auction bid where applicable. This clearly distinguishes it from sibling tools like rosters, standings, or schedule.

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 invocation context: pass season for a past year's draft and rely on profile-first league inference when connected. Does not explicitly name alternatives or exclusions, but the usage is concrete and actionable.

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

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

Annotations declare readOnlyHint=true and destructiveHint=false, so the agent already knows it's a safe read. The description adds that the tool is profile-first (league inferred when connected), which is a key behavioral trait beyond the schema. However, it does not specify what happens when no profile is connected (e.g., does it error or require league_id?), which is a minor gap given the openWorldHint.

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, tightly packed with value. The main purpose is front-loaded with 'THE COMMISSIONER REPORT' and the key outputs are listed immediately. The 'Profile-first' note is a useful addition. No wasted words, but 'Use for' list could be slightly trimmed, though it adds clarity.

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

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

The tool has 6 optional parameters and no output schema. The description explains what the report contains but does not specify the return format (beyond response_format parameter) or how it handles missing profile/connection. Given the complexity of profile inference and multiple providers, an agent might need more guidance on error states or default behavior. The description is adequate but leaves some edge cases uncovered.

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% (all 6 parameters have descriptions in the schema), so baseline is 3. The description does not add any parameter-level meaning beyond the schema; it only mentions the tool is profile-first)Skip. There is no information about how league_query interacts with profile inference, or whether sport/season are required when no profile is connected. The description fails to compensate for the schema's minimal parameter details, and the schema descriptions are generic (e.g., 'League name/id filter').

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 produces a 'commissioner report' covering competitive balance, blowouts, and inactive teams. It distinguishes itself from siblings by focusing on league health metrics rather than raw standings or matchups, and the verb 'get' plus specific resource 'league health' is unambiguous.

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

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

The description explicitly says when to use it: for questions like 'is my league healthy/competitive', 'who's tanking', or a state-of-the-league summary. It does not name specific alternatives or exclusions, but the use-cases are clear enough to route an agent. Sibling tools like fantasy_get_standings or fantasy_get_rosters are implied alternatives, but no direct comparison 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?

Annotations already mark the tool as read-only, idempotent, and non-destructive. The description adds meaningful behavioral detail beyond that, including platform-specific behavior for Fantrax (no owner data, full league URL accepted) and ESPN/Sleeper auto-detection of the user's team. This helps set expectations without contradicting 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 dense but front-loaded, with the core purpose stated first and platform details in a secondary paragraph. Some points repeat the schema's parameter descriptions, but the overall structure is efficient and scannable.

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

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

For a tool with 8 parameters and no output schema, the description covers the essential behavioral context: what the tool returns, when to avoid passing ids, how Fantrax differs, and how to mark the user's team. It is complete enough for an agent to invoke the tool correctly, though it does not explain the response envelope.

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

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

The input schema covers all 8 parameters with descriptions, so the baseline is 3. The tool description adds extra meaning by clarifying team_query's role in marking the starred team, the Fantrax league_id URL possibility, and the profile-first inference model. This goes beyond simply restating 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 a league's name, teams, scoring, and key settings, and highlights that it is the source of team ids for team_query. This distinguishes it from sibling tools like fantasy_get_league_health or fantasy_get_standings, making the purpose specific and actionable.

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 practical guidance: the league is inferred when a profile is connected so users should not ask for ids, and Fantrax requires team_query because it exposes no owner data. It does not explicitly name alternative tools or say when not to use this tool, but the context is clear and useful.

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

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

Annotations already cover read-only, idempotent, open-world, and non-destructive safety. The description adds substantial behavioral context beyond that: return contents (league points, projections, raw stats/game progress, retrieval time, provisional/final status), provider variability, snapshot-vs-streaming behavior, and Fantrax restrictions.

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 dense but front-loaded: purpose first, then usage conditions, return shape, provider caveats, and Fantrax limits. Every sentence contributes operational information, with no filler. The length is justified by the tool's 11-param complexity.

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

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

With no output schema, the description steps in to explain what is returned, including points, projections, raw stats, game progress, retrieval time, and status. It also covers provider-specific behavior, auth/profile assumptions, and Fantrax limitations. Given the rich schema and annotations, nothing essential is missing for correct invocation.

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

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

Schema description coverage is 100%, so the schema already documents all 11 parameters thoroughly. The description adds practical meaning for team_query and the live/include_players combination, but it does not add equally useful semantics for every parameter. This exceeds the baseline 3 but is not a full parameter reference.

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

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

The description opens with a specific verb and resource: current head-to-head scoring or a requested matchup period. It distinguishes this tool from season-level player data by stating 'season player data is not live scoring.' An agent can identify it as the live/box-score matchup tool without ambiguity.

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

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

It gives clear usage contexts ('how am I doing right now', 'who is scoring', mid-game updates) and parameter guidance (live=true, include_players=true). It also provides an explicit exclusion for season player data and provider limitations for Fantrax. However, it does not name a sibling tool to use instead for season player data, which keeps it from full routing clarity.

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?

The annotations already declare readOnlyHint=true, openWorldHint=true, idempotentHint=true, destructiveHint=false, and the description is consistent with them, so no contradiction. Beyond that, the description adds the prerequisite that it "needs a connected profile" and explains that it returns data "matched across platforms" – extra context an agent needs to set expectations. This is useful, though it doesn't mention rate limits or caching, which are not critical here.

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, front-loaded with the core purpose ("YOUR EXPOSURE MAP: ..."), followed immediately by concrete example queries. There is no filler or redundant commentary; every clause adds value to the agent's understanding.

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

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

For a zero-required-parameter, read-only retrieval tool with no output schema, the description covers the essential contract: what it returns (players ranked by how many teams hold them), the prerequisite (connected profile), and the intended use cases. It doesn't describe the exact shape of the ranked output, but given the rich schema for response format and the lack of output schema, this is acceptable. A slightly higher score would risk over-crediting a description that optionally already has schema to lean on.

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

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

Schema description coverage is 100%, so each parameter (sport, provider, response_format) is already documented with type, default, and examples. The description does not add any parameter-specific nuance; it references the broad absence of filters ("ALL configured leagues and providers") but doesn't elaborate on how the optional filters modify the result. The baseline 3 is appropriate since the schema handles parameter semantics.

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 is concrete: "every player you roster across ALL configured leagues and providers, ranked by how many of your teams hold them." It names the specific resource (the user's exposure map) and clearly differentiates from sibling tools like fantasy_get_my_team and fantasy_get_my_teams by its cross-league, cross-provider scope. The verb and intended output are unambiguous.

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

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

The description provides clear user intents with quoted use cases ("who do I have everywhere", "my exposure"), which helps an agent map natural-language requests to this tool. It doesn't explicitly say 'don't use for single league or team', but the phrase "ALL configured leagues and providers" and the title's "exposure across every league" communicate the distinct context versus more focused roster 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?

The annotations already mark the tool as read-only, idempotent, and non-destructive, but the description adds a crucial behavioral fact: the setup is sealed into the token and only changes via /setup plus reconnect. It also warns against instructing users to remove the connector, which prevents a harmful action the annotations alone would not reveal. There is no contradiction with 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 long but every sentence earns its place: purpose, trigger phrases, token-sealed behavior, no-credentials rule, and replacement context. The purpose is front-loaded in the opening sentence, so an agent can classify the tool immediately without wading through caveats. The length is justified by the behavioral cautions it conveys.

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

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

For a simple read-only setup tool with one optional argument, the description covers the output concept (leagues, teams, add/remove steps), when to invoke it, and the essential token-reconnect caveat. There is no output schema, but the response_format parameter lets the agent choose markdown or JSON output. Nothing an agent needs to call it correctly is missing.

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

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

The only parameter, response_format, is already fully described in the schema with an enum, default, and description, so schema coverage is 100%. The description's 'No arguments needed' is consistent but redundant given that required parameters are 0 and the default is documented. The description adds no real meaning beyond 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 first sentence names a specific verb and resource: it 'shows' the 'leagues and teams configured in the connected profile'. The '(whoami)' framing and the mention of add/remove setup steps separate it from live-data siblings like fantasy_get_my_teams or fantasy_get_league_info. The scope is unambiguous even without naming a sibling.

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 says to call this tool FIRST in a personalized session and maps concrete user triggers ('I also have an ESPN league', 'I started a new league', 'update my teams') to it. It also gives a firm negative rule: never tell the user to remove the connector. This is strong, actionable when-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 already declare readOnlyHint=true, idempotentHint=true, destructiveHint=false, covering the safety profile. The description adds valuable context about inference (league and team inferred when connected) and platform-specific auto-detection, going 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?

Three sentences with no filler: purpose is front-loaded, exclusions and alternatives are explicit, and platform nuances are concise. 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?

For an 8-parameter tool with no output schema, the description provides a clear idea of the return content (standing, matchup, roster) and critical usage constraints. It covers platform differences and inference behavior, leaving nothing essential unclear. A slightly higher score is withheld only because it doesn't hint at the response format (markdown vs json) or error cases, but these are minor given the schema's thoroughness.

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

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

Schema coverage is 100%, and each parameter has a detailed description (e.g., team_query's exact id preference, credentials conditions, response_format enum). The description itself does not add parameter meaning beyond the schema, so the baseline of 3 is appropriate.

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

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

The description states a specific verb (get) and resource (my team), and clarifies it returns standing, current matchup, and roster together. It also explicitly contrasts with the plural variant fantasy_get_my_teams, distinguishing scope without ambiguity.

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 defines when to use this tool (single league) and when not ('anything plural'), naming the alternative directly. It also gives platform-specific guidance (Fantrax requires team_query; ESPN/Sleeper auto-detect) and notes the profile-first inference behavior.

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

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

Annotations already declare readOnly/idempotent/non-destructive, so the safety profile is covered. The description adds genuinely new behavior: comparison_snapshot expires after 24 hours, cannot authorize account access, and must be kept private and passed unchanged. It does not describe pagination or result-size limits, so not a full 5.

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

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

Front-loads the most important behavioral rule (render a separate section per team) and keeps one idea per sentence. It is dense and mixes render instructions with parameter guidance, which lengthens it slightly beyond strict necessity, but every sentence carries actionable content.

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

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

With no output schema, the description carries the return-shape burden and does so: it describes what each view returns (compact starter highlights, game-progress coverage, standings/totals) and the per-team section formatting requirement. Nothing needed to call it correctly is missing.

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

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

Schema description coverage is 100%, so the baseline is 3; the description adds meaning beyond the schema by explaining the snapshot's 24-hour expiry and its non-authorizing nature, and by giving the 'my football teams' example for the sport param. It largely restates the view enum semantics already documented in 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?

States a specific verb+resource ('Your personal scoreboard... across connected teams') and explicitly scopes it as plural/cross-league, distinguishing it from the singular sibling 'For one named league's detail, fantasy_get_my_team.' The three view modes are named and given distinct meanings.

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

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

Gives explicit routing: use for anything plural or cross-league, pass sport for 'my football teams', and points to fantasy_get_my_team for a single named league. Each view has a stated purpose ('view=kickoff for am I ready for kickoff, empty slots, injury checks').

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

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

Annotations already declare readOnly/idempotent/non-destructive, so the description builds on that with per-provider coverage notes, the five-player research cap, 'Missing feeds/fields are explicitly unavailable', and a prompt-injection warning that news is untrusted material, never instructions. That last point is high-value safety 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?

Purpose and the preferred-over-memory directive are front-loaded, and the provider/research detail follows in a structured block. It is dense rather than padded, though the provider/parenthetical listing is long enough that a little tightening would help.

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

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

For an 18-parameter tool with nested credentials and no output schema, the description covers provider defaults, credential requirements, the query-vs-player_ids disambiguation, and research limitations. Only minor gaps remain, such as pagination or the shape of the returned payload, which is acceptable without an 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%, so the baseline is 3, but the description adds real meaning: include_history/include_splits require an explicit season, research_sources/history_limit/split_limit narrow results, and it warns to keep source/season/week/scoring distinct since public preset totals are NOT league-scored points.

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

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

States a specific verb+resource with scope ('SPECIFIC named players — rostered or not') and enumerates the data returned (stats, projections, ownership, availability, injury, ids). It explicitly differentiates from the sibling by naming fantasy_get_available_players as the browse alternative.

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

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

Gives an explicit when-to-use directive ('PREFER its retrieved stats over your own memory or stale rankings for any in-season player question') and an explicit when-not ('NOT for browsing who to add — that's fantasy_get_available_players'), plus the input requirement (query or player_ids).

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

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

Annotations already declare readOnlyHint, idempotentHint, and destructiveHint=false, so safety is covered. The description adds valuable behavioral context: provider differences (Fantrax lacks owner data), the star marking for the queried team, and credential nuances for private leagues. It does not contradict 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: front-loaded with the core purpose, then provider-specific guidance, and ends with a pointer to an alternative. It uses semicolons for compactness and avoids redundancy. Slightly long but each 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 the tool's complexity (9 parameters, multiple providers, no output schema), the description covers essential behaviors: provider differences, credential requirements, and the star-marking behavior. It could mention what happens when no profile is connected, but the credentials parameter covers that. Overall sufficient for correct invocation.

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

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

Schema description coverage is 100%, so parameters are already documented. The description adds meaning beyond the schema, particularly for team_query (marks ⭐, required on Fantrax, auto-detected elsewhere) and provider-specific behavior for sport and season. This extra context helps agents choose and fill parameters correctly.

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: retrieving every team's roster with player names, positions, and slot/status, and notes the team_query filter for a single team. It distinguishes from siblings like fantasy_get_my_team and fantasy_get_my_players by scope (all teams vs. own team) and content (roster vs. players).

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

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

The description explicitly explains when to use this tool versus alternatives, including provider-specific requirements (Fantrax needs sport and team_query, ESPN/Sleeper auto-detect) and a pointer to fantasy_get_my_team for a combined roster+standing+matchup call. This is actionable 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?

The description adds key behavioral context beyond annotations: determinism (clinches are guarantees, not simulations), provider differences (Fantrax partial features), and speed notes (Sleeper slower). This complements the readOnlyHint and idempotentHint 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 dense but each sentence contributes: core function, use cases, view selection, provider differences. It is structured with a colon and semicolon to separate ideas, though slightly long. It front-loads the purpose and essential usage before 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, multiple providers, and no output schema, the description covers what is returned (schedule, SOS, playoff picture), how to navigate sections via view, provider limitations, and credential needs. 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.

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

Schema coverage is 100%, so the baseline is 3, but the description enriches parameters: view is explained with examples, team_query notes Fantrax requirement and source from fantasy_get_league_info, and credentials details are clarified. It adds meaningful guidance beyond schema text.

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 schedule, strength of schedule, and a deterministic playoff picture with exact arithmetic. It gives concrete use cases and specifies the resource, distinguishing it from sibling tools like matchups or standings.

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

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

It explicitly lists when to use this tool ('am I making the playoffs', 'who's clinched', etc.) and notes the view parameter to pick a section. It also mentions provider-specific behaviors and profile-first league inference, giving clear context for selection.

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 the readOnlyHint/idempotent annotations, the description adds real behavioral nuance: it reveals that league inference depends on a connected profile, and that provider-specific behaviors like auto-starring differ. This is beyond the annotation's safety-only signal.

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 three short, front-loaded sentences: it leads with the result, then gives provider/profile inference details. No filler, no repetition of schema properties; every phrase 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 8 parameters and no output schema, the description adequately explains the returned content (rank, record, points for/against) and the provider-specific requirements for invoking the tool, leaving little ambiguous about the tool's function and purpose in a typical use case.

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's mention of team_query requirement on Fantrax and the inferred league when connected adds a marginal provider-driven semantic that the schema already partially covers, but it doesn't substantially compensate for the parameter depth.

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 opening phrase 'League standings: rank, record, points for/against' clearly states the resource and content returned. It conveys a read operation on the standings entity, though it does not explicitly differentiate from sibling tools like fantasy_get_league_info or fantasy_get_matchups.

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 provider-specific guidance ('Profile-first: league inferred when connected' and 'Fantrax needs team_query') and implies when the tool should be used, but it lacks any when-not-to-use direction or explicit alternative routing to the sibling standings-related 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?

The description goes well beyond the read-only Hint by disclosing important behavioral nuances: profile-first league inference, newest-first ordering, per-platform differences (FAAB bids for Sleeper, partial trade legs on ESPN, public-only visibility on Fantrax). This prepares the agent for platform-specific results beyond a generic 'get transactions'.

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 compact, front-loaded, and information-dense. Every sentence serves a purpose: the first defines scope, the second gives usage context, and the third covers platform-specific caveats. No filler or repetition of the title.

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 description covers what the tool returns, ordering, league inference, and key per-platform differences. It does not describe output schema or fields, but given this is a list retrieval operation, the level of context is adequate for an agent to decide when to call it and what to expect. A minor gap is lack of explicit error/auth context (e.g., Fantrax public-only).

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

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

With full schema parameter descriptions, the description still adds value by explaining profile-first league inference (why league_id may be omitted) and by reinforcing 'newest first' ordering semantics for limit. It also introduces functional context (FAAB, trade legs) not present in the schema. It does not deeply explain sport or week across platforms, but those are covered in schema/type 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 resource ('recent league moves') and enumerates the types of transactions (adds, drops, waiver claims, trades). It even provides user-facing example questions ('did my waiver claim process?') that make the purpose immediately understandable. The ordering ('newest first') further clarifies behavior.

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 practical usage context: 'Profile-first: league inferred when connected' tells the agent when league_id may be omitted quoted. It also provides per-platform call-outs (Sleeper per-week with FAAB, ESPN activity feed/trade-leg caveat, Fantrax public-only) that guide expectations. It does not explicitly name alternative sibling tools, but the platform notes supply usable decision context.

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

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

Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the safety profile is covered. The description adds valuable behavioral context: it emphasizes that the data is platform-wide, not league-specific, and not availability-aware, which prevents misuse. It also clarifies that Sleeper data is the default and that the tool is not for league-specific actions. This goes beyond the annotations without contradicting them.

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 long, front-loaded with the core purpose, and includes a clear exclusion and alternative. Every sentence earns its place, and there is no redundant 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?

Given the tool's complexity (7 parameters, 1 required, 3 enums, nested credentials object) and the absence of an output schema, the description is quite complete. It covers the core behavior, the key limitation (not availability-aware), and the alternative. It doesn't describe the return format, but the response_format parameter handles that, and the description's focus on usage guidance is appropriate. A 4 is warranted because the description could have added a bit more about the output structure, but it is largely 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 description coverage is 100%, so the schema already documents all parameters. The description adds context by explaining the meaning of 'trending' (platform-wide adds/drops) and by clarifying the distinction between this tool and fantasy_get_available_players, which helps an agent understand the 'direction' and 'provider' parameters. However, it doesn't add much detail beyond the schema for individual parameters, so a 4 is appropriate rather than a 5.

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

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

The description clearly states the tool's function: retrieving the most-added or most-dropped players platform-wide. It uses specific verbs ('most-added or most-dropped') and a clear resource ('players across the whole platform right now'), and it explicitly distinguishes itself from fantasy_get_available_players, which is a sibling tool. The title and description align well.

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

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

The description explicitly states when to use this tool ('who's trending', 'who's everyone dropping') and when not to use it ('not league-specific and not availability-aware'), and it names the alternative tool (fantasy_get_available_players) for league-specific, availability-aware needs. This is clear, actionable 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 readOnly/idempotent/non-destructive, and the description adds substantial behavior beyond that: profile requirement, conditional team-based content, missing-data warnings, and an important caveat that waiver candidates are options to review, not proven upgrades. 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?

Every sentence earns its place: core purpose first, then conditional behavior, usage triggers, parameter guidance, and a caveat. It is compact relative to the tool's complexity and contains no filler.

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

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

Given no output schema, the description explains the expected content of both the league-overview and identified-team cases. It also covers prerequisites, exclusions, alternatives, and data-quality caveats, making it complete enough for reliable invocation.

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

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

Schema description coverage is 100%, so the schema already documents parameters. The description further enriches league_query semantics by explaining when to pass it and the fallback behavior when omitted, which is valuable beyond 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 states a concrete verb ('return') and resource ('weekly report'), and specifies both the single-league and all-leagues scope. It also differentiates itself by naming fantasy_get_my_team as the simple single-team snapshot alternative.

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 triggering user intents ('what needs attention this week', 'my weekly rundown/recap', waiver review), instructs when to pass league_query vs. omit it, and calls out the connected-profile prerequisite. This gives an agent clear selection and invocation criteria.

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

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

Annotations already cover read-only, idempotent, and non-destructive behavior, so the bar is lower. The description adds valuable context: the platforms covered and the credential requirements (e.g., private ESPN needs espn_s2 + swid), which the agent needs to know before calling. It doesn't contradict annotations and adds meaningful behavioral detail beyond them.

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

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

Two sentences, front-loaded with the primary use case ('Start here when NO profile is connected') and immediately routing to the alternative for connected users. Every sentence earns its place; no filler or redundancy.

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

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

For a simple list tool with no output schema, the description fully covers what the agent needs: what it returns (platforms, capabilities, sports, credentials), when to use it, and when to use the alternative. Combined with strong annotations (read-only, idempotent), nothing critical is missing for correct invocation.

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

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

Schema description coverage is 100% for the single response_format parameter, with the enum values and default already documented. The description adds no additional parameter guidance beyond what the schema provides. With full schema coverage, baseline 3 is appropriate.

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

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

The description states the specific purpose: list supported platforms (fantrax, espn, sleeper) with capabilities, sports, and credentials. It clearly distinguishes from siblings by framing itself as the starting point for unconnected users and explicitly names fantasy_get_my_setup as the alternative for connected users. This leaves no ambiguity about what the tool does.

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 use it ('Start here when NO profile is connected') and when not to ('Connected users' leagues are already configured — see fantasy_get_my_setup instead'). It names the exact sibling to use instead, providing a clear routing decision for the agent.

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 the readOnlyHint annotation, the description discloses useful behavioral details: per-provider credential requirements, the fact that Fantrax discovery often returns empty even when leagues exist, and the recommended fallback path. This helps the agent anticipate and handle failures rather than assuming a successful result.

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 three sentences with no wasted words. The core purpose is front-loaded, the credential requirements are grouped efficiently, and the Fantrax caveat is included in a compact final sentence.

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 description is sufficiently complete for a read-only discovery tool: it covers provider differences, credential needs, fallback behavior, and the connected-profile distinction. It does not describe the exact output shape, but the response_format parameter and the phrase 'Discover the leagues' give enough context for an agent to proceed correctly.

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

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

The input schema already covers 100% of parameter descriptions, so the baseline is 3. The description adds meaningful value by compactly listing the exact credentials needed per provider ('Sleeper username + season; ESPN espn_s2 + swid + season + sport; Fantrax secret_id'), which complements the schema's broader credential description.

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

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

The description opens with a specific verb and object: 'Discover the leagues an account belongs to on a provider.' It also clearly scopes the tool to discovery without a connected profile, which differentiates it from sibling tools that fetch league details, rosters, or matchups.

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

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

It states when this tool is appropriate ('mainly for discovery WITHOUT a connected profile'), when it is not needed ('a connected profile's leagues come back directly'), and provides provider-specific fallback guidance ('on empty ask for a league URL/id and use the league tools directly'). This gives an agent actionable selection criteria.

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