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

Annotations already declare readOnlyHint=true and openWorldHint=true, so the operation is known to be safe and externally dependent. The description adds useful context about stable IDs and configuring a username, but does not disclose error handling or what happens when the username cannot be resolved.

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 sentence with no filler, front-loaded with the main verb and resource. Both clauses ('resolve...' and 'return...') earn their 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 single-optional-parameter, read-only account tool, the description conveys enough to select and invoke it: it resolves an identity and returns a current state. The lack of an output schema makes the vague 'current NFL state' a minor gap, but not a blocking one.

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

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

Schema coverage is 100% and the only parameter is documented as an optional override for SLEEPER_USERNAME. The description adds the notion of a configured default username, but it doesn't clarify precedence or behavior if both the configured value and override are absent.

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 a specific action (resolve username to stable user ID) and a second outcome (return current NFL state), which sets it apart from league- and roster-focused siblings. However, 'current NFL state' is vague enough that an agent won't know exactly what data to expect.

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 guidance is given about when to choose this tool over siblings like sleeper_list_leagues or sleeper_trade_context. The description implies the configured username is the default, but does not explain when to call this first vs other account/league tools.

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

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

Annotations already declare readOnlyHint=true and openWorldHint=true. The description adds context by specifying the data fields returned and that it is a live roster, but it does not go beyond that into behaviors like rate limits, auth needs, or response truncation. This is a modest addition above annotations, waranting a 3.

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 no fluff. The verb and scope are front-loaded, the data fields are compactly listed, and the use case is stated in the second sentence. 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?

While thre is no output schema, the description enumerates the key data fields (player names, positions, teams, injury status, records, FAAB, lineup grouping), which gives an agent a solid picture of the return content. Minor gaps like pagination or ordering are not critical for a read-only listing tool with one parameter.

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

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

Schema description coverage is 100% for the only parameter (league_id: 'Numerick Sleepper league ID'), so the schema handles param semantics. The description does not add extra meaning beond the league context, matching the baseline of 3 for full schema coverage.

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

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

Description states a specific verb ('Get') and resource ('every team’s live roster in a league') and enumerates what is included (player names, positions, teams, injury status, records, FAAB, lineup grouping). It clearly distinguishes from siblings like sleeper_my_roster by emphasizing league-wide scope and 'league-wide comparisons.

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

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

The description gives a clear use case: 'Useful for league-wide comparisons.' This implies when all rosters are needed rather than a single roster, though it does not explicitly name alternatives or state exclusions. Context is apparent from the league-wide wording.

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 and openWorldHint=true, so the description does not need to restate safety. It adds useful behavioral detail by disclosing that the board can be live or completed and what the returned data includes, which is valuable in the absence of an output schema.

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 no filler: the first states capabilities, the second states the parameter-based usage model. Both sentences earn their place and the most important information is front-loaded.

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

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

The description covers the return contents well and the annotations cover safety, but it leaves important invocation details unclear: the role of `draft_season`, what happens if both `league_id` and `draft_id` are supplied, and whether at least one is required. These gaps matter for an agent selecting parameters.

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 67%: `league_id` and `draft_season` have schema descriptions, while `draft_id` does not. The description adds meaning by explaining the league-ID-versus-draft-ID relationship, but it does not explain how `draft_season` interacts with either parameter, leaving a meaningful ambiguity.

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

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

The description opens with a specific verb ('Get') and a clear resource ('draft board'), then enumerates the exact content returned: resolved player picks, draft order, and traded draft slots. This is specific enough to distinguish from the listed siblings, none of which target draft-board data.

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

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

The description gives explicit input-selection guidance: use a league ID for the newest draft or a draft ID for a specific draft. It does not explicitly discuss when not to use this tool or mention the `draft_season` parameter, but the primary usage context is clear.

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 the safety profile (readOnlyHint=true, openWorldHint=true), so the description's job is to add scoping context. It discloses exactly what league data is returned and, notably, flags that future pick ownership is 'calculated' derived data rather than raw stored data. It does not disclose aggregation cost or partial-failure behavior, but the content scope is the key behavioral trait for a read-only overview 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?

Two sentences with zero filler: the first front-loads the full content list, the second adds a deliberate boundary. Every clause earns its place and the density-to-length ration is excellent.

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

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

For a tool with no output schema and ten sibings spanning overlapping domains (drafts, rosters, trades, transactions), the description supplies a usable category list but omits return sturcture, the time scope of 'records', and how pick_years interacts with the calculated ownership data. The roster exclusion helps disambiguate, yet an agent calling this tool is still guessing at the response shape for a fairly complex aggregation.

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 67% (league_id and pick_years have descriptions, username does not), and the description contributes zero parameter guidance. The 'username' parameter is left unexplained in both the schema and the description — an agent cannot tell whether it filters scope, authenticates, or is merely optional context alongside the required league_id. The description also never connects pick_years to the 'calculated future pick ownership' it mentions.

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 uses a specific verb ('Get') with a detailed content list — rules, scoring, lineup slots, team directory, records, drafts, traded picks, and calculated future pick ownership — that precisely scopes the resource. The exclusion clause ('Does not include every player on every roster') explicitly disambiguates it from roster-oriented sibings like sleeper_all_rosters. It stops short of 5 because it never names a sibing tool outright, relying on the 'overview' naming to carry 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?

The content list implies this is the comprehensive league-level entry point, and the final sentence signals when not to use it (when complete roster data is needed). However, no alternative sibing is named and there is no explicit when-to-use/when-not-to-use guidance, leaving the agent to infer routing from the tool name and the exclusion clause.

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

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

The annotations already declare readOnlyHint=true and openWorldHint=true, so the description does not need to restate safety. It adds useful scoping context: 'configured user’s NFL leagues for a season' and the mapping purpose. However, it does not disclose additional behavioral details such as response shape, pagination, or how include_roster_ids affects the result. This is adequate but not rich behavioral disclosure.

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 no fluff. The first sentence states the action and scope, and the second provides immediate usage direction. Every word 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?

The tool is relatively simple and the description covers its core purpose and first-step usage. However, there is no output schema and the username parameter is not clearly explained in either the schema or description. The role of include_roster_ids is left to schema text. These gaps keep it from being fully complete, though annotations and context signals reduce the risk.

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 around 67%, with season and include_roster_ids documented in the schema but username left undocumented. The description adds some meaning via 'configured user’s', which hints at username's role, and 'for a season' aligns with the season parameter. It does not add detail about include_roster_ids, but the schema already describes that parameter. Overall, the description partially compensates for schema gaps without fully clarifying all 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: 'List the configured user’s NFL leagues for a season.' It also clarifies the intended output purpose with 'map league names to league IDs,' which distinguishes it from sibling tools like sleeper_league_overview. This is more than adequate for an agent to understand what the tool does.

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

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

The description gives clear usage context: 'Use this first to map league names to league IDs.' This tells an agent when to invoke it, but it does not explicitly mention when not to use it or name alternative tools. It stops short of the rubric's strongest 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=true and openWorldHint=true, so the safety profile is covered. The description adds useful context by noting points are 'current' and starters are 'resolved,' implying a live snapshot, but it does not disclose defaults or edge-case behavior around the optional week parameter.

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 compact sentence front-loads the core purpose and then lists exactly what data will be returned. There is no filler, redundant phrasing, or repetition of structured schema 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?

This is a simple read-only tool with two parameters and no output schema. The description adequately conveys the returned matchups content, but it omits the default behavior for the optional week parameter, which is a minor completeness 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 description coverage is only 50%: league_id is described, but week is not semantically explained beyond numeric bounds. The description refers to 'one league week' but does not clarify the default when week is omitted or the exact meaning/format of the week value, so it fails to compensate for the coverage gap.

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

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

The description states a specific verb ('Get') and resource ('one league week's matchups') and enumerates the included data: resolved starters, bench players, lineup slots, and current points. This makes its purpose clear and distinguishes it from sibling tools like sleeper_league_overview or sleeper_all_rosters.

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

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

The description provides clear context for when to use it: for weekly matchups with lineup and points detail. It doesn't explicitly name alternatives or exclusions, but the scope is specific enough that an agent can infer the right situation.

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, so the safety profile is covered. The description adds meaningful behavioral detail beyond that: the roster is 'live', resolved to player names, grouped into specific roster slots, and includes draft-pick ownership. This gives the agent a clear expectation of what the tool returns.

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 entire description is one efficient sentence that front-loads the core action and scope, then packs all relevant output details. Every phrase earns its place, and there is no filler or repetition of schema fields.

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

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

For a read-only tool with no output schema, the description does a good job of conveying the result shape and primary parameter. However, it leaves the optional username parameter unexplained and does not address edge cases or when a caller should look elsewhere, so the context is adequate but not fully complete.

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

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

Only league_id has a schema description, and the tool description adds no explanation of the optional username parameter. The phrase 'configured user' hints at a default user, but it does not clarify whether supplying username overrides the configured user or how it interacts with the lookup. This is a real gap for an agent deciding whether to pass username.

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

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

The description opens with a specific verb ('Get'), names the resource ('configured user's live roster'), and scopes it to one league. It further specifies output details (resolved player names, grouping into starters/bench/reserve/taxi/keepers, draft-pick ownership), which clearly distinguishes it from broader sibling tools like sleeper_all_rosters.

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

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

The phrase 'configured user' and 'one league' imply when this tool is appropriate, but the description never explicitly states when to choose it over alternatives such as sleeper_all_rosters or sleeper_league_overview. An agent must infer the boundary rather than being told.

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 provide readOnlyHint=true and openWorldHint=true, so the safety profile is covered. The description adds that matching is by player name with an optional position filter, but discloses no deeper behavior such as match semantics, result limits, or handling of special entries. With annotations present, a 3 is fair.

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 core operation is front-loaded, followed by a single use-case sentence. No repetition of the title, no filler, and 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?

For a simple four-parameter, read-only search tool, the description supplies adequate selection and invocation context. The main gap is that with no output schema it does not indicate what a result record contains (e.g., player ID), which would fully serve the stated name-resolution use case.

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

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

Schema description coverage is 0%, so the description must compensate. It gives real meaning to two parameters — 'query' is a player name and 'position' is a player position — but says nothing about 'limit' or 'active_only', leaving them to inference from their property names and schema constraints. This is only partial compensation.

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 says exactly what the tool does: search Sleeper's player directory by name, with an optional position filter. The verb+resource is specific, and all siblings target different resources (leagues, rosters, transactions, matchups, drafts), so this is easily distinguishable.

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 a concrete scenario — resolving player names in a proposed trade — which tells the agent when to reach for this tool. It does not name alternatives or state when not to use it, so it misses the top score.

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 signal read-only and open-world behavior; the description adds useful context by disclosing that pending private trade offers are not available through the official API and must be pasted or described. It also states what content the tool returns, adding value beyond the annotations.

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

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

Three sentences, each earning its place: purpose and contents, team identification, and an important API limitation. The most decision-relevant information is front-loaded, with no redundant filler.

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

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

For a read-only data-retrieval tool, the description covers purpose, output scope, identification options, and the key limitation around private offers. It does not describe error behavior or exactly how pick_years controls future pick inventories, but annotations and schema cover the core safety profile.

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 50%, with league_id and team_queries described. The description adds meaning by explaining team identification via roster ID, owner name, username, or team name and mentions future pick inventories, which maps to pick_years. However, username and pick_years semantics remain partially inferred rather than explicitly defined.

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

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

The description opens with a specific verb and resource: 'Get focused trade-analysis context for selected teams,' then enumerates what it returns (full rosters, league rules, records, future pick inventories). This clearly separates it from sibling roster/league tools like sleeper_all_rosters and sleeper_league_overview.

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 for when to use the tool: for focused trade analysis on selected teams, identified by multiple key types. It does not explicitly name sibling alternatives or state when not to use it, but the scope is clear enough for an agent to route to it appropriately.

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

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

The annotations already declare readOnlyHint and openWorldHint, so the description only needs to add behavior beyond safety. It adds the default week window and the completed/pending scope, but it does not clarify what 'resolve' means or how the status maps to Sleeper exact values; this keeps it at a 3.

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 no filler: the first front-loads operation and resource, the second gives the default range. 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 read-only listing tool with no output schema, the description covers the essential invocation facts: league scope, optional week range with defaults, and transaction/status categories. It is slightly less complete around exact status strings and response contents, but the annotations and schema cover the remaining safety and required-parameter details.

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 only 40%, and the description compensates by mapping week range to start_week/end_week with a default, explaining completed/pending as status scope, and listing trades/waivers/free-agent moves for the types enum. It does not specify inclusiveness of start/end weeks or exact status strings, so not a 5.

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

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

The description names a concrete operation ('get and resolve') on a specific resource ('transaction records'), spells out the three transaction categories, and scopes by league and week range. This clearly separates it from siblings such as roster, matchups, and trade_context tools.

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

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

There is no explicit when-to-use or when-not-to-use guidance and no sibling tool is referenced. The only operational hint is the default week range, which helps invocation but does not help an agent decide between this and sleeper_trade_context or other league data tools.

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

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

Annotations readOnlyHint and openWorldHint already cover the safety profile. The description adds the temporal-window and add/drop focus, but doesn't mention output format, pagination, or how trends are calculated. This is adequate but not deeply transparent.

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 sentence that is front-loaded with the action and contains no filler. Every word contributes to understanding the tool's purpose.

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

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

For a read-only tool with optional parameters, the description plus schema constraints give enough information for an agent to make a correct call. Lack of an output schema is not a major gap since the return is intuitively a list of players, though explicit return fields would have improved completeness.

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

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

With schema description coverage at 0%, the description must compensate. It indirectly explains the 'type' parameter ('added or dropped') and 'lookback_hours' ('recent time window'), but says nothing about 'limit'. The schema constraints provide only numeric bounds, not semantic meaning.

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 action ('Get') and a concrete resource: 'players most frequently added or dropped on Sleeper over a recent time window.' This clearly distinguishes it from siblings like sleeper_search_players by focusing on trending activity rather than general search.

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

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

The description provides clear context about when to use the tool — to retrieve recent add/drop trends. It doesn't explicitly name alternatives or exclusion conditions, but the use case is obvious enough that an agent won't confuse it with the sibling tools.

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