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

Annotations already mark this as read-only and non-destructive, and the description adds useful behavioral context: exactly one authenticated request is made and the response includes an 'ok' flag that indicates whether a new token is needed. This goes beyond the structured annotations without contradicting them.

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

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

The description is two concise sentences. The first sentence states the action, and the second gives actionable decision guidance. Every word adds value, 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?

For a zero-parameter tool with no output schema and low complexity, this description is complete: it explains how to invoke the tool, what it does, and how to interpret the result. The follow-up instruction about requesting a new token closes the loop.

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

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

The tool has zero parameters and schema coverage for descriptions is 100%, so the schema is complete. The description does not need to explain parameters, and it correctly implies the call requires no arguments.

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 ('Make one authenticated request') and resource ('the session token'), and it clearly explains the tool's purpose: verifying session validity. This distinguishes check_auth from the data-retrieval sibling tools, which all focus on gathering league or player information.

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 context for when to use the tool: to test the session token. It also provides a concrete follow-up action ('Ask for a new token when ok is false'), which helps the agent know how to respond to the result. It does not explicitly name alternatives or exclusions, but no auth-related sibling exists, so the guidance is sufficient.

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?

With annotations that only establish this is a write (readOnlyHint false), the description usefully adds that the action reserves rather than posts and warns against duplicate claims. However, it does not explain what happens after the reservation, whether the claim expires, or how duplicate requests are handled beyond the warning.

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 short sentences, with the primary action and precondition in the first and a critical duplicate-prevention warning in the second. There is no filler and the most important behavioral constraint is front-loaded.

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

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

For a mutation with no output schema and a single undocumented parameter, this description leaves key invocation details unstated: what request_id refers to, how a claim is created or observed, and what the caller should expect in response. The precondition and duplicate warning help, but an agent lacks enough information to use the tool correctly in a multi-step flow.

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

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

The schema has 0% description coverage and the description never mentions request_id, so the string parameter's meaning is only inferred from its name. The warning about existing claims hints that request_id may identify a prior claim, but the description does not explicitly connect the parameter to the claim or say where the ID comes from.

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

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

The description names the action ('Reserve') and the object ('one browser submission') and adds a precondition ('after user authorization'), which makes it distinguishable from sibling posting/preparation tools. The phrase 'browser submission' is somewhat jargon-heavy but does not obscure the core claim/reserve semantics.

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 guidance not to call this when a claim already exists ('Never resubmit an existing claim') and sets an authorization precondition. It does not name alternatives such as post_league_chat or prepare_chat_post, so an agent must infer when this tool is the right choice 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?

The annotations already declare readOnlyHint=true and destructiveHint=false, so the read-only safety profile is established. The description adds useful context about user scoping and season format, but it does not disclose return shape, pagination, or any behavioral constraints beyond that.

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 with no filler. Every word earns its place, and it avoids repeating any schema field names or annotation details.

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

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

For a simple read-only tool with one required parameter, the description provides the core operation and parameter format. The main gaps are the lack of output-shape hints and explicit routing relative to siblings, but these are minor given the tool's simplicity and the annotation coverage.

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 carry the parameter-semantics burden. It adds meaningful meaning by specifying 'four-digit NFL season', which clarifies the expected format beyond the bare string type. An example value would strengthen it, but for one simple parameter this is solid 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 states a specific verb ('Find'), a resource ('configured user's leagues'), and a qualifier ('four-digit NFL season'). It is clear and not tautological, but it does not explicitly differentiate itself from close siblings like get_all_leagues_summary or get_league_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?

There is no guidance on when to use this tool versus alternatives such as get_all_leagues_summary or get_league_data. The phrase 'configured user's' implies it applies to the authenticated user, but no explicit when-to-use, exclusions, or prerequisites are provided.

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 destructiveHint=false, so the agent knows it's safe. The description adds the notion of 'separate private contexts' which hints at scoping, but doesn't elaborate on behavior like whether it initializes contexts or just reads them. It doesn't contradict annotations.

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

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

The description is a single well-structured sentence that leads with the verb and resource. It is concise and complete for its length.

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

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

Given the tool has no output schema and annotations only cover safety, the description should explain what 'contexts' means, how 'week' affects results, and how this relates to other league tools. The current description is minimal and would benefit from more detail, but it does cover the core action.

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

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

The schema has only one optional parameter 'week' with a default of null, and the description does not explain what 'week' does or how it affects the results. With 0% schema coverage, the description should compensate but doesn't. I'll give a 3 because the parameter is optional and its purpose is somewhat inferable.

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

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

The description clearly identifies the verb 'Return' and the resource 'separate private contexts for all configured leagues,' which distinguishes it from siblings like discover_leagues. It implies a scope (all configured leagues) but doesn't specify what a 'context' includes.

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 guidance on when to use this tool versus alternatives. Given the breadth of sibling tools (e.g., get_league_data, discover_leagues), the description lacks context on when this summary is appropriate or how it differs from those.

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 indicate read-only and non-destructive behavior, and the description adds a valuable behavioral detail: it makes no network request. This tells the agent this operation is safe, fast, and appropriate even in offline or rate-limit-sensitive contexts.

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 tightly written sentence that states the resource, the verb, and the key non-network behavior. Every word adds value, and the most important distinguishing feature is placed at the end without sacrificing clarity.

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

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

For a zero-parameter, read-only status tool with no output schema, the description is complete. It states what the tool displays, implies no side effects, and gives the agent enough to invoke it correctly and interpret the result.

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 are zero parameters, so there is nothing for the description to explain. The baseline for a no-parameter tool is 4, and the description loses no points since it does not omit any required parameter context.

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

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

The description uses a specific verb ('Show') and identifies an unambiguous resource ('persistent cache counts and configured freshness limits'). It also adds the unique capability 'without a network request', which clearly distinguishes this diagnostic tool from projection, player, and league-data siblings.

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 makes the intended context clear: use this when cache status or freshness limits are needed and no network call is desired. It does not explicitly name alternatives or exclusions, but the zero-parameter diagnostic nature makes the usage condition easy to infer.

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

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

Annotations already convey that the tool is read-only and non-destructive (readOnlyHint=true, destructiveHint=false), which covers the main safety profile. The description adds one useful behavioral detail, that the comparison targets the latest successful local snapshot, but does not disclose what counts as a change or how results are returned.

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 a single short sentence with no filler or redundancy. It front-loads the main action and resource, making it easy to scan; every word contributes to the tool's identity.

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 does not explain what the returned 'changes' look like or what the tool actually produces. It also fails to clarify failure behavior or when a comparison is meaningful, leaving important operational context absent for such a narrowly scoped 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 0%, so the description must compensate, but it never explicitly explains league_id or snapshot_id. The phrase 'league snapshot with its latest successful local snapshot' hints at which resources the parameters refer to, but the agent still cannot determine the precise role or expected format of each parameter.

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 ('Compare') on a specific resource ('a league snapshot' vs its latest successful local snapshot'), so the core purpose is clear. It does not explicitly differentiate itself from sibling tools, but the snapshot-comparison scope is distinctive enough that an agent can infer its purpose.

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 no guidance on when to use this tool instead of siblings such as get_league_data, get_data_health, or get_league_chat. There are no conditions, exclusions, or references to alternatives, leaving the agent to guess the appropriate context.

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

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

Annotations already mark this as read-only and open-world, and the description adds meaningful behavior beyond those annotations by warning that a missing match is not proof of failure. This is exactly the kind of open-world nuance that helps an agent interpret results correctly. It does not describe the full return shape, but the disclosure it provides is valuable.

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

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

The description is two sentences with zero filler: the first clearly states the action, and the second provides a crucial caveat. It is front-loaded and 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?

For a single-parameter, read-only tool with annotations already covering safety, the description covers the core purpose and a key behavioral caveat. However, it does not define request_id, describe what statuses or outcomes may be returned, or explain how 'fresh chat' is determined, leaving some gaps given there is no output schema.

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

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

The schema has one required parameter, request_id, but the schema description coverage is 0% and the description never mentions request_id. The parameter name itself gives a weak hint that it identifies a request, but the description adds no semantic detail about what value should be supplied or how it relates to the claimed post.

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 ('Verify') and a specific resource ('a claimed post against fresh chat'), making the tool's function clear. It differentiates from siblings like claim_chat_post by focusing on verification rather than creation or claiming, though it does not name any 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?

The description implies when to use this tool: after a claim has been made and you need to verify it against fresh chat data. It offers an important interpretive caveat ('A missing match does not prove delivery failed'), but it does not explicitly state when to prefer this tool over alternatives such as get_league_chat or search_league_chat.

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

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

The annotations already mark the tool read-only and non-destructive, so the description does not need to cover those basics. The description adds a meaningful behavioral limitation beyond the annotations: it does not test authentication, preventing an agent from misinterpreting auth failures as data-health issues.

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 short sentences deliver the core purpose and the key limitation with no filler. The main function is stated first and the important caveat follows immediately.

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-parameter, read-only tool, the description gives the agent the essential high-level return concept and the critical limitation. It could specify the exact shape or categories of configuration/capability limits, but nothing necessary to invoke the tool correctly is missing.

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

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

The tool has zero parameters, so the empty input schema is fully self-explanatory and the description has no parameter burden to carry. The baseline of 4 for a no-parameter tool 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?

The description states a clear verb and resource: it reports configuration and capability limits, rather than simply restating the tool name. It also adds an explicit boundary by saying it does not test authentication, which helps separate it from auth-focused siblings, though 'configuration and capability limits' remains somewhat abstract.

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 a useful when-not signal: this tool will not test authentication, so an agent should not reach for it to check auth status. However, it does not name an alternative tool or state positive conditions for choosing this tool over closely related siblings like get_cache_status.

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 destructiveHint=false, so the 'Read a draft' language is consistent and there is no annotation contradiction. The description adds one behavioral nuance—membership verification as a prerequisite—but says nothing about error behavior, rate limits, or what happens if the draft is not in the league.

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

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

The description is a single front-loaded sentence: 'Read a draft' comes first, and the membership verification clause adds meaningful context without fluff. It is concise and every word earns its place, though it is slightly under-specified, so it misses a 5.

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

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

The tool has three required parameters and no output schema, so the description should provide enough context for a correct call, including how the parameters relate and what the available resource values provide. It only states the draft's membership precondition, leaving resource semantics and return expectations unexplained.

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

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

The input schema has 0% description coverage, so the description must compensate, but it only clarifies the league-id/draft-id relationship via 'membership in the selected league.' It does not explain draft_id, league_id, or what each resource enum value returns, leaving most parameter meaning to the raw property names and the enum.

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 ('Read') and names a target resource ('a draft'), making the tool's core purpose clear and distinct from many siblings such as get_league_data or get_nfl_state. It stops short of 5 because it does not specify what kinds of draft data (details, picks, traded picks) are returned, leaving the schema enum to carry that load.

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 'after its membership in the selected league is verified' provides an implied precondition: call this only once you have confirmed the draft belongs to the selected league. There is no explicit guidance on when not to use it or how it compares to sibling read tools like get_league_data, so it does not fully earn a 4.

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

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

Annotations already indicate readOnlyHint=true and openWorldHint=true description adds the caveat that 'History coverage and upstream order remain unverified.' This provides useful behavioral context beyond the annotations, warning the agent that results may be incomplete or not strictly ordered.

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 very concise, consisting of two short sentences. The core purpose is front-loadedlorized, and the caveat is valuable rather than filler. It could be improved by adding parameter semantics without bloating the text.

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 there is no output schema and no parameter descriptions, an agent likely cannot correctly invoke this tool without extra context. The description does not mention what a 'chat page' contains, how to paginate, or what 'before' expects. The caveat is interesting but not enough to make the tool usable.

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% for all three parameters (league_id, limit, before), and the description does not explain what each parameter does. 'Read a chat page' gives no clue about pagination semantics, the meaning of 'before,' or how limit applies. The description fails to compensate for the missing schema descriptions.

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

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

The description states a clear verb and resource: 'Read a chat page.' It implies a read operation on a league chat, which distinguishes it from siblings like post_league_chat or search_league_chat. However, it does not explicitly mention 'league' or pagination in the purpose statement.

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

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

There is no guidance on when to use this tool versus alternatives such as search_league_chat or post_league_chat. The description only says 'Read a chat page' with no exclusions or context for when the alternative tools should be chosen.

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 readOnlyHint and destructiveHint annotations already establish that this is a safe read operation, so the description is not burdened with that disclosure. It adds one behavioral detail beyond the schema—the week requirement for matchups and transactions—but it does not cover other behavioral aspects like return shapes or error conditions.

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

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

The description is two short sentences with no filler. The action is front-loaded and the key constraint is placed in the second sentence, making it easy for an agent to parse quickly.

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

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

Given the annotations and the resource enum in the schema, this is minimally viable: the agent knows it is a read operation and that week is required for certain resources. However, with no output schema and no guidance on what is returned for each resource or how league_id is structured, the description leaves notable gaps.

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. The description adds meaning only for the 'week' parameter by noting it is required for matchups and transactions, and it loosely implies that 'resource' contains league data. It leaves 'league_id' and most resource enum values semantically unexplained, which is insufficient for three 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 starts with a clear action verb, 'Read', and names the object as 'a configured league resource' plus a distinguishing hint, 'with player names'. This makes the tool's basic purpose clear and separates it from write-oriented tools, though it does not explicitly differentiate from specialized siblings like get_matchup or get_standings.

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

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

The description gives one useful condition: 'Matchups and transactions require a week,' which tells the agent when a parameter is mandatory. However, it does not explicitly state when to prefer this tool over the many sibling alternatives, so usage is implied rather than directly specified.

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

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

Annotations already declare readOnlyHint=true, openWorldHint=true, and destructiveHint=false, and the description's 'Read' matches that safety contract. It adds the sections-limiting behavior but provides no additional operational context such as caching behavior or auth dependencies.

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: a clear statement of what the tool reads, followed by a direct instruction on limiting output. Every sentence earns its place, with no filler or redundancy.

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

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

The sections parameter is well explained, but mode and week are ambiguous, and there is no output schema to compensate. An agent would have to guess the semantics of cache_only/refresh and week, so the definition is not self-sufficient.

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

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

With 0% schema description coverage, the description must carry parameter meaning; it does for sections by enumerating valid values like settings, rosters, and chat. However, mode (normal/cache_only/refresh) and week are left unexplained, so coverage is only partial.

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 opens with 'Read league facts, owned roster, projections, and chat for a private review', giving a specific action and resource set. It stops short of 5 because the broad scope overlaps with sibling getters like get_league_data and get_league_chat, and it doesn't explicitly distinguish itself from run_manager_review.

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 only guidance is 'Pass sections to limit output', which is an invocation tip rather than a selection rule. It never states when to prefer this tool over run_manager_review, get_league_data, or get_league_chat, nor any exclusions.

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 destructiveHint=false, so the agent knows this is a safe read operation. The description adds useful context about what data is returned (names, injuries, projections, actual points), but it doesn't disclose behavior like whether it returns data for the current week by default, how it handles missing lineups, or whether it requires authentication. With annotations covering the safety profile, a 3 is appropriate.

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 a single, efficient sentence that front-loads the core purpose and lists the key data fields. It earns its place with no wasted words, though it could be slightly more explicit about the optional week parameter.

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 covers the main return fields (names, injuries, projections, actual points) but misses important context: the week parameter is optional and defaults to null, and the tool likely requires an authenticated league context. Given the tool's simplicity and the annotations covering safety, this is adequate but not complete.

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

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

Schema description coverage is 0%, so the description must compensate. It mentions 'for a week' which maps to the week parameter, but it doesn't explain that week is optional and defaults to null (presumably current week). It also doesn't clarify what league_id refers to beyond the obvious. The description adds some meaning but leaves the week parameter's semantics ambiguous.

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

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

The description clearly states the tool's function: showing both lineups for a week, including names, injuries, projections, and actual points. It uses a specific verb ('show') and resource ('my lineup and my opponent's lineup'), which distinguishes it from siblings like get_week_projections or get_player_week_stats_and_projections.

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 implies usage for viewing a weekly matchup, but it does not explicitly state when to use this tool versus alternatives like get_week_projections or get_manager_context. It also doesn't mention that week is optional or defaults to the current week, which is important context for an agent deciding whether to call this tool.

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

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

Annotations already declare readOnlyHint=true, destructiveHint=false, and openWorldHint=true, covering the safety profile. The description adds modest context by specifying the data comes from Sleeper and the exact scope of the read, but it does not disclose behaviors like data freshness, return shape, or potential delays. This is acceptable given the annotations.

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

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

The description is a single, focused sentence with no filler or redundant wording. It front-loads the primary action ('Read') and immediately states the resource, making it easy to scan.

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

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

For a zero-parameter, read-only state tool with strong annotations, the description covers the essential information. The only minor gap is that 'league-season context' is somewhat vague and the return content is not elaborated, but this is a simple state fetch and the description is adequate 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?

The tool has zero parameters, so per the rubric the baseline is 4. The description correctly avoids inventing parameter details, and there is no schema information to compensate for.

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 uses a specific verb ('Read') and names the resource ('season, week, and league-season context from Sleeper'), making the tool's function clear. It does not explicitly differentiate from siblings like get_league_data or get_schedule, but the resource scope is distinct enough for an agent to infer its purpose.

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 use this tool versus alternatives such as get_league_data or get_schedule. The usage context is only implied through the description's mention of season/week context, with no explicit when-to-use or when-not-to-use direction.

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, but the description adds meaningful behavioral context beyond them: outputs are raw, un-scored statistics and projections. It does not describe return format or edge cases, but for a read-only tool the added context is valuable.

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 short sentences with no filler. The core action is stated first, and the important qualifier about league scoring is front-loaded. 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?

For a tool with four parameters, no parameter descriptions, and no output schema, the description is too sparse to be fully actionable. It does not clarify the expected format for player_ids or season, the meaning of week, or the effect of season_type, leaving the agent to rely on parameter names alone.

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%, and the description does not explain player_ids, season, week, or season_type. The text adds no meaning beyond the parameter names already visible in the schema, so the description completely fails to compensate for the missing parameter documentation.

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 ('Read') and resource ('raw actual statistics and projections'), and clearly distinguishes this tool from siblings like get_week_projections by noting that no league scoring is applied. The scope is immediately understandable.

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 implies when to use the tool ('raw' and 'no league scoring is applied'), but it does not explicitly state when to prefer it over alternatives such as get_week_projections, nor does it provide exclusions. The usage context is clear but the guidance is implicit rather than explicit.

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 readOnlyHint, openWorldHint, and destructiveHint, so the safety profile is known. The description adds a key behavioral limitation ('No kickoff times') and an inclusion ('teams on bye'), which goes beyond annotations. It does not contradict annotations and provides useful contextual detail.

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 a single, well-structured sentence that front-loads the main content and places the exclusion at the end. Every word adds value; there is no fluff or redundancy.

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

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

With no output schema, the description should clarify the return structure. It mentions 'games with date and status' but not whether it's an array, how teams are represented, or what status values look like. It also lacks parameter format details. An agent calling this tool would have to infer too much.

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%, and the tool description provides no explanation for the 'season' or 'week' parameters. It does not specify format, valid ranges, or meaning beyond the property names, failing to compensate for the missing schema descriptions. The agent must guess expected inputs.

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

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

The description clearly states the resource (NFL games for a week) and specifies what is included (date, status, teams on bye) and explicitly excludes kickoff times. This distinctively differentiates it from siblings like get_week_projections and get_nfl_state, making its 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?

The description gives no guidance on when to use this tool versus alternatives. It does not mention any conditions for selection or exclude cases, leaving the agent to infer usage solely from the resource name. With many siblings present, this is a notable gap.

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 the operation as read-only and non-destructive, covering the safety profile. The description adds useful context about what is returned (standings sorted by wins then points for, with team and manager names), but it does not disclose limitations or edge-case 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?

The description is a single, well-structured sentence that front-loads the resource and then packs sorting rules and output fields. There is no filler and every part 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 one-parameter read-only tool with no output schema, the description provides the essential return-content details and the annotations cover safety. The main missing piece is guidance on sourcing league_id, but this is a minor gap given the tool's simplicity.

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

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

The schema has 0% description coverage and the description does not explain league_id beyond implying a league context. It offers no guidance on where the ID comes from, accepted formats, or how it maps to the returned standings, leaving a real gap for the agent.

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

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

The description clearly identifies the resource (league standings) and adds meaningful detail about sorting and included fields. It distinguishes the tool from siblings by specifying the exact content and order, though it lacks an explicit verb.

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

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

There is no guidance on when to use this tool compared to related siblings like get_league_data or get_matchup. The intended use must be inferred from the name and description, with no exclusions or alternative routing provided.

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

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

Annotations already declare read-only, non-destructive behavior. The description adds valuable context by clarifying that the values are popularity/trend data rather than projections, which reduces the risk of misuse. It does not mention rate limits or auth, but these are less critical for this simple read operation.

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

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

The description is two short sentences with no filler. The main action and resource are front-loaded, and the important caveat about projections is concise and purposeful.

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 and helpful schema titles/defaults, this description is nearly sufficient for invoking the tool correctly. However, there is no output schema and the description only mentions 'player names,' leaving the broader response shape and the practical effect of `lookback_hours` and `limit` to inference.

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 needed to compensate. It only echoes the 'add/drop' concept behind the `kind` parameter and provides no explanation of `limit` or `lookback_hours`. The schema titles and defaults help, but the description itself contributes little parameter-level 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 uses a specific verb ('Read') and names the resource ('Sleeper add/drop trends') plus the key content ('player names'). The caveat that popularity is not a projection helps separate it from projection-related siblings, though it does not explicitly name an alternative.

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

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

The description implies the tool should be used for add/drop popularity trends and warns against treating it as projections. However, it does not explicitly state when to choose this over siblings like get_week_projections or search_players, nor does it provide a clear exclusion list.

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 and non-destructive behavior. The description adds a useful caveat about eligibility checks, but does not disclose output shape, pagination behavior, or any auth/rate-limit context; with annotations lowering the bar, this is adequate but not rich.

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 short sentences with the core action front-loaded and the limitation placed second. Every word earns its place; no filler.

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

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

With five parameters, a 0% schema description coverage, and no output schema, this is under-specified. The agent doesn't learn what result objects look like, how query/position interact, or how pagination works, so it is not 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 description coverage is 0% and the description does not explain any of the five parameters. An agent gets no guidance on query syntax, position allowed values, limit/offset semantics, or league_id beyond the raw schema.

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

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

The description uses a specific verb-resource pair ('Find unrostered players') and clarifies the scope by stating it does not verify waiver or immediate-add eligibility. This differentiates it from siblings like search_players or get_trending_players, which imply broader or different player searches.

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 implies use for browsing unrostered players and gives an important when-not: don't treat results as waiver/eligibility-verified. However, it never names an alternative tool or gives a positive condition for choosing this tool over siblings.

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

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

Annotations already establish readOnlyHint=true and destructiveHint=false, and the description adds meaningful behavioral context: the data is public, results are sorted by PPR points, and passing a league_id changes results to unrostered players only. This goes beyond the safe-read signal and helps an agent anticipate output ordering and scoping 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?

Two tightly written sentences deliver the essential purpose and key behavioral modifier with no filler. The most important information is front-loaded, and every clause adds value.

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

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

For a read-only tool with annotations and a schema that includes enums and defaults, the description covers the main invocation-relevant details: data source, projection/stat duality, sorting, and the league_id filter. It does not describe return structure in depth, but that is partially mitigated by the mention of point totals and PPR sorting.

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 0% schema description coverage, the description must carry parameter meaning. It does clarify category by mentioning 'projections or actual stats' and explains the effect of league_id. However, it does not describe season, week, position, or limit semantics, though those parameter names and the schema enums/defaults make them reasonably self-explanatory.

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 clear verb and resource: 'Read Sleeper's public week projections or actual stats with point totals, sorted by PPR points.' It is specific enough to understand the core function, but it does not explicitly distinguish itself from the similarly named sibling tool get_player_week_stats_and_projections, so it falls short of full sibling differentiation.

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

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

The description provides useful context such as public data and the league_id behavior ('A league ID limits results to unrostered players'), which implies when league_id should be used. However, it does not explicitly state when to use this tool versus alternatives like get_unrostered_players or get_player_week_stats_and_projections.

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 is a write operation (readOnlyHint=false) and non-destructive. The description adds genuinely useful behavioral context beyond that: the post is made 'as the configured user' (identity semantics), and crucially, the tool requires explicit user authorization for the exact text and league before executing. This authorization requirement is a material behavioral trait an agent needs to know.

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 first sentence front-loads the action and scope; the second delivers the critical authorization precondition. 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 mutation tool with no output schema and a chat-tool family around it, some gaps remain: the description doesn't indicate what the tool returns after posting (ID? status?), nor does it place the tool in the surrounding prepare/claim/post/status flow. The most important safety context (authorization requirement) is present, but the operational outcome and flow position are left unspecified.

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 partially does by tying each parameter to its role in the authorization requirement: 'exact text' maps to the text parameter (emphasizing exactness, not approximations) and 'league' maps to league_id as the destination chat. However, it provides no format, value constraints, or examples, leaving the agent to guess at acceptable input shapes.

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 ('Post'), a resource ('league chat'), and a precise scope ('one message', 'as the configured user'). This clearly differentiates it from siblings like get_league_chat (read), search_league_chat (search), and prepare_chat_post (drafting), so an agent can tell them apart without opening schemas.

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

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

The description gives a clear precondition for calling the tool: 'Require explicit user authorization for the exact text and league first.' This effectively tells the agent when it is safe to invoke this tool. However, it does not explicitly name the alternatives in the chat-post flow (prepare_chat_post, claim_chat_post, get_chat_post_status) or state when those should be used instead, leaving some orchestration 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?

The description adds important behavioral context beyond the annotations: it does not submit the post and requires user authorization. However, it doesn't disclose whether a draft or pending post is stored, how authorization is expected to be provided, or what side effects occur before the final submission. With readOnlyHint=false, more detail about the mutation profile would be valuable.

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

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

The description is two short sentences with no filler, and the most important fact—that this tool prepares but does not submit—is front-loaded. The minor grammatical issue ('Require' instead of 'Requires') does not meaningfully harm clarity.

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

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

There is no output schema and no parameter documentation, so the description carries the full burden of explaining the workflow, but it omits what happens after preparation, how authorization works, and what the tool returns. Given the related sibling tools claim_chat_post, post_league_chat, and get_chat_post_status, an agent lacks enough information to sequence 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 0%, and the description provides no parameter-level guidance for league_id, text, or request_id. While text and league_id are somewhat self-explanatory, request_id is highly ambiguous and not explained anywhere. The description fails to compensate for the complete lack of schema documentation.

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: 'Prepare an exact browser-assisted post.' The clarifying sentence 'This tool does not submit it' explicitly differentiates it from the submission step, which helps distinguish it from sibling tools like post_league_chat. It doesn't fully explain what 'prepare' entails, but the core purpose is identifiable.

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?

'This tool does not submit it' clearly signals that this is a staging step rather than the final send action, and 'Require user authorization' states a precondition. It doesn't explicitly name alternatives such as post_league_chat or claim_chat_post, but the negation gives strong contextual guidance about when to use it.

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

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

Annotations already establish that the tool is read-only and non-destructive. The description adds useful context by specifying the display-name format, but it does not disclose behavior for invalid IDs, unmatched IDs, duplicates, ordering, or empty arrays. With annotations covering the safety profile, this is acceptable but not rich.

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 a single, front-loaded sentence with no filler. It efficiently communicates the action, input, and output format while remaining immediately scannable.

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

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

For a simple one-parameter mapping tool with read-only annotations, the description gives enough for an agent to select and invoke it correctly: input is player_ids, output is display names. The lack of an output schema means return-shape details are not fully covered, but the core behavior is clear.

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 carry the meaning of player_ids. It does so by clarifying that the IDs are Sleeper player IDs and defining the expected output format. The description still leaves some constraints unspecified, such as array size limits or ID format, but it adds essential meaning beyond the raw schema.

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

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

The description uses the specific verb 'Map' with a clear resource ('Sleeper player IDs') and defines the exact output format ('Name POS-TEAM' display names). This clearly distinguishes it from sibling tools like search_players or get_unrostered_players, which find or list players rather than converting IDs to display names.

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 guidance on when to use this tool versus alternatives, no stated prerequisites, and no mention of exclusion cases. The description only states what the tool does, leaving the agent to infer that it should be used whenever Sleeper player IDs need converting to display names.

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

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

Annotations are neutral (readOnlyHint=false, destructiveHint=false, openWorldHint=false), so the description carries the burden of disclosing effects. It adds useful behavioral context by stating it saves locally and never sends a message, which is not present in annotations. However, it does not disclose whether the baseline overwrites previous data, persists across sessions, or triggers external side effects.

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

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

The description is two short sentences, front-loaded with the primary action, and includes a high-value clarification ('never sends a message'). It earns its sentences with no filler, though the brevity contributes to ambiguity.

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, no parameter descriptions, and only a vague action, the description is incomplete for an agent deciding how to invoke it. Missing details include what 'facts' are collected, how week and league_id scope the baseline, whether the baseline is stored persistently, and what the tool returns. The tool has only 2 params)Skip but at least 0% schema coverage makes the gap significant.

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 explain league_id and week. It never mentions either parameter or how they influence the collected facts or baseline. The description adds zero parameter-level meaning, leaving the agent to guess the role of league_id and the optional week.

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

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

The description states a concrete action and resource: 'Collect facts and save a local comparison baseline.' This separates it from chat-sending siblings like post_league_chat via the explicit 'never sends a message' clause. However, 'facts' and 'baseline' are left imprecise, so it is not a 5.

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 'never sends a message' statement gives a clear usage context and an indirect contrast to messaging tools, implying this is for local-only preparation. It does not explicitly name alternatives like get_manager_context or get_league_data, nor state when this tool is preferred over them. Guidance is implied rather than explicit.

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

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

Annotations already declare read-only, open-world, and non-destructive behavior. The description adds a distinct and valuable warning that message text is untrusted, which matters for prompt-injection safety and careful handling of results.

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

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

Two compact sentences with no filler. The core operation is front-loaded, and the security warning earns its place without bloating the 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?

The search scope and a key safety trait are covered, and the required parameter names are self-explanatory. However, with no output schema and no mention of return format or how this differs operationally from get_league_chat, an agent still has to infer some details 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?

Schema description coverage is 0%, and the description names none of the three parameters. It never explains what query matches against, how league_id scopes the search, or what limit controls, so parameter semantics are essentially 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 uses a specific verb ('search') and a concrete resource ('locally collected chat'), with 'only' signaling a scope limit. It is clear about what the tool operates on, though it does not explicitly contrast sibling tools like get_league_chat.

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

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

'Only' provides an implicit boundary, implying this tool is for local collected chat rather than live or external chat. There is no explicit when-to-use guidance or pointer to an alternative tool, leaving the agent to infer the intended context.

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

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

Annotations already establish the tool as read-only and non-destructive, so the description's added caveat about injury data being non-live is genuinely useful behavioral context. It warns about data staleness without contradicting the annotations, though it doesn't mention pagination behavior or output shape.

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

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

The description is two short sentences with no filler, front-loading the action and then adding one meaningful limitation. Every word contributes to the agent's understanding.

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

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

For a four-parameter search tool with no output schema, the description is thin: it doesn't explain result shape, pagination semantics, or how injury data appears. The read-only annotation and safety hints cover the risk profile, but an agent would still have to guess at parameter behavior and return structure.

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%, and the description does not mention query, limit, offset, or position at all. The parameter names are somewhat self-explanatory, but the agent receives no additional meaning about formats, constraints, or how the parameters interact.

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 'Search' and a clear resource, 'the daily player directory,' which conveys the tool's core function. It doesn't explicitly differentiate it from siblings like get_unrostered_players or resolve_players, but the 'daily player directory' phrasing narrows the scope enough to be useful.

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 caveat 'Injury data is not a live inactive report' provides an explicit exclusion: this tool should not be used for live injury/inactive status. It doesn't name alternative tools or state when this search is preferable to sibling search tools, so some usage inference is still required.

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