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

Annotations already declare readOnlyHint=true, openWorldHint=true, and destructiveHint=false, so the description does not need to repeat safety. It adds valuable behavioral context by listing the specific detection categories (unfilled slots, byes, OUT/DOUBTFUL, IR violations, bench optimization), which tells the agent what to expect from the audit. It does not describe the return format, but given no output schema, the list of checks partially compensates.

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 paragraph that front-loads the primary purpose and then enumerates specific checks, which is efficient and informative. It is not overly verbose for the complexity of the tool, and each sentence adds value. The final sentence gives usage triggers, which is useful. It could be slightly tighter, but it is well-structured.

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

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

Given the tool's complexity (multiple checks), no output schema, and annotations covering safety, the description is quite complete in explaining what the tool does and when to use it. It does not describe the return format, but the enumerated checks give the agent a strong expectation of the output content. For an audit tool, this is largely sufficient, though a note about output structure would make it fully complete.

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

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

Schema description coverage is 100%, so all four parameters are documented with descriptions (week, year, teamId, leagueId). The description adds no extra meaning beyond the schema — it merely restates that week is required because rosters and byes are week-specific, which is already in the schema's week parameter description. Baseline of 3 is appropriate since the schema carries the semantic load.

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 ('audit') applied to a specific resource ('a team's lineup for a week') against league requirements and player availability, and enumerates the exact checks performed (unfilled slots, byes, OUT/DOUBTFUL, IR issues, bench optimization). This clearly differentiates it from siblings like get_roster (which shows raw data) and get_health (which likely reports player health) — the tool is an analytical audit.

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 explicitly says to use it for questions like 'is my lineup set', 'am I missing anything', and 'IR or bench optimization questions', giving clear context. However, it does not name alternative tools or state when to use them instead (e.g., when you need raw roster data, use get_roster). The guidance is adequate but not exhaustive.

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 safety profile is covered. The description adds topical scope but does not disclose behavioral details such as response format, length, or whether the explanation is tailored to the topic parameter. This is acceptable for an informational tool but not exemplary.

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 no filler. The first sentence front-loads the resource and scope, while the second provides actionable usage guidance. 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?

This is a low-complexity tool: one optional parameter, a fully described enum, and read-only annotations. The description covers what the tool does, what topics it addresses, and when to invoke it, so an agent has everything needed to select and call it correctly.

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

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

Schema description coverage is 100%: the single optional topic parameter is fully documented with an enum and clear descriptions, including the default behavior. The description's topic list roughly mirrors the enum, so it adds no meaningful meaning beyond what the schema already provides.

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 and resource ('Get background on how fantasy football works') and enumerates concrete subtopics, so an agent knows exactly what this tool provides. It also distinguishes itself from the sibling data-retrieval tools by framing itself as a primer for jargon and unfamiliar formats.

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 when-to-use guidance: 'Call this when a question uses fantasy jargon you are not confident about, or before giving advice in an unfamiliar league format.' It does not name alternative tools or state when not to use it, but the context is clear enough to route an agent effectively.

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

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

Adds useful behavioral traits beyond the readOnlyHint and destructiveHint annotations by describing chronological order and pointing out pagination with size and offset. No contradiction 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 trimmed sentences front-load the core operation and intended use cases while adding the essential pagination hint with zero filler. Every sentence earns its place.

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

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

The description is complete enough for a read-only, no-required-parameter feed: it gives the content, ordering, use cases, and paging behavior, while the schema covers the rest. The only gap is not naming a similar sibling such as get_transactions.

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

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

Schema coverage is 100%, so the schema already documents all five optional parameters with defaults and paging semantics. The description mentions size/offset pagination but adds little meaning beyond the schema.

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

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

States a concrete operation on a clear resource: 'the league activity feed' and describes exactly what kind of log it returns ('who added/dropped/traded what' with chronological ordering. It is clear enough to identify the tool but does not explicitly differentiate from a sibling, and it names no 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?

Gives clear use contexts: 'Best tool for what did I miss this week' and newsletter or recap writing' tells an agent when to choose it. No when-not guidance or exclusions are present, so it does not reach the explicit alternatives level.

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

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

Annotations already declare readOnlyHint=true and destructiveHint=false, so the bar is lower. The description adds meaningful behavioral context: requesting a week beyond the league's current_week returns an error, and includeLineup toggles player-level detail. It doesn't describe the response structure, but for a read-only tool this is sufficient beyond the annotations.

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

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

Three sentences with no filler: what it returns, when to use it, and a critical failure condition. The core purpose is front-loaded, and every sentence earns its place.

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

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

With no output schema, the description compensates well by listing the key return fields and the includeLineup behavior, plus the error condition and prerequisite get_league. It doesn't specify the exact JSON structure or limits, but for a read-only box-score tool the agent has enough to call 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?

Schema description coverage is 100%, so the baseline is 3. The description goes beyond by explaining the week constraint ('later than the league current_week fails') and explicitly tying includeLineup to the full player-level breakdown. This adds practical meaning that the schema alone doesn't convey.

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

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

The description uses a specific verb 'Get' and resource 'box scores for a week', then enumerates the exact fields returned (actual/projected team scores, player points, projected points, slot, opponent, bye-week flag, injury status). It also distinguishes itself from siblings by claiming to be 'the richest tool here', so an agent can tell it apart from get_scoreboard or get_matchups 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?

Explicitly lists when to use it: 'start/sit review, bench blunders, over/under-performance versus projection and weekly recaps.' It also gives a clear exclusion and prerequisite: requesting a later week fails, so 'check get_league first.' This tells the agent exactly when to call and what to do instead.

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

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

The annotations already declare readOnlyHint=true and destructiveHint=false, so the safety profile is covered. The description adds that the tool returns 'every draft pick' with specified fields, which is consistent with the annotations. It doesn't add extra behavioral context like pagination or performance, but for a read-only query tool, the annotations plus the field list are sufficient.

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 core function front-loaded and the usage guidance appended. There is no redundant phrasing or filler. Every sentence earns its place, making it efficient and easy to parse.

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?

Despite lacking an output schema, the description lists all the fields returned (round, pick number, player, drafting team, auction bid amount, keeper status), giving the agent a clear expectation of the response. The tool is simple (two optional parameters, both documented in schema), and the description covers purpose and usage fully. Nothing essential 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 input schema has 100% description coverage for both parameters (year and leagueId), including guidance to omit them to use server defaults. The description does not add any additional parameter-level details, so it relies on the schema. Given the high schema coverage, a baseline of 3 is appropriate.

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

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

The description clearly states the tool retrieves draft picks with a specific set of fields (round, pick number, player, drafting team, auction bid amount, keeper status). It also names concrete use cases (draft grades, steal/bust analysis, trade context), which distinguishes it from sibling tools like get_roster or get_teams that serve different purposes.

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 explicit use cases ('Use for draft grades, steal/bust analysis, and to see how much a manager originally invested in a player being discussed in a trade'), giving the agent clear context for when to invoke this tool. It does not mention alternatives or when not to use it, but the use cases are specific enough to guide selection.

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, so the safety profile is covered. The description adds useful context about result contents (projected and recent points) but does not disclose anything beyond that; with annotations present, 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?

Three short sentences, each earning its place: first defines the result, second gives usage scenarios, third hints at parameters. Front-loaded with the core function and 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?

For a read-only list tool with optional parameters and no output schema, the description covers what the tool returns, why an agent would use it, and how to adjust the query. It is complete enough for selection and invocation, though it omits output shape details that the schema does not provide.

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

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

Schema description coverage is 100%, so all six parameters are already documented. The description adds a small amount of extra guidance ('raise size to see deeper options' and 'filter by position'), but it does not substantially compensate beyond the baseline.

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

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

States a specific verb and resource: 'List unrostered players available on the waiver wire or as free agents'. The scoping word 'unrostered' clearly distinguishes it from roster-related siblings like get_roster, and the inclusion of projected/recent points adds concrete behavioral specificity.

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

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

Explicitly tells the agent when to use this tool: for 'who should I pick up', streaming defense/kicker, and finding replacements for injured starters. It stops short of naming alternatives or when-not-to-use conditions, so it earns a 4 rather than a 5.

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

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

Annotations already establish that this is read-only and non-destructive, so the description does not need to repeat safety traits. It adds useful behavioral context: the tool probes external API reachability and helps disambiguate failure modes. It stops short of describing the exact return shape, but for a zero-parameter health check this is a minor gap.

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 wasted words. The primary purpose is front-loaded in the first sentence, and the second sentence provides actionable usage context.

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 zero-parameter health check, the description is nearly complete: it states what the tool does, when to use it, and what diagnostic distinction it supports. It does not describe the return format, but given the tool's simplicity and the read-only annotations, this is acceptable and only mildly incomplete.

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 is empty and schema description coverage is 100%, so there are no parameter semantics to document. The baseline of 4 applies because the description correctly implies the tool requires no inputs and focuses purely on a connectivity result.

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 ('Check') and a specific resource ('the ESPN fantasy football HTTP API this server talks to'), and it clarifies the exact intention: verifying reachability. It is clearly distinguished from sibling data-retrieval tools like get_league or get_teams.

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

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

It gives explicit usage guidance: 'Use this first when other tools fail, to tell "API is down" apart from "bad league config".' This tells the agent exactly when to invoke this tool and what diagnostic question it answers.

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 safety profile is covered. The description adds the useful behavior that current_week anchors week-scoped questions, but provides no further behavioral detail such as defaults or return shape 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, front-loaded with the core returned fields and the most important value (current_week) called out. 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?

This is a simple read-only tool with no output schema, and the description enumerates the key returned fields plus the intended usage context. The optional defaults are already documented in the schema, so nothing critical is missing.

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

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

Schema description coverage is 100%, so the two optional parameters are already fully documented in the schema. The description adds no additional parameter meaning, so the baseline score of 3 is appropriate.

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

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

The description clearly states the tool returns league id, season year, league name, team count, and current_week, which is unambiguous about the resource and purpose. It does not explicitly differentiate from siblings like get_league_profile, so it misses the highest bar for sibling distinction.

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 context: call this before any week-scoped question to know what 'this week' means. It does not name alternative tools or state when not to use it, so it falls just short of a 5.

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

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

Annotations already mark it read-only and non-destructive, and the description adds rich behavioral context: it produces interpreted, human-readable summaries rather than raw data, and provides strategic implications. The detailed output categories give the agent a clear picture of what the tool will return without an output schema.

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

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

Front-loaded with the strongest guidance ('THE tool to call before giving any fantasy advice') and packed with specific output details. The length is justified by the tool's importance and the absence of an output schema; there is no filler or repetition.

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

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

Even without an output schema, the description fully inventories what the agent will learn: scoring rules, lineup construction, roster sizes, waiver/FAAB mechanics, trade deadline, playoff structure, and strategic implications. Input defaults are covered by the schema, so nothing needed for correct invocation 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 input schema has 100% coverage with clear descriptions for both year and leagueId, including default behavior when omitted. The tool description adds no additional parameter semantics, so the baseline of 3 is appropriate.

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

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

States a specific, meaningful action: translating raw ESPN league settings into plain English. The description enumerates what is included (scoring format, lineup, FLEX/superflex, waivers, trade deadline, playoffs, implications), making it clearly distinct from siblings like get_league or get_settings.

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

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

Explicitly says to call this first before giving fantasy advice and warns against assuming a standard league. However, it does not name specific sibling tools as alternatives or say when to choose them instead, leaving a small amount of inference to the agent.

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, and destructiveHint, so the safe read-only nature is covered. The description adds useful context about future-week availability and matchup types, but does not disclose output shape, pagination, or any operational 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 two tight sentences with no filler. The core function is front-loaded, and the use-case guidance earns its place 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?

For a simple read-only tool with three optional, fully documented parameters and no output schema, the description conveys the essential semantics and use cases. It is slightly light on what the returned matchup objects actually contain beyond matchup_type, but nothing critical is missing for 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 100%, so all three parameters are already documented. The description does not add parameter-level meaning beyond the general idea of a weekly schedule, so baseline 3 is appropriate.

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

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

The description clearly states the tool retrieves the matchup schedule for a week, including matchup_type categories like regular season and brackets. It is clear enough to distinguish from scoring/standings tools, though it does not explicitly name a sibling 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 gives explicit use cases: previewing who plays whom, including future weeks, and working out playoff scenarios. It does not mention exclusions or when to prefer a sibling tool, 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 mark this as read-only and non-destructive, and the description does not contradict them. The description adds behavioral context beyond annotations by warning that name-based lookup can fail and prescribing a fallback workflow, plus noting the exact-name constraint.

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: the first names the action and return content, the second gives the exact-name requirement and fallback rule. Every sentence earns its place with 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?

For a simple read-only lookup with fully documented optional parameters and clear fallback guidance, the description is sufficient. Minor gaps are the lack of an output schema and no explicit statement about what happens if neither name nor playerId is provided.

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

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

Schema coverage is 100%, so the schema already documents all four parameters. The description reinforces the name format and suggests playerId as the fallback key, but it does not add substantial parameter semantics beyond what the schema provides.

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 ('Look up'), a single resource ('a single player'), and enumerates the data returned: position, pro team, ownership/start percentages, injury status, and scoring. This clearly distinguishes get_player_info from roster and free-agent sibling 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 gives an explicit usage rule ('Use the exact full name') and a concrete failure path: if lookup fails, use get_free_agents or get_roster and pass the returned player_id. This is direct guidance on when and how to switch to 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 mark the tool as readOnly and non-destructive, so the safety profile is covered. The description adds meaningful context beyond annotations by explaining that results are computed, blend scoring and strength of schedule, and offer a better quality estimate than raw record; it does not describe the return payload shape, but that is not safety-critical for this read-only lookup.

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 operation, then adds the formula distinction and the companion use case, and every sentence contributes 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 simple, fully optional-parameter read-only tool, the description is sufficiently complete: it states the operation, the interpretation of the result, and the companion tool. It omits a detailed return-shape description, but no output schema exists and the tool name plus first sentence convey the expected result well enough.

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

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

Schema description coverage is 100%, so week, year, and leagueId are all individually documented. The description adds only a small hint that ranking is 'through a given week,' while leaving the detailed optional/omit semantics to the schema; the schema already does the heavy lifting.

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 and resource ('Get computed power rankings') and clarifies that the concept blends scoring and opponent strength, distinguishing it from raw record standings. It even names the related sibling get_standings, so an agent can identify what this tool uniquely provides.

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

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

It gives a clear usage context: compute rankings through a week and pair with get_standings to detect teams overperforming their record. It does not explicitly state when not to use this tool or enumerate alternatives, but the stated companion relationship is enough to guide selection among the listed 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 declare readOnlyHint=true and destructiveHint=false, so the safe read behavior is covered. The description adds context about the returned data fields and required parameters, which is useful but does not disclose additional behavioral traits like auth needs, rate limits, or result envelope.

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 concise sentences with no fluff: the first states the core function and data contents, the second states use context and hard requirements. Everything 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?

There is no output schema, but the description enumerates the key categories of returned data: player names, positions, lineup slot, eligible slots, pro team, injury status, and ownership. It also clarifies the starting-point use case. Minor gaps like the exact response envelope are not essential for selecting or invoking 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 100%, so the schema already documents all four parameters. The description's statement that 'Both teamId and week are required' reinforces the schema but does not add meaning beyond it.

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 and resource: 'Get one team's roster for a specific week' and enumerates the returned fields. This clearly distinguishes the tool from siblings like get_teams (which returns teams) and get_free_agents (which returns available players).

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: 'starting point for start/sit, trade and roster-construction questions'. It does not explicitly name alternatives or exclusions, but the intended use is clear enough for an agent to select 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 declare readOnlyHint=true and destructiveHint=false, so the agent knows this is a safe read. The description adds one useful behavioral detail beyond annotations: future weeks return zero scores. It does not add much further context such as response format or data freshness, but the annotation safety profile lowers the burden.

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 core purpose is front-loaded, the future-week behavior is stated succinctly, and the sibling alternative is named in one clause. Every sentence earns its place.

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

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

This is a low-complexity read-only tool with no required parameters and a 100%-covered schema. Since there is no output schema, the description appropriately enumerates the returned content (team names, scores, playoff flag), covers the one edge case an agent might worry about (future weeks), and points to the correct sibling for per-player detail.

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

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

Schema description coverage is 100%, so all three parameters (week, year, leagueId) are already documented with types, ranges, and defaults. The description only refers to 'a week' generically and adds no parameter-level meaning beyond the schema, so the baseline of 3 applies.

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

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

The description states a specific verb and resource: get head-to-head scores for a week, and enumerates the returned fields (home/away team names, scores, playoff flag). It is clear about what the tool does, though it only explicitly differentiates from get_box_scores, not from the similarly named get_matchups sibling.

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 usage condition: it is safe for future weeks where scores will be zero, and it explicitly routes per-player detail to get_box_scores instead. It does not discuss other alternatives like get_matchups, but the provided guidance is concrete and actionable.

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-only nature is known. The description adds that player value depends on these rules, which is useful context but not a behavioral disclosure beyond what annotations provide. 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 two sentences, front-loaded with the list of settings, and the second sentence adds a clear usage directive. No redundant information, 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?

With simple optional parameters, high schema coverage, and read-only annotations, the description fully covers what an agent needs: it explains what data is returned and why it matters. No missing information that would prevent 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 schema description coverage is 100%, with both parameters (year and leagueId) documented in the schema. The tool description does not add any additional parameter semantics, so it stays at the baseline of 3.

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

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

The description states a specific verb 'Get' with a clear resource 'league settings' and enumerates the exact contents: scoring format, roster/lineup counts, playoff details, waiver/FAAB rules, keeper settings, and divisions. This distinguishes it from siblings like get_league or get_teams by specifying the 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 explicitly instructs when to use the tool: 'read them before ranking, trading or start/sit advice.' This provides clear context for when this tool is relevant, though it doesn't mention any alternative tools or exclusions, which prevents a 5.

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

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

Annotations already indicate a read-only, non-destructive, open-world operation. The description adds behavioral context by stating the results are ordered by league rank and which statistical columns are included, which helps the agent know what to expect in the response.

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 functional statement is front-loaded, and the second sentence gives a legitimate analytical use case without bloat.

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 list endpoint without an output schema, the description covers the key return fields and ordering, and the schema covers the optional parameters. It lacks a clear statement of when to prefer this over get_power_rankings, but that is more of a usage-guidance gap than an incompleteness for invoking the 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?

The input schema documents both optional parameters (year and leagueId) at 100% coverage. The description adds no additional parameter semantics, but none are needed because the schema fully explains them, so the baseline score of 3 is appropriate.

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

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

The description clearly identifies a specific verb ('Get'), resource ('standings'), and output fields with ordering ('ordered by league rank with wins, losses, ties and points_for'). However, it does not differentiate itself from the sibling 'get_power_rankings', so it stops short of the top score.

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 no explicit guidance on when to choose this tool over alternatives, such as 'get_power_rankings' or 'get_teams'. Usage is only implied by the action itself, with no exclusions or alternative routing.

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, covering the safety profile. The description does not contradict these and adds the output fields returned, which is useful. However, it does not disclose any potential side effects or dependencies beyond what annotations provide, and it does not address the openWorldHint implication (e.g., reliance on external data). The description is consistent but adds limited behavioral context 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?

The description is two sentences with zero fluff. The first sentence front-loads the action, resource, and specific output fields. The second sentence adds a practical use case. Every sentence earns its place, and it is well-structured for quick comprehension.

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

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

There is no output schema, but the description explicitly lists the fields returned (team_id, name, abbreviation, record, points for/against, division), which is sufficient for an agent to know what to expect. It also covers the intended use case. It does not mention sorting or pagination, but for a list of all teams this is likely not critical. The description is complete enough for correct invocation.

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

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

The schema covers 100% of parameter descriptions, including explanations of optional year and leagueId with default behavior. The description adds no additional semantic meaning for parameters, so it correctly relies on the schema. Baseline 3 is appropriate since the schema carries the full burden and the description does not enhance it.

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 'List' and the resource 'every fantasy team' with specific fields (team_id, name, abbreviation, record, points for/against, division). It also notes a specific use case (translating team names to teamId), which helps distinguish it from sibling tools like get_standings that might also return records. The purpose is unambiguous and specific.

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 explicitly states when to use this tool: to translate a user-typed team name into a numeric teamId required by other tools. This gives clear contextual guidance. It does not explicitly mention when not to use it, but the use case is specific enough that an agent can infer the appropriate scenario. Slight deduction for not naming alternatives directly.

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, covering the safety profile. The description adds useful context about the content (FAAB amounts, claim outcomes) but does not disclose behavioral traits such as result ordering, pagination, or coverage of default periods beyond the schema defaults.

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 action and scope, followed by a practical use case. Every sentence earns its place and there is no wasted wording.

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 partial return-value disclosure (FAAB amounts, success/failure) and the annotations cover read-only safety. It is complete enough for a straightforward filtered-list tool, though it leaves minor gaps around output ordering and manager identifiers.

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?

Input schema coverage is 100%, so the schema fully documents all four parameters. The description adds no new parameter-level meaning beyond broadly referencing scoring periods and transaction types, so the baseline of 3 is appropriate.

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

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

The description uses a specific verb ('Get') and resource ('roster transactions') with concrete subtypes (waiver claims, free-agent adds, drops, trades) and distinctive output details (FAAB bid amounts, claim success/failure). This clearly separates it from siblings like get_activity and get_teams without requiring schema inspection.

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 explicitly states when to reach for this tool: 'Use this to see what the waiver market paid for a player and which managers are chasing the same needs.' It provides a clear use context, though it does not name sibling alternatives or give exclusion criteria.

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, covering the safety profile. The description adds that the tool returns a recommended sequence, but it does not specify the output format or clarify whether the sequence is just tool names without executing them. This is modest added context 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 with no waste. The first sentence front-loads the tool's function and examples; the second gives the exact trigger condition for using it.

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, the description covers the essential points: what it does and when to call it. It lists broad categories but stops short of describing the exact format of the returned sequence, which would have been helpful given there is no output schema. Overall, it is complete enough for an agent to decide to 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 tool takes zero parameters, so the baseline is 4. The description adds value by enumerating the question types that affect the recommended sequence, even though it doesn't need to document any parameter syntax.

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

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

The description states a specific verb ('Get') and resource ('recommended tool sequence') and grounds it with six concrete fantasy question categories. It clearly distinguishes itself from sibling data-fetching tools by focusing on tool sequencing rather than returning 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?

The description explicitly says to call this tool when unsure which tools to combine, giving a clear usage context. It doesn't provide exclusions or explicitly name alternatives, but the sibling tools are naturally implied alternatives to use directly when the agent already knows the right tool.

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