Muffed — verified NFL stats and fantasy context

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

Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the description doesn't need to repeat those. It adds meaningful behavioral context: the tool 'names no winner, no margin and no recommendation' – clarifying it's neutral and not a prediction/ranking tool. It also states that invalid metrics are 'refused with the nearest ones,' revealing a fallback behavior. This goes beyond the annotations and helps the agent set expectations.

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

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

The description is dense but well-structured. It opens with the core purpose, then adds a key behavioral trait (no winner), and then details the metrics parameter. Every sentence adds value; there's no fluff. It's slightly longer than necessary but remains focused. Front-loading the purpose and key behavior helps the agent quickly understand the tool's essence.

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

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

With no output schema, the description must explain the return behavior. It states 'shown side by side,' 'Each side carries its source rank,' and 'States both figures and stops' – giving some idea of output structure. However, it does not clarify the response format (e.g., JSON shape), nor does it explain all parameters (a, b, season, entity_kind). For a tool with 6 parameters and no output schema, the description is moderately complete but leaves gaps that could affect 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%, so the description must compensate. It explains 'metrics' in detail (accepted keys, plain-English names, refusal of non-panel metrics) and mentions 'all:true' for the full set. However, it does not explain 'a', 'b', 'season', or 'entity_kind'. While 'a' and 'b' are presumably entity identifiers and 'entity_kind' is implied by 'two players or two teams', the description leaves these to inference. For a 6-parameter tool with zero schema coverage, this partial coverage is inadequate.

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 compares two players or teams side by side, with a default focus on position-relevant metrics and an explicit option for the full set. It distinguishes itself from sibling tools like get_entity_metrics (single entity) and run_stat_query (derived stats) by emphasizing it shows both figures without declaring a winner, margin, or recommendation. The verb 'compare' and resource 'players/teams' make the purpose specific and unambiguous.

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

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

The description provides clear context on when to use the tool: when you need a side-by-side comparison. It gives explicit guidance on the 'metrics' parameter, stating it accepts verified panel metric keys from list_metrics or plain-English names, and warns that measures only run_stat_query computes are refused. While it doesn't name sibling alternatives like get_entity_metrics or query_stat_leaders directly, the implied contrast (comparison vs single entity vs derived stats) is sufficient. It could improve by explicitly saying 'use this for comparing two entities, not for single-entity metrics.'

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?

While annotations indicate read-only, idempotent, and open-world behavior, the description adds value by specifying data sources (Muffed's handcuff page and Sleeper) and the exact content (depth chart, injury status). This goes beyond the structured annotations and helps set expectations without contradiction.

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

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

The description is two sentences, front-loaded with the core purpose and data sources, and includes a practical use-case question. Every phrase contributes meaning without 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?

Given the single parameter, no output schema, and rich annotations, the description adequately explains what the tool does and what it returns. It could mention the response format or structure, but for a simple lookup tool the provided context is sufficient to understand and invoke 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?

The schema has one parameter 'team' with a full enum of NFL team codes but no property description. The tool description clarifies that the parameter selects a single team's backfield, which is sufficient compensation. The enum itself provides the allowed values, so the meaning is clear.

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: it retrieves a team's backfield handcuff information, depth chart, and injury status. It uses specific verbs like 'answers' and identifies the resource as a specific team's backfield, distinguishing it from sibling tools focused on leagues, players, or metrics.

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 implicitly defines when to use the tool (to find backup running backs and replacements for injured starters). It does not explicitly name alternatives or exclusions, but the context is clear and distinct from sibling 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 destructiveHint=false, so the safe read nature is covered. The description adds valuable behavioral context: insights are 'dated, sourced claim with its supporting figures,' which gives the agent a better understanding of the returned data structure and provenance, despite no mention of auth or rate limits.

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 is front-loaded with the main subject and provides essential information without unnecessary words. It is concise and directly conveys the tool's purpose and source.

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 with two optional parameters and no output schema. The description gives a good overview of the data content but misses parameter semantics and does not describe the return format or how limit/subject affect results. This is adequate but leaves room for improvement.

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 the parameters (limit, subject) at all. Since there are two optional parameters, the description fails to explain their meaning or usage, leaving the agent to infer from the schema alone. This is a significant 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 clearly identifies the tool's purpose: retrieving Muffed's published editorial reads on the current NFL state. It specifies the resource ('editorial reads', '/trends board') and the nature of the content ('dated, sourced claim with its supporting figures'), distinguishing it from sibling tools focused on metrics, backfield data, or league info.

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 in the context of wanting current editorial insights from Muffed, but it does not explicitly state when to prefer this tool over alternatives or provide exclusions. There is no reference to other tools (e.g., for metrics use get_player_metrics), so 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?

The annotations already declare readOnlyHint, openWorldHint, idempotentHint, and destructiveHint, so the safety profile is covered. The description adds meaningful behavioral detail beyond those annotations: names are resolved before lookup beleh, and an unrecognised name returns closest matches rather than guessing, which is genuinely useful failure-mode information.

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 tight sentences with no filler. It front-loads the core return value and scope, adds concrete examples, and then covers the notable name-resolution behavior.

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, no output schema, and no descriptions on any parameter, the tool definition is incomplete. An agent cannot determine how to request a specific season, metric, or headline scope, nor what the returned structure will be beyond the mention of source rank.

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 only explains the entity parameter via examples and name resolution. The metric, season, scope, and entity_kind parameters are left undocumented, leaving the agent without enough information to correctly set optional filters or interpret the enum choices.

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 that the tool returns every verified figure for a single NFL player or team and provides concrete examples like 'Bijan Robinson' and 'DEN'. It is clear about the resource and the singular-entity scope, but it does not explicitly differentiate itself from sibling query tools such as run_stat_query or list_metrics, so it stops short of 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 description clearly conveys that this tool is for looking up known verified figures for one named player or team, which gives an agent solid context for when to use it. It does not, however, mention alternatives or exclusions such as using compare_entities for comparisons or query_stat_leaders for broader stat filters.

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

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

Annotations already declare readOnly and idempotent. The description adds valuable context about the content returned (definition, seasons, ranking, licence, attribution) and warns that season coverage is often narrower than a decade. This goes beyond the structured 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 two sentences, front-loaded with the core purpose. The second sentence adds a concrete example and a practical caveat about season coverage. No wasted words.

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 lookup with no output schema, the description covers what the tool returns, accepted input formats, and a data limitation. This is complete enough for an agent to select and invoke the tool correctly.

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

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

The input schema only defines `metric` as a string with zero description. The description compensates by explaining it accepts a metric key or common name, with examples ('cpoe', 'rushing yards over expected'), giving clear guidance that the schema lacks.

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

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

The description clearly states the tool returns a metric's published definition, including its meaning, coverage, ranking, licence, and attribution. This distinct verb+resource purpose differentiates it from siblings like list_metrics or get_entity_metrics.

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 on what the tool does and how to specify the metric (key or common name), but does not explicitly mention when not to use it or name alternative tools. It implies usage for looking up definition details, which is sufficient for a simple lookup.

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, idempotentHint=true, and destructiveHint=false, so the safety profile is established. The description adds meaningful behavioral context by promising 'keys and coverage only, never figures,' which clarifies that this tool will not return underlying data values. No contradiction exists between the description and 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 compact and front-loads the core message, with the mode-switching instruction in the second sentence. The phrase 'What Muffed can answer on' is slightly awkward and adds less value than the rest, but overall there is no waste and every sentence contributes.

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 that there is no output schema, the description does the necessary work of stating what is returned: family counts, season coverage, or individual keys and coverage, and explicitly excludes figures. It could be more complete by explaining how season and entity_kind filter the results, but the essential call contract is understandable without opening the schema.

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

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

Schema description coverage is 0%, so the description must compensate, but it only explains search and detail:true. It does not clarify the semantics of limit, season, or entity_kind, and it never explains how these filters affect the summary versus individual-key modes. The parameter names are suggestive but the behavior is left largely undocumented.

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 lists metrics and contrasts two output modes: a default family summary versus individual metric keys via search/detail:true. It also narrows the contract with 'Returns keys and coverage only, never figures,' making the core purpose clear. It does not explicitly differentiate from sibling tools like get_metric_definition, but the purpose itself is unmistakable.

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: when you need to know what Muffed can answer, with a default summary mode and an opt-in individual-key mode. However, it gives no explicit guidance about when to choose this over sibling tools such as get_entity_metrics or get_metric_definition, nor any exclusions. Usage is inferable rather than stated.

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

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

Annotations already declare readOnlyHint, idempotentHint, and destructiveHint, covering the safety profile. The description adds behavioral details: it returns pre-sorted results and includes each source's own rank and the population it was ranked against. It also notes the metric must be 'verified' and the season is singular. These are useful, but the description does not disclose potential edge cases (e.g., empty results, default order, or how asc/desc sorting affects the ranking). Since annotations carry the core behavior, 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 two sentences, with the primary function and output details front-loaded in the first sentence and a crucial pointer to list_metrics in the second. There is zero fluff, and every phrase adds value. The structure is efficient and easy to parse for an agent.

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 6 parameters, no output schema, and 0% schema description coverage, the description leaves significant gaps. It explains the core purpose and the metric parameter's validation via list_metrics, but omits details on the remaining parameters (limit, order, position, entity_kind), their defaults, and how the output is structured beyond rank and population. An agent would struggle to call this tool correctly without additional inference or probing.

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 0%, meaning the description must explain parameters, but it only touches on metric indirectly ('Call list_metrics for the metric keys this accepts') and season ('one season'). It does not explain limit, order, position, entity_kind, or their valid values and defaults. The description fails to compensate for the lack of schema documentation, leaving the agent with little guidance on how to set these parameters correctly.

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

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

The description clearly states the tool returns 'Top entities on one verified metric for one season, pre-sorted, each with the source's own rank and the population it was ranked against.' This is a specific verb-resource pair (query stat leaders) with precise details about the output (rank and population). It also implicitly differentiates from list_metrics by instructing to call it for metric keys, avoiding ambiguity. The title 'Verified stat leaders' reinforces the purpose without being tautological.

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 some usage context by saying 'Call list_metrics for the metric keys this accepts,' which tells the agent to use list_metrics when needing valid metric keys. However, it does not explicitly state when to use this tool versus alternatives like run_stat_query, compare_entities, or get_entity_metrics. There are no exclusions or alternative routing beyond the single list_metrics pointer, so guidance is partial.

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?

Despite rich annotations (readOnlyHint, idempotentHint, destructiveHint), the description adds substantial behavioral context: responses are 'labelled as computed, not verified,' every response 'carries the executed method, the population size, the measure's definition and the data version,' unsupported figures return 'the reason and the nearest thing it does cover,' and the scoring default flips to half-PPR when unspecified. None of this is present in the annotations, and nothing contradicts 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 long (~300 words), but every sentence carries information and the most important guidance is front-loaded in the first sentence ('Call this for any question about...'). The length is justified by the tool's complexity and the 0% schema coverage; it is dense rather than padded. It loses a point only because a worked example could have conveyed some of the op semantics more economically than prose.

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

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

For a tool with 5 params, 0% schema coverage, no output schema, and 10 op variants, the description is remarkably complete: it covers response contents (substituting for the missing output schema), error behavior, data provenance, and the scoring default. The main gap is that the semantics of the individual op subtypes and their fields are only partially explained, and no example query is given — an agent assembling a count_weeks_where or rank_change payload gets no guidance beyond the const names.

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 carries the full burden — and it compensates well: it maps the four main parameters to conceptual roles ('a population (position, qualifying threshold), a window... one named measure, and one operation'), gives exact formats for measure.key (e.g., 'key_player_stats.rushing.yards'), and explains the scoring enum and default. However, the op schema has 10 discriminated variants and the description only names six of them, leaving delta_between_seasons, rank_change, longest_streak, and count_weeks_where (plus fields like k, direction, and qualify) undocumented.

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 verb and resource ('Computes an NFL figure from a structured query') and explicitly enumerates its scope: 'leaders, rankings, splits, career or team spans, or how a player or team compares to others.' It also differentiates from siblings directly — 'this tool is the only surface here that computes them' — and contrasts with the 'verified panel' (verify_claim) and pointers to get_entity_metrics / query_stat_leaders. An agent can tell this tool apart without opening the schema.

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

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

The opening line is an explicit when-to-call directive: 'Call this for any question about NFL statistics... including when you believe you know the answer.' It also gives a clear why-not-to-answer-from-memory rationale ('Figures from memory are unsourced and frequently wrong') and names concrete alternatives for unsupported keys ('refused with a pointer to get_entity_metrics and query_stat_leaders'). No inference is required.

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

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

Annotations already declare the tool as read-only, idempotent, and non-destructive. The description adds a privacy note ('Muffed stores nothing about who called it') which is useful context, but it does not describe return format or error behavior. With annotations covering the safety profile, this is consistent with a score of 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?

The description is two sentences: the first front-loads the main purpose and the second adds a meaningful privacy statement. No redundant or extraneous content is present.

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 a required (username) and optional (season) parameter, no output schema, and useful annotations. However, the description does not explain the optional season parameter, the return format, or potential error cases, leaving significant gaps for an agent to use the tool 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 does not explain any parameters. It indirectly references 'username' but completely omits the 'season' parameter, leaving the optional parameter undocumented. This fails to compensate for the lack of 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 clearly states the tool's purpose with a specific verb ('Lists') and resource ('NFL leagues a Sleeper username belongs to'). It also distinguishes itself from sibling league tools by indicating its role in picking a league id for other 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?

The description implies when to use the tool ('so a league id can be picked for the other league tools') and suggests a workflow order. However, it does not explicitly state when not to use it or mention any alternatives.

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, openWorldHint, idempotentHint, and non-destructive behavior, so the description need not repeat those. It adds value by specifying the exact data payload (manager-to-roster map, detected scoring format), and its 'downstream reads better' note implies a non-mutating, dependency-free operation. No contradictions with annotations.

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

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

Two sentences, zero redundant words. The first sentence front-loads the return payload; the second delivers a usage hint. No fluff.

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 getter with one obvious parameter and strong annotations, the description covers the return payload and provides usage context. It doesn't detail error scenarios or distinguish from sibling getters, but those are not essential here.

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 sole parameter league_id is not described in the description, and schema_description_coverage is 0%. However, the tool name and 'One league's...' make the parameter's role obvious. Still, the description does not explicitly document the ID format or that it is required, relying on the schema pattern.

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

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

The description enumerates the returned league attributes (name, season, size, current week, scoring format, manager-to-roster map), making it clear this retrieves a single league's configuration. It distinguishes from sister tools like sleeper_find_leagues by focusing on a specific league rather than searching, though no explicit comparison is made.

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 'Everything downstream reads better once this has been called' indicates this is a preliminary/setup call to be used before other league operations. It does not explicitly mention alternatives or exclusions, but the 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 declare read-only/idempotent behavior, and the description adds context that this provides verified figures and doesn't make projections, which is useful for setting expectations 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?

Two sentences, front-loaded with the core purpose, and no wasted words. The description is concise and reads well.

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?

It gives purpose and boundaries, but without an output schema or parameter explanations, it's incomplete for an agent to know exactly what to expect in return or how to construct inputs properly.

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 has no descriptions (0% coverage) and the description does not explain the meaning or format of league_id, team, or week. It only implies league context, leaving the agent to infer parameter semantics.

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

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

The description clearly states the tool provides both sides of a league matchup with verified figures and team records, and explicitly distinguishes itself from projection tools by stating what it does not do. This differentiates it from sibling story/insight 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?

It implies when to use (when you need verified matchup context) and explicitly states it does not project outcomes or recommend lineups, which serves as a when-not. However, it doesn't name alternative tools for 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 read-only, idempotent, and non-destructive behavior. The description adds valuable context by specifying that players not covered by Muffed are listed as 'uncovered' rather than omitted, clarifying the tool's completeness 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 brief and front-loaded with the core concept. However, it relies on the unexplained term 'Muffed' and the phrase 'published Muffed surfaces' is awkward, slightly compromising clarity for conciseness.

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 and no parameter explanation, the description does not fully cover what an agent needs to know. It lacks return format, parameter semantics, and clarity on the 'Muffed' concept, though the simple structure and annotations partially compensate.

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 the meaning or format of league_id or team. It only vaguely references 'one team's roster' without connecting to the required parameters, leaving the agent without sufficient information to construct valid 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 clearly states the tool maps a team's roster to verified figures and published Muffed surfaces, which is a specific resource and operation. It distinguishes itself from sibling tools like sleeper_get_league or sleeper_standings_story by focusing on roster-specific data, though the term 'Muffed' is unexplained.

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 for when to use this tool versus alternatives. The description implies input via league_id and team but does not state prerequisites, exclusions, or when other Sleeper tools might be more appropriate.

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 safety (readOnlyHint, idempotentHint, destructiveHint=false). The description adds valuable transparency by explaining that standings are computed from roster rows and that points against may not always be available ('where available'). This helps the agent understand data derivation and potential limitations, exceeding the annotation baseline.

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

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

The description is two sentences long, front-loaded with the core purpose, and immediately followed by a brief explanatory note about the derivation method. Every word earns its place; there is no redundancy or filler.

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

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

Given the tool's simplicity (one parameter, no output schema, strong annotations), the description is complete. It explains the computation method, the data fields returned, and a limitation ('where available'). With no output schema, it successfully summarizes the return content. This is sufficient for an agent to use the tool effectively.

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, so the description must compensate. However, it never mentions the required league_id parameter or its role. The parameter name is self-explanatory, but the description adds no meaning beyond the schema, leaving the agent without explicit guidance on what input to provide or expected formats.

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: computing league standings from roster settings, specifying the output (records, points for, points against). It also distinguishes itself from siblings by explaining that Sleeper has no standings endpoint, so these are derived from roster rows. This is a specific verb+resource with clear scope.

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

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

The description provides clear context for when to use the tool: whenever league standings are needed, because Sleeper does not provide a direct endpoint. It implies the tool is the appropriate choice for this purpose, though it does not explicitly reference alternative tools or exclusions. The context is clear and no misleading guidance is present.

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

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

Annotations already cover read-only, idempotent, and non-destructive behavior. The description adds useful behavioral context beyond that by explaining what each result category returns (actual value for wrong, real season coverage for unverifiable). This is helpful and consistent with the annotations.

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

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

Two sentences with no filler: the first states the operation, the second explains return categories and input constraint. Key information is front-loaded, and every sentence adds value.

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

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

The description explains the outcome categories well despite no output schema, and the schema covers optional season and entity_kind constraints. A small gap is the absence of an example or a fuller definition of Muffed's verified panel, but the tool is still callable correctly from the description plus 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?

With schema_description_coverage at 0%, the description needed to compensate by explaining the meaning of metric, entity, and value, but it only says 'structured fields only, not sentences'. The field names and enum are present in the schema, but the description does not clarify how to populate the required claim object or what counts as a valid metric/entity.

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 verb 'Checks' and the resource 'structured claims against Muffed's verified panel', and further specifies the three possible outcomes. It is clear, though it does not explicitly name sibling tools or contrast itself with run_stat_query/query_stat_leaders, so it stops 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 sentence 'Takes structured fields only, not sentences' gives a concrete usage boundary and tells an agent what input form is acceptable. It does not, however, point to an alternative tool for free-text claims or explain when a sibling would be preferred.

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