League Loom

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

Annotations already cover read-only/idempotent/no-destruction, so the bar is lower; the description adds provider-specific behavior beyond them (ESPN % owned + season/projected points, Sleeper relevance rank, Fantrax public-league ownership/ADP with an ADP-backed fallback). It does not mention pagination, result caps, or what happens on a failed provider lookup, keeping it off 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-loads the core purpose and the 'THE waiver/pickup tool' signal, then layers alternatives and provider caveats efficiently in one paragraph. Slightly dense with ALL-CAPS emphasis and provider detail that borders on over-stuffing, but 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?

No output schema exists and the tool has 11 params plus nested credentials, but the description covers the selection alternatives, the exclusion rule, and per-provider return semantics. Remaining gaps are minor (pagination/limits are already in the schema's limit param).

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% across 11 parameters, so the schema already carries parameter meaning. The description reinforces default ordering per provider (ESPN % owned, Sleeper relevance rank) but adds no syntax, format, or constraint detail beyond 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?

States a specific verb and resource ('Browse players you can ADD in ONE league (free agents + waivers)') with explicit scope and ordering ('best first'). It also names the sibling it is not (fantasy_get_player_data) and a complementary sibling (fantasy_get_weekly_digest), so it is distinguishable 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?

Explicitly routes the agent: use fantasy_get_player_data for a specific named player, fantasy_get_weekly_digest for waiver ideas across ALL leagues. It also states the exclusion ('Excludes rostered players'), which is the key when-not condition for a pickup tool.

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

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

Annotations already declare readOnly, idempotent, non-destructive and open-world, so safety is covered. The description adds only that auction bids appear 'where applicable' and how season affects output; it says nothing about auth needs or provider quirks the schema hints at.

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 sentences, front-loaded with the return contents and followed by the single most useful calling tip. The parenthetical example earns its place; nothing is padded.

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, no-output-schema read tool with fully documented parameters, the description conveys what comes back and the one non-obvious calling pattern. Multi-provider/auth nuances live in the schema, so the coverage is adequate.

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

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

Schema description coverage is 100%, so the schema already documents every parameter including season, provider, league_query and credentials. The description's only added semantic is the season-for-past-draft usage pattern, which makes the baseline 3 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 resource (draft results) and enumerates what a pick contains (round/overall, team, player, auction bid), which cleanly separates it from siblings like fantasy_get_transactions or fantasy_get_rosters. It is not tautological, though it opens with a fragment rather than a full verb clause.

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 usage cue given is 'Pass season for a past year's draft', with a natural-language example. There is no guidance on when to prefer this over adjacent tools, nor any prerequisite/exclusion notes, so it stays at an implied-usage level.

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

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

Annotations already declare readOnlyHint, idempotentHint, and destructiveHint=false, so safety is covered. The description adds real value beyond that by disclosing what the report computes (points-for/win% spread, blowouts, inactive-heavy rosters), telling the agent what derived analysis it will get rather than raw data.

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

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

Two tight sentences: the first names the report and its contents, the second gives the use-case triggers. Front-loaded and zero 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?

With no output schema, the description usefully enumerates the report's contents so the agent knows what to expect. Safety and idempotency are covered by annotations. Minor gap: it doesn't note anything about scope defaults (e.g. connected-league auto-pick), though the schema handles that.

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

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

Schema description coverage is 100%, so every parameter (sport, season, provider, league_id, league_query, response_format) is already documented in the schema. The description adds no additional guidance on parameter usage, which is acceptable but earns only the 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+resource ('THE COMMISSIONER REPORT for one league') and enumerates the three analytical outputs it produces: competitive balance, this week's blowouts, and inactive-heavy rosters. This clearly distinguishes it from sibling read tools 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?

Explicitly lists the trigger questions it answers ('is my league healthy/competitive', 'who's tanking', state-of-the-league summary), which gives strong when-to-use context. It does not, however, name a sibling alternative or state when a simpler tool (e.g. get_standings) would be preferable.

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, openWorld, non-destructive, so the safety profile is covered. The description adds real behavioral context: rules are returned only 'where the platform provides them', Fantrax lacks owner data and requires team_query, while ESPN/Sleeper auto-detect, and Fantrax ignores season. That platform-dependent variability is useful and not derivable from 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?

A single semicolon-joined sentence that front-loads the returned data before the team_query linkage. Dense but every clause carries information; 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?

For an eight-parameter, multi-provider, all-optional, no-output-schema tool, the description covers what is returned and the cross-tool dependency well, while the schema handles provider/credential nuance. Missing only explicit guidance on the disconnected-profile path and the markdown-vs-json tradeoff, which the schema already notes.

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 eight parameters, including provider enum, season, and credentials. The description adds little beyond noting that team ids originate here; baseline 3 is appropriate 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 the concrete payload (league name, teams/owners, scoring format and settings, key rules like trade deadline) and explicitly names the downstream consumer ('source of team ids for team_query'), which separates it from siblings like fantasy_get_standings or fantasy_get_league_health. It lacks an explicit verb (the name supplies it) and does not contrast itself with the other league-scoped getters.

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 only implied: the agent can infer it should call this before fantasy_team_query to obtain team ids, and the platform-dependent notes hint at when certain inputs are needed. There is no explicit 'use this when / use X instead' statement and no stated prerequisites such as needing a connected profile.

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

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

Annotations already cover safety (readOnly, idempotent, non-destructive), so the bar is lower, yet the description adds real behavioral context: a refresh is a new snapshot rather than streaming, partial subtotals list missing categories and must not be treated as complete, and private-league credentials are required for non-public reads. It stops short of describing pagination or how large league-wide snapshots behave, so it is 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 core purpose and the live-scoring distinction in the first two sentences, then branches by provider. Dense and jargon-heavy ('raw stat categories NFL-only') but each clause carries load; slightly long for a single description.

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

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

Covers an 11-parameter tool with a nested credentials object and no output schema: it describes the return payload (fantasy points, separate projections, raw stats/game progress, retrieval time, provisional/final status), provider-by-provider data availability, and auth requirements. 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 description coverage is 100%, so the 3 baseline applies, but the description adds cross-parameter semantics the schema cannot: the live=true + include_players=true pairing for mid-game use, and the team_query interpretation of ambiguous names. It adds genuine conditional meaning beyond the per-field docs.

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) and scope (league-wide or one team), then explicitly distinguishes itself from the sibling it could be confused with: 'season player data is not live scoring.' An agent can pick this over fantasy_get_player_data 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 concrete when-to-use triggers ('who is scoring' or mid-game updates → live=true and include_players=true) and explicit boundaries for each provider (Fantrax team totals only; roto/points leagues have no matchups; scores require a publicly viewable league). Exclusions and alternatives are named rather than implied.

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 readOnlyHint, idempotentHint, openWorldHint and destructiveHint, so the safety profile is covered. The description adds genuine behavioral context by disclosing the aggregate payload shape (one call returns standing + matchup + roster with lineup locks), which is not derivable from annotations. It stops short of noting response size or latency trade-offs of the bundled call.

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

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

Two sentences with zero waste. The scoping constraint and the alternative routing rule are front-loaded in the second sentence, so the agent sees the disambiguation cue before committing to the call.

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, but the description compensates by listing the returned components (standing, matchup, roster, lineup locks). Combined with 100% schema coverage on the inputs and annotations covering the safety profile, an agent has everything needed to call this 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 description coverage is 100% across all 8 parameters, including provider defaults, credential requirements, league_id omission rules and response_format semantics, so the schema carries the full burden. The description adds no parameter-level detail (no mention of sport, season, or credentials), making 3 the correct 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?

States a specific verb/resource pair ('One call for YOUR team') and enumerates exactly what is bundled: standing, current matchup and roster with lineup locks. It also explicitly distinguishes itself from the plural sibling 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') and names the exact alternative for the excluded case ('for anything plural... use fantasy_get_my_teams'), complete with example phrasings like 'my teams' and 'how am I doing'. Nothing is left to inference.

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?

Annotations already declare readOnly/idempotent/openWorld/non-destructive safety, but the description adds substantial behavioral context: provider-specific data availability, default public research limits, scoring caveats ('public preset point totals are NOT league points'), untrusted news handling, missing-field behavior, and authentication requirements. 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?

The definition is long but front-loads purpose, preference, and the key sibling exclusion. The remaining provider-specific and parameter-interaction details are dense yet largely purposeful for a 19-parameter, multi-provider tool, with little obvious repetition.

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 19 parameters, no output schema, nested credentials, and multiple providers, the description covers the important operational distinctions: research defaults, scoring differences, missing feeds, provider quirks, and credential requirements. It is complete enough for correct invocation 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 schema already documents each parameter. The description still adds interaction semantics beyond the schema, such as names + query counting together, include_history/include_splits needing season, and Sleeper NFL projections needing week plus league season even with include_research=false.

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 and scope: 'Deep dive on SPECIFIC named players, rostered or not: league-scoped points and stats, projections, % owned, availability, injury status, cross-platform ids.' It also distinguishes itself from fantasy_get_available_players and notes it replaces fantasy_get_players, so an agent can identify it 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 explicit when-to-use guidance ('PREFER its retrieved stats over memory or stale rankings for in-season player questions') and explicit when-not-to-use guidance ('NOT for browsing who to add: use fantasy_get_available_players'). It also instructs batching names in ONE call and when to use 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 readOnly/idempotent/non-destructive, so the safety profile is covered. The description adds provider-specific behavioral context that annotations cannot: Fantrax name resolution requires sport, and Fantrax has no owner data so team_query is mandatory there while ESPN/Sleeper auto-detect. No return-format or pagination detail, but for a read tool this is solid added context.

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 compact, front-loaded sentences with no filler – roster contents first, then scoping, then the routing alternative. Dense and information-bearing throughout, though the parenthetical '(lineupContext/lineupLock)' is field jargon that slightly interrupts flow.

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 carries the burden of describing the payload, and it does: it names the roster fields returned. With 9 unrequired params and complex multi-provider behavior, the description still tells the agent enough to call it correctly without guessing.

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 schema already documents all nine parameters including provider defaulting and credential requirements; baseline is 3. The description's 'team_query limits it to ONE team' and 'Fantrax name resolution needs sport' largely restate what the schema descriptions already state, adding little beyond them.

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?

Opens with a specific verb+resource ('Every team's roster') and enumerates the returned fields (players, positions, slot/status, injury evidence, lineup locks). It explicitly differentiates from the closest sibling, fantasy_get_my_team, so an agent can route correctly 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?

States the scoping condition (team_query limits the result to ONE team / 'my roster') and names the alternative with its condition: 'For your roster + standing + matchup in one call, use fantasy_get_my_team.' Both when-to-use and when-to-use-something-else are covered.

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 substantial value beyond them: the playoff picture is deterministic (report clinches as guarantees, not simulations) and provider behavior varies sharply (ESPN/Sleeper full vs Fantrax H2H-only, no clinch math, partial SoS; non-public leagues return pairings without scores). These are exactly the behavioral caveats an agent needs before summarizing 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?

Front-loaded with the core capability and the determinism caveat, then usage triggers, then provider caveats. It is dense with parentheticals and semicolons but nearly every clause carries information; only mild tightening is possible.

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 it covers the risky areas well: provider divergence, credential-less public reads (in schema), and what sections the response contains. It does not describe return shape/structure for the schedule vs strength vs playoff sections, a minor gap since no output schema exists.

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% (view, provider, credentials, team_query all documented inline), so the schema carries parameter meaning. The description reinforces that 'view' selects a section but adds no syntax or format detail beyond the schema, making the baseline 3 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?

States a specific verb+resource (full-season schedule) plus the two additional artifacts it produces (strength of schedule, deterministic playoff picture with seeds/clinch/magic numbers), which cleanly separates it from siblings like fantasy_get_matchups and fantasy_get_standings. The parenthetical 'exact win/loss math, not simulation' pins down the semantics an agent needs.

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 trigger phrases ('am I making the playoffs', 'who's clinched', 'who has the easier schedule', rest-of-season outlook) that map directly to usage, and explains that 'view' selects the section. It stops short of explicit when-not-to-use guidance or naming sibling tools for adjacent questions.

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 openWorldHint, so safety and side-effect profile are covered. The description adds the useful caveat that FAAB/waiver order is only present 'where the platform provides them', but says nothing about auth requirements or pagination/ordering behavior.

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

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

A single front-loaded sentence listing the payload fields with no filler. 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?

With no output schema, the field enumeration is a helpful stand-in for return values, but the description omits how results are structured or sorted and gives no cross-platform caveats beyond the FAAB note. Adequate for a read-only tool whose 8 parameters are fully documented in the schema, but not rich.

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% across all 8 parameters, including provider defaults, league_query auto-pick, and credential rules, so the schema carries the full burden. The description contributes no additional parameter meaning, which is the baseline 3 case.

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 (league standings) and enumerates the returned fields (rank, record, points for/against, FAAB/waiver order), so it is distinguishable from siblings like fantasy_get_rosters or fantasy_get_matchups. The retrieval verb is only implied, but the resource 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?

No statement of when to choose this tool over alternatives such as fantasy_get_rosters or fantasy_get_league_health, and no prerequisites or exclusions. Usage is left entirely to inference from the name.

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 safety (readOnly, idempotent, non-destructive). The description adds critical provider-specific behavior: Sleeper returns per-week with FAAB bids, ESPN uses activity feed (trade legs may be partial), Fantrax only public leagues. This is exactly the kind of non-obvious context that helps an agent interpret 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?

The description is extremely compact—one sentence with provider-specific notes—front-loading the core action and examples. Every element (scope, examples, provider caveats) adds value without waste.

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 annotations handle safety and schema covers all parameters, the description provides necessary provider-specific behavioral details. It doesn't explain return format (no output schema), but the implied structure (newest first) is sufficient for an agent to proceed.

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 parameter meanings are fully documented in the schema. The description adds no extra syntax or format details for parameters like week, limit, types, etc., but that's unnecessary given the high 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 a specific verb+resource ('league moves (adds, drops, waiver claims, trades)') and distinguishes from siblings like fantasy_get_standings or fantasy_get_matchups. It even gives example agent-facing questions, making the purpose 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?

It provides clear context via example questions ('did my waiver claim go through?', 'what trades happened?'), implicitly telling when to use. No explicit when-not-to-use or alternative tool references, but the examples narrow usage effectively.

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, openWorldHint=true, idempotentHint=true, destructiveHint=false, covering the safety profile. The description adds the important scope constraint that the data is platform-wide Sleeper-only, which is useful behavioral context. However, it doesn't mention rate-limit/pagination behavior, authentication for the non-default providers, or the fact that results depend on provider/credentials -- gaps that a 7-param tool with a credentials field could benefit from disclosing.

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 tightly packed sentences front-load the core purpose and the key scoping constraint, then route to the alternative. Zero wasted words and no redundancy with the schema or annotations.

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 should ideally hint at the return shape, but it doesn't. Still, for a read-only platform-trending tool with rich schema coverage and clear alternative routing, the essential information is present; the only meaningful gap is the return format/fields.

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 like limit, sport, provider, direction, lookback_hours, credentials, and response_format are already documented in the schema with enums and defaults. The description adds no parameter-level detail beyond what the schema provides, 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?

States a specific verb+resource (most-added/most-dropped players platform-wide) and uses colloquial aliases ('who's trending', 'who's everyone adding/dropping') that map user intent to the tool. It explicitly distinguishes itself from the sibling fantasy_get_available_players by naming that tool and the scenario that calls for it.

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 ('who's trending', 'who's everyone adding/dropping') and when-not ('not league-specific or availability-aware'), and names the alternative (fantasy_get_available_players) with the condition that selects it. Nothing is left to inference.

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 readOnlyHint, idempotentHint, and destructiveHint=false, so "All tools are read-only" is largely a restatement of structured data. The genuinely additive behavior info is that the tool is a bootstrap/discovery call whose usefulness depends on whether a profile exists.

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 sentences with the payload contents front-loaded and the usage condition second. The embedded user-question parenthetical is mildly redundant but useful for retrieval matching, so the text is efficiently sized overall.

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, but the description enumerates the returned fields (platforms, capabilities, sports, credentials), which is exactly what an agent needs for a zero-required-param discovery tool. An agent has enough to call and interpret it without further detail.

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

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

Only one parameter (response_format) and schema coverage is 100%, so the schema already documents the markdown/json choice and its default. The description adds no additional parameter guidance, which meets the baseline for fully documented params.

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 (list fantasy providers) and enumerates what each entry contains: platforms (fantrax, espn, sleeper), capabilities, sports, and credential requirements. This clearly separates it from league-scoped siblings like fantasy_list_user_leagues, though it never names a sibling 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?

"Start here when NO profile is connected; a connected profile's leagues are already configured" gives a concrete entry condition and implicitly excludes the case where a profile already exists. It stops short of naming the alternative tool to use when a profile IS connected.

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 this a safe read (readOnly, idempotent, non-destructive, open-world), so the safety profile is covered. The description adds the non-obvious auth requirements per provider and the important quirk that Fantrax discovery can return empty even when leagues exist. No mention of rate limits or result shape, but the auth/edge-case disclosure is the valuable part.

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: the primary case (no connected profile) leads, followed by provider requirements, then the failure fallback. Telegraphic phrasing ('Needs: ...') is efficient, though the credentials sentence is somewhat cryptic without the schema in view.

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 still does not describe what a successful result looks like (a list of leagues with ids), though that is inferable. Given annotations cover safety and the schema covers parameters, the credentials prerequisites and Fantrax edge case make it nearly complete for a read/discovery tool.

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

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

Schema description coverage is 100%, so all five parameters (including the nested credentials object and enums) are already documented in the schema. The description largely restates the provider-to-credential mapping and that Fantrax ignores season, adding little syntax or format detail beyond the 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 ('Discover an account's leagues on a provider') and immediately scopes it against the sibling behavior of connected-profile reads. An agent can distinguish it from fantasy_get_my_teams/get_my_setup without opening any 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 per-provider prerequisites (Sleeper username+season, ESPN espn_s2+swid, Fantrax secret_id) and an explicit fallback path when Fantrax returns empty: 'ask for a league URL/id and use the league tools directly.' When-to-use and what-to-do-on-failure are both spelled out.

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