League Loom

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

Annotations already declare readOnly/idempotent/non-destructive, so safety is covered. The description adds genuinely new behavioral context: it returns 'Facts, never a verdict' (no recommendation is synthesized), and some fields are sport-conditional ('best projected lineup change (NFL)'). It does not say what happens when a player is unresolvable or how per-provider gaps are handled.

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

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

One front-loaded sentence with zero filler, and the source-vs-facts distinction is placed at the end where it lands as a qualifier. The mid-sentence catalogue is telegraphic and takes effort to parse, costing it the top mark.

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

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

With 10 parameters, nested credentials, and no output schema, the description's job is to convey what comes back — and it enumerates the returned facts precisely (ownership, points, projections, age, contract, injury, lineup delta, roster spots, pick ownership). Combined with 100% schema coverage on inputs, an agent has enough to call it and anticipate the payload.

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 carries get/give/provider/league_id/team_query/credentials semantics. The description adds only indirect hints (NFL-specific lineup output, Sleeper-only pick ownership), which implies provider/sport dependencies but gives no parameter-level guidance beyond what the schema states. 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?

States a specific verb and resource ('Check a proposed trade') plus an explicit scope constraint ('in ONE league'), then enumerates the exact facts returned (rosters, points, projections, age, contract, injury, lineup change, pick ownership). No sibling tool claims this territory, so an agent can route to it unambiguously.

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

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

The 'ONE league' scoping and the pointer 'news via fantasy_get_player_data' tell the agent what this tool does not cover and where to go instead. There is no explicit statement of when not to call it (e.g. pre-draft, or a league that isn't connected), so it stops short of full when/when-not guidance.

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

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

Annotations already declare readOnly/idempotent/non-destructive, and the description adds real behavioral context beyond them: provider-specific result semantics (ESPN % owned, Sleeper every unrostered player by relevance), and importantly the Fantrax session-cookie requirement with an 'ADP-backed fallback' when absent. It stops short of pagination or result-shape detail, so not a 5.

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

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

Front-loaded with the core purpose and exclusions, and each sentence carries routing or provider information. The all-caps emphasis and dense provider clause make it slightly noisy, but nothing is truly wasted.

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

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

For an 11-parameter, zero-required tool with no output schema, the description covers what fields come back per provider and when credentials are needed, which is the main ambiguity. Return formatting details are left to the response_format parameter description, a minor gap.

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

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

Schema coverage is 100%, so every parameter is already documented in-schema; that sets the baseline at 3. The description only echoes a couple of default-sort behaviors per provider, which the schema's sort description largely covers, so it adds little parameter meaning beyond structured data.

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 ('Browse players you can ADD'), scopes it to ONE league, and names what is excluded (rostered players). It also explicitly distinguishes itself from siblings, calling itself 'THE waiver/pickup tool' while routing named-player and cross-league cases elsewhere.

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?

Names two alternatives with the exact condition that selects each: fantasy_get_player_data for a specific named player, fantasy_get_weekly_digest for waiver ideas across ALL leagues. The when-to-use boundary is unambiguous.

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, openWorld behavior, so the safety profile is covered. The description adds the useful conditional note that auction bid appears only 'where applicable', but says nothing about provider/credential resolution requirements or result size, which the schema handles separately.

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 return payload is front-loaded, and the season hint follows as a usage note. No filler or repetition of schema content.

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

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

For a 7-parameter read tool with no output schema, the description tells the agent what comes back and how season affects the result, while credentials and league resolution are fully covered by the schema. Slightly thin on provider-specific behavior (e.g. season being ignored by Fantrax), which lives only in the schema.

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

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

Schema description coverage is 100%, so every parameter including the conditional credentials object and league_query autopick behavior is already documented. The description only reiterates season semantics already stated in the schema, so baseline 3 applies.

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

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

Names the exact resource (draft results) and enumerates the payload contents — picks with round/overall, team, player, auction bid — which no sibling tool covers, so the agent can distinguish it from fantasy_get_my_players or fantasy_get_transactions. It lacks an explicit verb, but the scope 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?

Gives a concrete triggering use case with a natural-language example ('show my draft from last year') mapped to the season parameter, which tells the agent when this tool is the right call. No exclusions or alternatives are named, but there is no overlapping sibling to route away from.

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

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

Annotations already declare readOnly/idempotent/non-destructive, so safety is covered; the description adds that output is a derived analytical report (spread-based balance, inactivity-aware 'checked out' detection) rather than raw records, which matters since no output schema exists. It does not disclose cost, latency, or failure modes such as an unresolvable league.

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, zero filler, with the identity of the report front-loaded before the component breakdown and the example intents. Every clause either names content the tool produces or a query it answers.

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

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

With no output schema, the description correctly spends its words on what the report contains, which is the main thing an agent cannot learn elsewhere; parameters are fully covered by the schema. The remaining gap is scope boundary against fantasy_get_weekly_digest and fantasy_get_standings.

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

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

Schema description coverage is 100% and every parameter is documented in-schema (provider defaults, season ignored by Fantrax, league_query auto-pick), so the baseline is 3. The description only implies single-league scoping ('for one league') and adds no syntax or format detail 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?

Names a specific composite resource ('THE COMMISSIONER REPORT for one league') and enumerates its three components: competitive balance spread, this week's blowouts, and checked-out teams. An agent can broadly tell it apart from raw-data siblings like fantasy_get_standings or fantasy_get_rosters, but it never contrasts itself with the nearby fantasy_get_weekly_digest, which sounds similar in 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?

Gives concrete triggering intents: 'is my league healthy/competitive', 'who's tanking', or a state-of-the-league summary. However, it offers no when-not guidance and no explicit alternative for agents that only need raw standings (fantasy_get_standings) or a general digest (fantasy_get_weekly_digest).

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

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

Annotations already declare readOnly, idempotent, non-destructive, and openWorld, so the safety profile is covered. The description adds genuine behavioral context by qualifying that rules are returned only 'where the platform provides them,' signalling platform-dependent gaps in the payload. It says nothing about latency, multi-league resolution, or what happens when league_id is omitted, so it earns a moderate score rather than a high one.

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

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

A single dense sentence with the returned data front-loaded and the cross-tool hint appended last. No filler, no restatement of the title, and it ends on the actionable detail.

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 must carry the return-value burden, and it does so by listing the concrete fields returned. Given eight optional parameters and a three-provider matrix, the description is adequate because the schema documents provider behavior in detail. Minor gap: it doesn't clarify whether multiple leagues can be resolved or how the response format choice affects content, but nothing critical is missing.

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

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

Schema description coverage is 100%, so all eight parameters are already documented, including the provider defaults and credentials shape. The description only adds the cross-reference that team_query accepts ids sourced from this tool, which is a useful but narrow contribution beyond the schema. Baseline 3 applies when the schema carries the parameter burden.

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 enumerates exactly what the tool returns (league name, teams/owners, scoring format and settings, rules like trade deadline) and notes it is the source of team ids. That is specific and resource-focused, though the verb is implicit ('A league's name, teams...') rather than an explicit 'Retrieve'. Sibling differentiation is only partial — it links forward to team_query but doesn't contrast with fantasy_get_my_teams or fantasy_get_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?

Usage is implied rather than stated: calling out that this is the source of team ids for team_query hints it should be called before team-scoped tools. There is no explicit 'use this when' / 'use X instead' guidance, and no mention that it is the natural entry point before standings, matchups, or rosters.

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?

Adds substantial context beyond annotations: refresh produces a new snapshot rather than streaming, partial subtotals must never be treated as complete, Fantrax returns pairings without scores when the league isn't viewable, roto/points leagues have no matchups, and credentials rules per provider. Annotation safety profile (readOnly, idempotent) is consistent and enriched.

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

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

Front-loaded with purpose then caveats; nearly every clause carries operational weight (streaming caveat, partial subtotals, provider limits). It is dense as a single paragraph and some provider detail could be trimmed, but nothing is filler.

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

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

For an 11-parameter, multi-provider tool with no output schema, the description covers return contents, provider-specific limitations, credential expectations, and edge cases (partial subtotals, roto leagues). An agent has what it needs to call and interpret results 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 baseline is 3; the description goes further by pairing live=true with include_players=true and explaining why. It also clarifies provider-dependent behavior of season/sport, but doesn't detail team_query ambiguity handling beyond 'exact name/id wins', which is already 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 ('head-to-head scores') with scope (league-wide or one team via team_query) and explicitly contrasts it with 'season player data', which separates it from fantasy_get_player_data. An agent can pick this tool without opening the schema.

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

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

Gives concrete conditional guidance: 'For "who is scoring" or mid-game player updates, pass live=true and include_players=true', and rules out season player data. Strong, though it describes the distinction rather than naming the sibling tool to use 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 already cover read-only, idempotent, non-destructive, open-world behavior. The description adds real context beyond them: that players are matched across platforms, that results are ranked by team count, and that a connected profile is required. Return format/ordering nuances are implied but not detailed.

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

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

Front-loaded with the core concept ('YOUR EXPOSURE MAP') followed by definition, then trigger phrases, then the prerequisite. Dense but every clause is useful; the quoted example list is slightly heavy but directly aids retrieval.

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 adequately characterizes the return as a cross-platform ranked exposure list. Combined with annotations covering the safety profile, an agent has enough to select and call it correctly; only response formatting specifics are left to the schema.

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

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

Schema coverage is 100% with all three parameters fully documented, so the schema carries parameter meaning. The description reinforces the default behavior ('ALL configured leagues and providers') but adds no syntax or format detail beyond the schema. Baseline 3 applies.

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

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

Names a specific resource and scope: 'every player you roster across ALL configured leagues and providers, ranked by how many of your teams hold them.' This cleanly distinguishes it from sibling getters like fantasy_get_my_teams or fantasy_get_rosters, which are per-league/per-team, by emphasizing cross-league aggregation.

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 concrete user-phrasing triggers ('who do I have everywhere', 'players on several of my teams', 'if X gets hurt how many of my teams does it hit') and states the prerequisite 'Needs a connected profile.' It does not explicitly name the sibling alternative to use for single-league rosters, so it stops short of a 5.

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

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

Annotations already declare readOnly/idempotent/non-destructive, but the description goes well beyond them: it discloses where changes are saved (/setup), the reconnect flow per client (Claude/ChatGPT ask for reconnection with a new token; other apps disconnect/reconnect), and hard behavioral prohibitions (relay returned steps, never tell the user to remove the connector, never ask for ids or credentials).

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 core purpose in the first clause, then layers routing conditions and behavioral rules. It is long, but nearly every sentence carries decision-relevant information; the reconnect detail and the 'never tell the user to remove the connector' rules are dense but earned.

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

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

For a zero-required-param read tool with no output schema, the description covers purpose, routing, the change/reconnect workflow, and the agent's obligations. There is no meaningful gap an agent would need filled before calling it.

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

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

There is a single optional parameter (response_format) at 100% schema description coverage, so the schema fully documents it. The description adds nothing about the parameter or its format tradeoffs, which is the expected baseline when the schema does the work.

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

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

States a specific verb and resource: it returns the connected profile's leagues, teams, full custom rules, plus the steps to add/remove/change a league. It also distinguishes itself from the plain-listing siblings by telling the agent not to call it merely to start a session and noting it replaces fantasy_manage_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 gives when-not (the server instructions already list the connected leagues, so don't call it just to start a session) and when-to (leagues absent from context, rules truncated, list ends '…and N more', or the user wants to change their setup), with concrete trigger phrases. This is about as routed as a description gets.

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 useful behavioral context that this is a bundled aggregation (standings + matchup + roster) including lineup-lock state, which tells the agent not to chain sibling calls. It stops short of noting auth requirements or data-freshness/caching behavior, which would matter for a multi-provider read.

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

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

Two sentences, no filler. The capability statement comes first and the scoping/exclusion rule second, which is the right order for a routing decision.

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 eight optional params, no output schema and a nested credentials object, the description does enough: it names the three data sections returned and flags the lineup-lock nuance. It does not describe the shape of the combined response or how sections are labeled, which is the only remaining gap given there is no 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 description coverage is 100%, so every parameter (sport, season, provider, league_id, team_query, credentials, league_query, response_format) is already documented in-schema, and the description adds no additional parameter meaning. Baseline 3 applies when the schema carries the burden.

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 with explicit scope: the caller's own team in a single league, returning standing, current matchup and roster with lineup locks. It directly names the sibling it differs from (fantasy_get_my_teams), so an agent can disambiguate without opening either schema.

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

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

Gives an explicit when-to-use rule ('SINGLE-league only') plus concrete example phrasings that should route elsewhere ('my teams', 'how am I doing', 'my week'). The alternative tool is named, so the routing decision is fully specified.

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

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

Annotations cover the safety profile (readOnly, idempotent, non-destructive), and the description adds substantial behavior beyond them: comparison_snapshot must be passed back unchanged and expires after 24 hours, requires a connected profile, and the tool renders one section per team without mixing players or points.

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?

Dense but front-loaded: scope first, then routing rules, then per-view behavior. Every sentence carries information, though the rendering directives ('ALWAYS render a separate section...') could be trimmed without loss for tool selection.

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 compensates by describing what each view returns (matchups and starter highlights, empty slots and deadlines, lighter standings and totals) plus prerequisites and snapshot reuse. An agent has everything needed to call and interpret it.

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

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

Schema coverage is 100%, so baseline is 3, but the description adds meaning the schema lacks: sport is exemplified ('NFL' for 'my football teams'), view behavior is spelled out per mode, and comparison_snapshot's opaque/never-fabricate/expiry semantics are clarified.

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 ('personal scoreboard and kickoff check across ALL connected teams') with explicit scope (cross-league, plural). It directly distinguishes itself from the singular sibling fantasy_get_my_team, so an agent can route without opening either schema.

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

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

Gives quoted trigger phrases ('my teams', 'how am I doing', 'my week'), an explicit when-not ('do NOT answer those from one league'), and names the alternative for a single named league (fantasy_get_my_team). Routing is unambiguous.

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?

Goes well past the readOnly/idempotent annotations by disclosing per-provider behavior: ESPN weekly data usually only current week, Fantrax needs a viewable league or saved session cookie else only roster status/ADP, Sleeper gives identity/availability plus matchup box scores for league points. It also warns that news is untrusted material and that missing feeds are marked unavailable — real operational context an agent can't infer from 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?

Front-loaded with the action, batching rule and the disambiguation from the sibling tool, and nearly every clause carries an actionable caveat. The second paragraph is a dense wall of provider-specific fragments that takes effort to scan, and the names/limit rule is stated twice (description and schema).

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 19-parameter, three-provider, nested-credential tool with no output schema, the description covers the gaps that actually cause wrong calls: provider-dependent data availability, research defaults capping at five players, history/splits requiring an explicit season, and the distinction between public preset scoring and league points. Little 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?

Schema coverage is 100%, so baseline is 3, but the description adds cross-parameter semantics the schema doesn't: exact player_ids disambiguate names, query counts as one extra name alongside names, and Sleeper NFL projections require week plus the league season even with include_research=false. It stops short of documenting every param (research_sources, split_limit, response_format are left to 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 ("Deep dive on SPECIFIC named players") and enumerates the payload (points, projections, % owned, availability, injury, cross-platform ids). It explicitly contrasts scope with fantasy_get_available_players and notes it replaces fantasy_get_players, so an agent can route without opening schemas.

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

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

Gives concrete when-to-use rules: batch up to 10 names in ONE call for a roster or trade, never one call per player, and prefer retrieved stats over memory or stale rankings. It names the alternative tool and the condition for it ("NOT for browsing who to add: use 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 establish read-only, idempotent, non-destructive, open-world behavior, so the description does not need to repeat safety traits. It adds useful context beyond annotations by describing the returned roster fields and the provider-specific Fantrax name-resolution requirement, though it does not cover rate limits or pagination.

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 and front-loaded: it first says what the tool returns, then the team_query constraint, then the provider-specific note and alternative tool. Every sentence contributes useful routing or behavior information.

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

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

For a nine-parameter read tool with no output schema but rich schema descriptions and annotations, the description is largely complete. It names the roster data returned and the key sibling alternative, though it does not discuss pagination or response format beyond what the schema already covers.

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 nine parameters well. The description adds a little semantic context about team_query narrowing to one team and Fantrax sport lookup, but most parameter detail is repeated from 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 specific resource and contents: every team's roster with players, positions, slot/status, injury evidence, and lineup locks. It also distinguishes this tool from the sibling fantasy_get_my_team by naming the alternative explicitly.

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

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

It gives clear routing guidance: use team_query to limit the result to one team, and use fantasy_get_my_team instead when you need roster + standing + matchup in one call. The Fantrax sport requirement is also called out for that provider-specific path.

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/non-destructive, but the description adds genuinely new behavioral facts: results are exact win/loss math rather than simulation, so clinches should be reported as guarantees. It also discloses per-provider fidelity (ESPN/Sleeper full vs Fantrax H2H-only, partial SoS, no clinch math) and an auth edge case where private leagues without a saved session cookie return pairings only.

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 output surface is front-loaded before the usage triggers and provider caveats, and every clause carries information. It is dense with stacked parentheticals and a quote list, which costs some readability but not correctness.

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 10-parameter, no-output-schema tool, the description covers the important variance: what each view returns, how providers differ, and the credential/session caveat. Remaining gaps (response shape, defaults like view=all, required-param guidance) are already documented in the schema.

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

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

Schema description coverage is 100%, so the baseline is 3; the description goes slightly beyond it by tying view to sections and by stating that Fantrax requires team_query while ESPN/Sleeper auto-detect it. Those cross-parameter dependencies are not spelled out in the schema, though the remaining parameters are left entirely to 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 names three concrete outputs (full-season schedule, strength of schedule, deterministic playoff picture with seeds/clinch/magic numbers) rather than restating the tool name, and it explicitly contrasts its math with simulation. It never names a sibling such as fantasy_get_standings or fantasy_get_matchups to draw the boundary, so the split is inferable rather than stated.

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

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

It supplies real user-intent triggers ('am I making the playoffs', 'who's clinched', 'who has the easier schedule', rest-of-season outlook) and explains that the view parameter narrows the section. It does not say when to prefer a different tool or state exclusions other than provider coverage, so it lands short of a full when/when-not treatment.

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

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

Annotations already declare readOnlyHint, idempotentHint, and destructiveHint=false, so the safety profile is covered. The description adds useful behavioral context by noting that FAAB/waiver order is only present 'where the platform provides them,' but says nothing about authentication needs, error cases, or ordering of results.

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

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

A single front-loaded sentence that lists the key returned fields without filler. 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?

With 100% schema coverage and no output schema, the description appropriately explains what the tool returns. It is nearly complete, though it could clarify that standings cover all teams in the league rather than just the user's team.

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 fully documents all eight parameters including provider defaults, league_id omission, team_query behavior, and credentials. The description adds no parameter-level meaning beyond that, which is the baseline expectation when the schema does the work.

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

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

The description names the resource (league standings) and enumerates the specific fields returned (rank, record, points for/against, FAAB/waiver order). It is clearly distinguishable from siblings like fantasy_get_rosters or fantasy_get_matchups, though it lacks an explicit verb and direct sibling differentiation.

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

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

There is no guidance on when to use this versus alternatives, no prerequisites, and no notes about provider-specific requirements despite the schema exposing sport, provider, league_id, and credentials. The agent must infer usage entirely from parameter names.

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 annotations (readOnly, idempotent, non-destructive), the description discloses per-provider behavior: Sleeper returns per-week results with FAAB bids, ESPN returns an activity feed where trade legs 'may be partial', and Fantrax requires a publicly viewable league or a saved session cookie — real auth and data-completeness caveats an agent needs. The partial-data warning is especially valuable since it changes how results should be reported.

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

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

Front-loaded with the resource and its contents, followed by use-case questions, then terse provider notes — the ordering is right and there is no filler. The provider notes are compressed to near-telegraphic fragments ('Sleeper: per week, with FAAB bids'), which is efficient but slightly harder to parse than full sentences.

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

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

For a 10-parameter, zero-required read tool with no output schema, the description covers the main risk areas: provider variance, auth requirements, partial ESPN trade legs, and result ordering. It leaves the return structure largely unstated and doesn't mention the limit/response_format knobs, which the schema carries but the agent may want framed in terms of output shape.

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 provider-specific parameter semantics: 'week' is meaningful per-week on Sleeper while 'season' is ignored by Fantrax, and 'types' is echoed by the listed moves. It still says nothing about 'limit' or 'response_format' beyond what the schema states.

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

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

States a specific resource ('recent league moves') with an explicit enumeration of what's included (adds, drops, waiver claims, trades) and the ordering ('newest first'). No sibling tool overlaps this surface — fantasy_analyze_trade evaluates a trade, fantasy_get_my_players lists a roster — so an agent can select it 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 two quoted user questions ('did my waiver claim go through?', 'what trades happened?') give concrete use contexts that map directly to the tool. It stops short of explicit exclusions or pointing to alternatives such as fantasy_analyze_trade for evaluating rather than listing trades, so it falls short of a 5.

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

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

Annotations already declare read-only, idempotent, open-world, non-destructive, so the description doesn't need to re-state safety. It adds genuine behavioural context the annotations can't carry: the data is Sleeper platform-wide only, not league-scoped or availability-aware, and reflects a current snapshot ("right now"). It stops short of mentioning freshness/lookback behaviour or response shape, which would have earned a 5.

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

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

Two sentences, zero filler, with the scope constraint front-loaded before the alternative tool redirect. Every clause earns its place.

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

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

For a 7-parameter read tool with a nested credentials object and no output schema, the description conveys the data source, scope limits and result kind (most-added/most-dropped) — enough to call it correctly. It could say more about ordering/ranking and what the rows contain, but the schema already covers credential and provider handling.

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%, including enums for direction, provider and response_format and defaults for limit/lookback_hours, so the schema carries all parameter meaning. The description adds no syntax, format or default detail beyond that. Baseline 3 is correct.

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

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

States a specific verb and resource — the most-added or most-dropped players platform-wide — and immediately frames it with recognisable user phrasings ("who's trending"). It explicitly names the sibling tool fantasy_get_available_players as the different case, so an agent can distinguish the two without reading schemas.

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

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

Gives an explicit when-to-use condition ("who's everyone adding/dropping") and an explicit when-NOT-to-use plus redirect ("for players you can actually add in YOUR league use fantasy_get_available_players"). No inference required.

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

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

Beyond the annotations, the description discloses that a connected profile is required, that candidates are options rather than proven upgrades, that coverage warnings should be preserved, and that injury freshness should be verified. It also describes the shape of the returned digest with and without an identified team. The annotations already cover safety and idempotency, and the description adds meaningful operational caveats.

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-loads the core purpose and intended use cases before moving into output detail and caveats. It is longer than strictly necessary, with some repetition around one-league versus all-leagues behavior, but most sentences carry useful routing or behavioral information. It remains readable 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?

There is no output schema, so the description must explain return behavior, and it does: identified-team reports include prioritized roster checks, standings, matchups, waiver candidates, FAAB, recent moves, and missing-data warnings; without a team it returns a league overview. Combined with annotations and full schema coverage, this is complete enough 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 coverage is 100%, so the baseline is 3. The description adds useful semantics for league_query by explaining that it narrows the report to one named league and that omitting it includes all matching leagues. It also clarifies that team selection is optional, giving more meaning than the schema alone for those selection parameters.

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

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

The description states a specific verb and resource: a weekly report/digest for one league or all configured leagues. It distinguishes scope clearly and names the sibling tool for a simpler alternative. An agent can tell this apart from generic league-info or team-snapshot tools without opening the schema.

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

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

It gives explicit user intents such as 'what needs attention this week', 'weekly rundown/recap', and waiver review. It clarifies when to pass league_query, when team selection is optional, and routes simple single-team snapshots to fantasy_get_my_team. This is strong when-to-use and alternative 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 readOnly, idempotent, non-destructive and openWorld, so the safety profile is covered. The description adds what is actually returned (capabilities, sports, credentials) and the prerequisite state (no connected profile), which the annotations cannot convey; the trailing note about league tools being read-only and share publishing on request is background about siblings rather than this tool.

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 expected return contents are front-loaded in the first clause, and the 'start here' routing cue follows immediately. The final sentence about other league tools is off-topic for this tool and dilutes focus.

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 exists, so the description must hint at return content, and it does list capabilities, sports and required credentials. The response_format option is left to the schema, which is acceptable at full coverage, but an agent gets no sense of the response shape.

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 single response_format parameter has 100% schema description coverage, including enum meaning and default, so the schema carries the semantics. The description says nothing about output format options, so no credit above the baseline.

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

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

Names the specific resource (supported platforms) and enumerates them (fantrax, espn, sleeper) with the returned attributes (capabilities, sports, required credentials). The parenthetical user question plus the 'start here when NO profile is connected' clause makes it clearly distinguishable from fantasy_get_my_setup and fantasy_list_user_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?

Gives an explicit trigger: use it when no profile is connected, since a connected profile's leagues are already configured. No sibling is named as an alternative, and the when-not case is only implied via the connected-profile caveat, so it falls short of a full 5.

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

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

Annotations already declare readOnly/idempotent/non-destructive/open-world, so safety is covered; the description adds real value by enumerating which credential each provider requires and by warning that Fantrax discovery frequently returns empty even when leagues exist. That caveat is exactly the kind of failure-mode disclosure annotations cannot carry. It does not say what happens on partial credential failures or whether an empty result is otherwise distinguished from an error.

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

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

Front-loaded purpose followed by prerequisites and a fallback note; every sentence carries information. The telegraphic 'Needs: ...' colon-list is efficient but slightly compressed, reading more like notes than prose.

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 5-param, zero-required, multi-provider discovery tool with no output schema, the description covers the decision point, per-provider inputs, the optional provider default, and the known empty-result trap — 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?

Schema coverage is 100%, so baseline is 3; the description earns above that by mapping parameters to providers (Sleeper username + season; ESPN espn_s2 + swid + season + sport; Fantrax secret_id) and noting Fantrax ignores season — cross-parameter relationships the per-field schema text does not express.

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 ('Discover an account's leagues') and immediately scopes it against the connected-profile path (fantasy_get_my_teams-style), so the agent can distinguish it from the many league-read siblings without opening the schema.

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

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

Gives a clear primary condition ('mainly WITHOUT a connected profile') and a contrast case ('a connected profile's leagues come back directly'), plus a concrete fallback when Fantrax returns empty (ask for a league URL/id and use league tools directly). It stops short of naming the specific alternative or fallback tools, which is what a 5 would require.

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 mark it non-read-only and open-world, and the description adds real context beyond them: the page expires in 30 days, ids are hidden, the manage link deletes the page, and it 'never changes the league.' It also discloses that League Loom re-reads records and scores and that notes must be plain text with no links. These are non-obvious behavioral traits an agent needs.

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 core publish action and the gating rule are front-loaded, and every sentence carries signal. It is dense and semicolon-heavy, with the expiry and link details slightly crammed, but nothing is genuinely 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?

With no output schema, the description delivers the return semantics ('share link' and 'manage link removes the page') an agent needs. Combined with full schema coverage across 10 params, an agent has enough to call it 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 adds content constraints not in the schema — plain-text notes and 'no links' — that affect how parameters should be filled. It otherwise leaves per-parameter detail to the well-documented 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 states a specific verb ('Publish') and resource ('a page') plus the return value ('its link'), covering both recap and power-ranking kinds. It is clearly distinguishable from all read-only siblings like fantasy_get_standings or fantasy_get_weekly_digest.

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?

'ONLY when the user asks for a link or accepts your offer, never unprompted; offer after writing one' gives explicit when-to-use and when-not-to-use conditions with a triggering workflow. This is unusually precise routing guidance.

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