Server Quality Checklist

Tool Scores

• get_league_matchupsA
  4.1/5.0
  Behavior4/5

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

  Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false. The description adds meaningful domain context beyond these: it specifies that entries include commissioner-overridden points and that teams sharing matchup_id played one another. This clarifies the data's meaning without contradicting any annotation.

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

  Conciseness4/5

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

  Five sentences, each with a distinct purpose: what it returns, field contents, matchup_id semantics, input sourcing, and use cases. The primary purpose is front-loaded. Slightly longer than necessary but every sentence contributes value, so it earns a 4 rather than a 5.

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

  Completeness4/5

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

  For a read-only tool with two simple parameters and no output schema, the description covers return contents, input provenance, and intended use cases. It does not mention error handling or empty results, but that is a minor gap for a tool of this simplicity and with strong annotations.

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

  Parameters3/5

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

  Schema description coverage is 100%, and the schema already tells agents to use get_sport_state for the week and get_user_leagues for the league_id. The description repeats this guidance but adds no new semantic detail. Baseline 3 is appropriate given the high schema coverage.

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

  Purpose5/5

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

  The description opens with 'Return all team matchup entries for one league week' – a specific verb, resource, and scope. It enumerates the fields returned (roster_id, matchup_id, starters, all players, points, and commissioner-overridden points) and explains the semantics of matchup_id. This clearly distinguishes it from sibling tools like get_league_rosters and get_winners_bracket.

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

  Usage Guidelines4/5

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

  Provides explicit use cases ('Use for weekly recaps, live score summaries, and lineup analysis') and explains how to obtain the required inputs from get_user_leagues and get_sport_state. It does not name alternative tools or state when not to use it, but given no other sibling tool returns matchups, the guidance is clear and sufficient.

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

• get_league_traded_picksA
  4.1/5.0
  Behavior3/5

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

  Annotations already declare readOnlyHint=true, openWorldHint=true, idempotentHint=true, and destructiveHint=false, covering safety. The description adds the return field details (season, round, original roster, previous owner, current owner) and the league_id prerequisite, which is useful but does not describe any additional behavioral quirks like pagination or rate limits. Given the annotations, the description adequately supplements without needing extensive disclosure.

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

  Conciseness5/5

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

  The description is two sentences, with the primary purpose in the first sentence and supporting details (fields, use cases) in the second. It is front-loaded, efficient, and every sentence contributes value. No wasted words.

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

  Completeness5/5

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

  With no output schema, the description clearly lists the fields returned per item, explains how to obtain the required league_id, and provides use cases. The tool has a single parameter and is a read-only list operation; the description covers everything an agent needs to invoke it correctly and interpret the result.

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

  Parameters3/5

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

  The schema already fully documents the only parameter (league_id) with a description that matches the description text ('obtained from get_user_leagues'). The description reinforces but does not add new semantic meaning beyond what the schema provides. With 100% schema coverage, a score of 3 is appropriate.

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

  Purpose5/5

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

  The description clearly states the verb ('Return') and the resource ('all current and future draft picks traded in a league'), and specifies the scope (league-level) and the included fields. It is distinct from siblings like get_draft_traded_picks by focusing on league-wide trading history, making the purpose unambiguous.

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

  Usage Guidelines4/5

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

  The description provides explicit context on when to use the tool, including a prerequisite ('Obtain league_id from get_user_leagues') and a list of use cases (asset inventories, ownership, trade evaluation). It does not explicitly exclude alternatives, but the context is clear enough for an agent to select this tool over similar ones.

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

• get_trending_playersA
  4.1/5.0
  Behavior4/5

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

  Annotations already declare readOnlyHint, idempotentHint, and non-destructive behavior, so the safety profile is covered. The description adds valuable context by stating the return format (player_id and activity count) and the time-window based ranking. It does not 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.

  Conciseness4/5

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

  The description is concise and front-loaded with the core purpose in the first sentence. The second paragraph adds use-case context without fluff. Every sentence contributes value, though the second paragraph could be condensed slightly without loss.

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

  Completeness4/5

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

  With no output schema, the description appropriately states the return values (player_id and activity count). It also gives a pointer for ID translation, covering the typical follow-up. Sorting order and pagination are not mentioned but are implicitly handled by the limit parameter. Overall, sufficient for an agent to call correctly.

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

  Parameters3/5

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

  The input schema provides 100% coverage with descriptions for all four parameters, including defaults and constraints. The description does not add parameter-specific meaning beyond what the schema explains; it only loosely references the time window and adds/drops, which the schema already details.

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

  Purpose5/5

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

  The description states a specific action ('rank players trending') and a specific resource ('by adds or drops over a recent time window'). It clearly distinguishes from siblings by focusing on ranking activity, and it explicitly mentions returning player_id and activity count, making the tool's purpose unambiguous.

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

  Usage Guidelines4/5

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

  The description gives clear use cases (waiver-wire discovery, injury monitoring, etc.) and directs the agent to use get_players for ID-to-name translation. It lacks explicit contrasts with other tools like get_transactions, but the purpose is specific enough that an agent can infer when to use it.

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

• get_user_draftsA
  4.1/5.0
  Behavior4/5

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

  Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, covering the safety profile. The description adds value by specifying exactly what the response contains (draft IDs, league IDs, draft type, status, settings, order, timing, metadata), which goes beyond the annotations. No contradiction with annotations; the description aligns with the read-only, idempotent nature.

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

  Conciseness5/5

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

  Three sentences with zero fluff. The first sentence states the primary function, the second lists return contents, and the third gives dependency and usage context. It 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.

  Completeness4/5

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

  For a simple list tool with three parameters, all schema-documented, and no output schema, the description covers the essentials: what it returns, how to obtain required inputs, and when to use it. It does not mention pagination or potential limits, but given the tool's simplicity and the presence of rich annotations, nothing critical is missing.

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

  Parameters4/5

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

  Schema coverage is 100%, so all parameters are documented in the schema. The description adds contextual meaning beyond the schema: it explains that user_id comes from get_user and that season can be resolved via get_sport_state. This provides practical guidance on how to fill the parameters correctly, exceeding the baseline of 3.

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

  Purpose4/5

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

  The description states a specific verb ('List') and resource ('a user's Sleeper drafts') and clearly scopes it by sport and season. It also lists the returned fields, making the purpose unambiguous. However, it does not explicitly name sibling tools like get_league_drafts or get_draft to differentiate, though the 'user's drafts' phrasing inherently distinguishes it from league-scoped alternatives.

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

  Usage Guidelines4/5

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

  The description gives concrete usage guidance: how to obtain the required user_id via get_user, and how to handle an unknown season via get_sport_state. It also states the intended use case ('discover draft IDs for draft-board and pick analysis'). It does not explicitly mention when to prefer alternatives like get_league_drafts, but the dependency hints are actionable and sufficient for most agents.

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

• get_draft_picksA
  4.2/5.0
  Behavior4/5

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

  Annotations already cover readOnly, idempotent, and non-destructive. The description adds valuable behavioral context: it returns only 'completed picks' (a filtering behavior) and mentions a 'player metadata snapshot,' indicating the data is a point-in-time record. This goes beyond the annotations and helps the agent understand the semantics of the returned data.

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

  Conciseness5/5

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

  The description is compact, with the primary purpose front-loaded in the first sentence. It uses two short paragraphs: one for what it returns and one for usage and parameter source. There is no redundant phrasing or filler—every sentence adds information.

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

  Completeness4/5

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

  For a simple list tool with a single parameter, the description covers the input source, output content, and typical use cases. It does not mention ordering or pagination, but those are often not critical for such an endpoint. The absence of an output schema is compensated by listing the key fields, making the description sufficiently complete for an agent to invoke the tool correctly.

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

  Parameters3/5

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

  The input schema already fully describes draft_id with a clear description. The tool description adds a hint on where to obtain the draft_id (from get_league_drafts or get_user_drafts), which is useful but not essential beyond the schema. Since coverage is 100%, the description's extra hint provides marginal value, aligning with the baseline of 3.

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

  Purpose5/5

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

  The description opens with a specific verb and resource: 'Return all completed picks from a Sleeper draft.' It explicitly lists the fields returned, making the tool's scope unambiguous. It differentiates from siblings like get_draft (draft metadata) and get_draft_traded_picks (traded picks) by focusing on completed picks and referencing how to obtain the draft_id.

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

  Usage Guidelines4/5

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

  The description clearly states that draft_id should be obtained from get_league_drafts or get_user_drafts, and it lists concrete use cases ('draft recaps, team-by-team results, reaches, values, and board reconstruction'). While it does not explicitly say when not to use this tool or compare it with get_draft, the guidance is sufficient for an agent to decide when to call it.

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

• get_league_draftsA
  4.2/5.0
  Behavior4/5

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

  Annotations already declare readOnlyHint and idempotentHint, covering safety and side-effect concerns. The description adds useful behavioral details: drafts are returned newest first, and it lists the specific fields included (draft_id, type, status, settings, season, timing, draft-order metadata). It also discloses the possibility of multiple drafts per league. No contradiction with annotations.

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

  Conciseness5/5

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

  The description is four sentences with no redundancy. The purpose is front-loaded in the first sentence, and subsequent sentences add distinct value: ordering and fields, the multiple-drafts caveat, and usage guidance. Every sentence earns its place.

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

  Completeness4/5

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

  For a simple read-only list tool with one parameter and no output schema, the description covers return field highlights, ordering, and usage guidance. It could optionally mention pagination or response limits, but for a tool of this complexity it is adequately complete.

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

  Parameters3/5

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

  Schema description coverage is 100%, so the schema already fully documents the league_id parameter. The description reiterates its origin ('Obtain league_id from get_user_leagues') but adds no new semantic meaning beyond the schema. Per guidelines, baseline 3 applies when the schema covers parameters completely.

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

  Purpose5/5

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

  The description clearly specifies the action ('List every draft') and the resource ('associated with a Sleeper league'). It distinguishes itself from siblings like get_draft (single draft) and get_user_drafts (user-scoped) by focusing on league-scoped enumeration.

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

  Usage Guidelines4/5

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

  It provides explicit guidance on when to use this tool: to obtain the correct draft before requesting picks, and how to acquire the required league_id ('Obtain league_id from get_user_leagues'). It also notes that dynasty leagues may have multiple drafts, implying this is the way to enumerate them. It doesn't explicitly name alternatives but the context is sufficient.

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

• get_sport_stateA
  4.2/5.0
  Behavior3/5

  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 safety profile is fully covered. The description adds the specific list of returned fields for NFL, which is useful context beyond the annotations, but it does not disclose any additional behavioral traits (e.g., error behavior, rate limits). Since the annotations already cover the safety aspects, this is an adequate but not exceptional contribution.

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

  Conciseness5/5

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

  Two sentences with no filler: the first states the core purpose, the second details the NFL fields and provides usage guidance. The key information is front-loaded, and every sentence earns its place. This is a model of conciseness.

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

  Completeness4/5

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

  Given the simple schema (one parameter), rich annotations (read-only, idempotent), and no output schema, the description is nearly complete. It fully specifies the NFL return contents and gives usage context. The only small gap is that it does not describe what is returned for non-NFL sports (e.g., baseball or basketball), but the default 'nfl' and the explicit NFL field list make this a minor omission. Overall, an agent has everything needed to correctly call and interpret the tool for its primary use.

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

  Parameters3/5

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

  Schema description coverage is 100%—the single 'sport' parameter is fully documented in the schema with its default and description. The tool description does not add any new meaning or syntax for the parameter beyond what the schema already provides, so it does not compensate further. Baseline 3 is appropriate.

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

  Purpose5/5

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

  The description clearly states the action ('Return') and the specific resource ('Sleeper's current week and season state for a sport'), and lists the exact fields for NFL. It is unambiguous and distinct from sibling tools that fetch specific data like matchups or rosters, making it easy for an agent to identify this as the state-preamble tool.

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

  Usage Guidelines5/5

  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: 'Use this before week- or season-scoped calls when the current values are unknown', and even provides concrete examples (matchups, transactions, user leagues, drafts). This gives an agent clear contextual guidance and effectively differentiates it from the siblings that depend on this state information.

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

• get_transactionsA
  4.2/5.0
  Behavior4/5

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

  Annotations already declare readOnlyHint=true and destructiveHint=false, establishing the safety profile. The description adds value by detailing what the response contains: 'added and dropped player IDs, involved roster IDs, status, timestamps, FAAB bids or transfers, and traded draft picks.' This goes beyond the annotations without contradicting them.

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

  Conciseness5/5

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

  Two sentences with no filler. The first sentence states the primary purpose, and the second packs result fields and usage context efficiently. The description 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.

  Completeness4/5

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

  For a read-only, two-parameter tool with no output schema, the description covers purpose, result content, usage scenarios, and a prerequisite. It does not describe exact response structure or error handling, but given the annotations and the tool's simplicity, it is sufficiently complete for an agent to call it correctly.

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

  Parameters3/5

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

  Schema description coverage is 100%, with both league_id and round already explained in the input schema, including the note that round is an NFL week for football. The description reiterates the league_id source but adds no new parameter semantics; thus a baseline 3 is appropriate.

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

  Purpose5/5

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

  The description opens with 'Return a league's free-agent moves, waivers, and trades for a round,' which is a specific verb (return) and resource (transactions). It also lists the exact result fields, making the tool's function unambiguous and distinguishable from sibling tools like get_league_traded_picks, which focuses only on traded picks.

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

  Usage Guidelines4/5

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

  The description states 'Obtain league_id from get_user_leagues' as a prerequisite and gives concrete use cases: 'waiver reports, trade histories, FAAB analysis, and weekly transaction summaries.' This provides clear context for when to use the tool, though it does not explicitly mention alternatives or when NOT to use it, so it stops short of 5.

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

• get_draftA
  4.3/5.0
  Behavior4/5

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

  Annotations already declare readOnlyHint, idempotentHint, and destructiveHint false, covering safety. The description adds value by detailing the exact return contents (draft type, status, rounds, timer, slots, draft order, mapping, league ID, timing, metadata) and the intended workflow. No contradictions with annotations, and the description enriches behavioral understanding beyond the safety profile.

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

  Conciseness5/5

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

  Three sentences, zero filler. The purpose is front-loaded, followed by a concise list of returns, then usage guidance. Every sentence earns its place.

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

  Completeness5/5

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

  For a single-parameter read-only tool with no output schema, the description covers purpose, parameter acquisition, return contents, and usage context. It is complete for an agent to call correctly: it knows what to expect and why.

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

  Parameters3/5

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

  Schema covers 100% of the parameter, with its own description including provenance. The description repeats the sourcing guidance ('Obtain draft_id from get_league_drafts or get_user_drafts'), which is redundant with the schema. No additional semantics provided. Baseline 3 is appropriate.

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

  Purpose5/5

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

  The description clearly states it fetches settings and metadata for one Sleeper draft, distinguishing it from siblings like get_draft_picks (which fetch picks) and get_league_drafts (which list drafts). It also specifies the resource (draft) and the action (fetch), leaving no ambiguity.

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

  Usage Guidelines4/5

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

  The description provides clear guidance on when to use: 'Use before analyzing the board so pick positions can be assigned to users and rosters.' It also tells how to obtain the required draft_id from get_league_drafts or get_user_drafts. However, it does not explicitly state when not to use or name alternatives like get_draft_picks, though the context implies it. Minor gap.

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

• get_losers_bracketA
  4.3/5.0
  Behavior4/5

  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 safety profile is known. The description adds value beyond those by specifying what the returned payload contains (rounds, participants, progression sources, and placement), which helps the agent set expectations for downstream use.

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

  Conciseness4/5

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

  The description is compact and well-organized: the primary purpose is front-loaded, followed by a returns summary and then use-case guidance. Every sentence contributes meaning, though the enumerated return items and use cases make it slightly denser than strictly necessary — still earned space.

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

  Completeness4/5

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

  For a single-parameter, read-only tool with no output schema and no nested objects, the description is nearly complete: it states what the tool does, what it returns, and when to use it. The only minor gap is the lack of explicit mention of the sibling get_winners_bracket as the complementary alternative, but the description covers the essentials.

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

  Parameters4/5

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

  Schema coverage is 100% since league_id is the only parameter and it is described as the 'Sleeper league_id.' The description reinforces this by instructing the agent to obtain league_id from get_user_leagues, adding provenance guidance that the schema lacks. With high coverage and the added hint, this exceeds the baseline of 3.

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

  Purpose5/5

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

  The description uses a specific verb ('Fetch'), names the resource precisely ('the league's consolation or losers playoff bracket'), and distinguishes it from the sibling get_winners_bracket by explicitly covering the losers/consolation side. It also enumerates the returned data (bracket rounds, roster participants, progression sources, winners, losers, placement), leaving no ambiguity about what the tool does.

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

  Usage Guidelines4/5

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

  The description states concrete use cases ('consolation recaps, toilet-bowl analysis, draft-order implications, and remaining postseason matchups') and tells the agent where to obtain the required parameter ('Obtain league_id from get_user_leagues'). It does not explicitly name get_winners_bracket as the not-to-use alternative, but the purpose statement makes the distinction implicit.

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

• get_winners_bracketA
  4.4/5.0
  Behavior4/5

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

  Annotations already declare readOnlyHint, openWorldHint, idempotentHint, and destructiveHint=false. The description adds context about the returned data and mentions 'supported playoff sizes', implying limitations. It does not contradict any annotation, and provides useful behavioral context beyond the structured metadata.

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

  Conciseness5/5

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

  Three concise sentences: the first states the core action, the second details the return data, and the third provides usage context and source for the parameter. No redundant phrasing; front-loaded and efficient.

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

  Completeness4/5

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

  Given no output schema, the description gives a clear enumeration of the returned data (rounds, matchups, IDs, progression, placement), sufficient for an agent to understand what to expect. Usage context and source of the parameter are also covered. Lacks explicit error handling, but that is minor for a read-only tool.

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

  Parameters3/5

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

  Schema coverage is 100% (league_id is already well-documented as 'Sleeper league_id obtained from get_user_leagues'). The description repeats this guidance in the usage line, but adds no new meaning beyond the schema. Per calibration, baseline 3 applies for high schema coverage.

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

  Purpose5/5

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

  The description clearly states the tool fetches the league's championship playoff bracket, with specific details on the returned data (rounds, matchups, IDs, progression, placement). It distinguishes itself from siblings like get_losers_bracket by focusing on the championship bracket.

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

  Usage Guidelines5/5

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

  Explicitly instructs when to use it (after or during playoffs) and for what purpose (explain paths, seeds, results, upcoming matchups). Also directs the agent to get league_id from get_user_leagues, providing a clear call flow.

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

• get_draft_traded_picksA
  4.5/5.0
  Behavior4/5

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

  Annotations already declare readOnlyHint, openWorldHint, idempotentHint, destructiveHint, so the safety profile is covered. The description adds the specific fields returned and the per-draft scoping, which is meaningful context beyond annotations. It does not disclose potential errors or edge cases, but given read-only and idempotent nature, that is acceptable.

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

  Conciseness5/5

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

  Four sentences, each earning its place: purpose, output fields, parameter sourcing, and complementary tool usage. No fluff, front-loaded with the primary function.

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

  Completeness5/5

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

  Despite no output schema, the description explicitly lists the returned fields, covering that gap. It addresses the single parameter, provides a composite workflow with siblings, and the annotations handle safety. Nothing critical is missing for correct invocation.

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

  Parameters4/5

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

  Schema covers 100% of the parameter description, but the description adds value by telling the agent where to obtain draft_id ('Obtain draft_id from get_league_drafts'), which is not in the schema. This goes beyond the baseline of 3 and aids correct invocation.

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

  Purpose5/5

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

  States a precise verb ('Return traded-pick ownership') and a specific scope ('for one Sleeper draft'), distinguishing it from the sibling get_league_traded_picks. Also lists the returned fields (season, round, original roster, previous owner, current owner), which clarifies what the tool does beyond just the name.

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

  Usage Guidelines4/5

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

  Provides clear context: instructs to obtain draft_id from get_league_drafts and to combine with get_draft and get_draft_picks to reconstruct a draft board. It implies the scope difference from get_league_traded_picks by saying 'specifically for one Sleeper draft,' but does not explicitly exclude alternative tools. Could be improved by naming the sibling it differentiates from.

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

• get_leagueA
  4.5/5.0
  Behavior4/5

  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 safety profile is covered. The description adds value by detailing the return payload (status, season, scoring settings, roster positions, draft ID, league name, avatar, roster count), giving the agent a concrete picture of what to expect. It does not state any side effects beyond what annotations imply, but given the annotations, this is sufficient.

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

  Conciseness5/5

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

  Three focused sentences: purpose, return fields, and usage guidance. No fluff, front-loaded with the core action, and each sentence earns its place. Ideal density for an agent to parse quickly.

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

  Completeness5/5

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

  For a simple read-only metadata tool with one parameter and no output schema, the description provides everything an agent needs: how to obtain the ID, what data it returns, and when to call it. The sibling set is large, but the description clearly scopes this tool to league configuration, leaving no ambiguity.

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

  Parameters3/5

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

  Schema description coverage is 100%; the parameter league_id is well-documented in the schema with source instructions. The description reinforces this by mentioning 'Obtain league_id from get_user_leagues,' but adds no new semantic beyond the schema. Baseline of 3 is appropriate since the schema already carries the full burden.

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

  Purpose5/5

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

  The description states a specific verb and resource: 'Fetch configuration and metadata for one Sleeper league.' It further enumerates the returned fields (status, season, scoring settings, etc.), making it unmistakably distinct from sibling tools like get_league_rosters or get_league_matchups, which have different scopes.

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

  Usage Guidelines5/5

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

  Explicitly instructs when to use the tool: 'Use this before interpreting scores, roster slots, league status, or chaining through previous seasons.' Also points to the correct source for the league_id ('Obtain league_id from get_user_leagues'), which routes the agent to the right prerequisite tool. This is clear and actionable.

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

• get_league_rostersA
  4.5/5.0
  Behavior4/5

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

  Annotations already declare readOnlyHint, openWorldHint, idempotentHint, and destructiveHint, covering safety. The description adds behavioral context by enumerating exactly what data is returned (roster_id, owner_id, players, starters, wins, losses, points, etc.) and scoping it to 'every roster' in the league. It does not conflict 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.

  Conciseness5/5

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

  Three sentences, no fluff. The first sentence states the action, the second lists included fields, and the third gives workflow guidance. Info is front-loaded and every sentence contributes to clarity.

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

  Completeness5/5

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

  For a simple read-only tool with one fully-documented parameter and no output schema, the description covers purpose, available fields, and how to obtain the required input. It also hints at the response structure ('every roster'). Nothing essential is missing for an agent to call it correctly.

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

  Parameters3/5

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

  Schema description coverage is 100%; the parameter 'league_id' is already described as 'Sleeper league_id obtained from get_user_leagues.' The description repeats this exact guidance without adding any new semantic details (e.g., format, validation rules, or variations). Baseline 3 is appropriate.

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

  Purpose5/5

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

  The description clearly states 'Return every roster and its season record in a Sleeper league' with a specific verb and resource. It lists the roster fields and distinguishes itself from siblings like get_league_users (which maps owners) and get_league_matchups (scoreboard). No ambiguity.

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

  Usage Guidelines5/5

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

  Provides explicit workflow guidance: 'Obtain league_id from get_user_leagues. Combine with get_league_users to map owners to teams and use for standings or roster analysis.' This tells when to use the tool, how to get its input, and how to combine it with a sibling, effectively routing the agent to the correct usage.

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

• get_league_usersA
  4.5/5.0
  Behavior4/5

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

  Annotations already declare readOnlyHint, openWorldHint, idempotentHint, and destructiveHint=false, so the safety profile is unambiguous. The description adds useful behavioral context about the returned data shape (all users, specific fields). It does not contradict annotations and provides additional value beyond the structured hints.

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

  Conciseness5/5

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

  The description is compact and well-structured: it opens with the core function, lists output fields, then gives usage guidance. Each sentence serves a purpose, and the critical information is front-loaded with no redundancy.

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

  Completeness5/5

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

  For a read-only tool with one parameter and no output schema, the description provides the essential output structure and workflow context: where to get the input and how to use the output with another tool. Nothing crucial is missing for correct invocation.

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

  Parameters3/5

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

  The single parameter league_id has a complete schema description (100% coverage) and the description repeats that it comes from get_user_leagues. While this reinforces the source, it adds no new semantics beyond what the schema already provides, so baseline 3 is appropriate.

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

  Purpose5/5

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

  The description clearly states the tool returns all users in a Sleeper league and lists the specific fields included (user_id, username, display name, avatar, commissioner status, team metadata). It also names how to obtain the league_id and references a sibling (get_league_rosters) for combination, distinguishing its purpose from other tools.

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

  Usage Guidelines5/5

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

  The description explicitly instructs to obtain league_id from get_user_leagues and tells when to combine results with get_league_rosters (for standings, team labels, manager summaries). This gives clear when-to-use and integration guidance without leaving 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.

• get_playersA
  4.5/5.0
  Behavior5/5

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

  Annotations already cover read-only, idempotent, and non-destructive hints. The description adds valuable behavioral context: the response size (several megabytes), the recommended caching strategy, and the daily call limit. This goes beyond annotations and provides essential operational details.

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

  Conciseness5/5

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

  Three sentences: purpose, content, and usage guidance. No wasted words, and the most important info (purpose and filtering advice) is front-loaded. Highly concise and well-structured.

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

  Completeness5/5

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

  For a simple tool with optional parameters and no output schema, the description covers everything an agent needs: what it returns, the size implications, caching strategy, and when to use filters. It is self-sufficient and leaves no critical gaps.

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

  Parameters3/5

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

  The schema already documents all three parameters with 100% coverage, including defaults and descriptions. The description reinforces the filter preference but does not add new semantic meaning beyond what the schema provides. Baseline of 3 is appropriate.

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

  Purpose5/5

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

  The description states a specific verb and resource: 'Fetch Sleeper's player-ID lookup map'. It clearly differentiates from siblings like get_user or get_trending_players by focusing on the lookup map. The purpose is unambiguous and distinct.

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

  Usage Guidelines4/5

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

  The description gives actionable guidance: 'Prefer position and active filters when a smaller lookup is enough' and advises caching and calling no more than once daily. While it doesn't explicitly contrast with sibling tools, the context of when to call and when to filter is clear, making it strong but not maximal.

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

• get_userA
  4.5/5.0
  Behavior4/5

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

  Annotations already cover safety (readOnlyHint=true, idempotentHint=true, destructiveHint=false), so the description builds on that by disclosing the return payload (user_id, username, display name, avatar) and adding the context that user_id is a stable identifier for downstream tools. This adds meaningful behavioral context beyond the annotations, though it does not mention error cases or pagination (not needed for a single-profile lookup).

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

  Conciseness5/5

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

  The description is two short paragraphs: the first states purpose, the second lists returns and gives usage guidance. Every sentence earns its place, and critical information (purpose and usage) is front-loaded. No fluff.

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

  Completeness5/5

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

  For a simple one-parameter lookup with no output schema, the description covers everything an agent needs: what it does, what it returns, how to use it, and how it fits into the toolchain. Annotations already handle safety, and the description fills the remaining gaps (return fields, stable ID intent). Complete for this tool's complexity.

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

  Parameters3/5

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

  Schema coverage is 100% — the parameter description already explains that username_or_user_id accepts a username or numeric ID and that user_id values are stable. The tool description reiterates this but does not add new meaning beyond what the schema provides. Baseline of 3 is appropriate since the schema is the primary source of parameter semantics.

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

  Purpose5/5

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

  The description states a specific verb ('Resolve') and resource ('Sleeper username or user ID to its public user profile'). It clearly names the output fields (user_id, username, display name, avatar identifier) and differentiates from siblings by explaining its role as the entry point before calling get_user_leagues or get_user_drafts. This is unambiguous and distinguishes it from other user/league tools.

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

  Usage Guidelines5/5

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

  Usage guidance is explicit: 'Use this first when only a username is known, then pass the returned user_id to get_user_leagues or get_user_drafts.' This tells the agent when to invoke this tool and what to do next, naming the alternatives directly. No inference needed.

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

• get_user_leaguesA
  4.5/5.0
  Behavior4/5

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

  Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, covering the safety profile. The description adds value by specifying the return contents (league_id, draft_id, settings, scoring, roster positions, status, previous-league linkage) and the prerequisite on user_id. It does not contradict annotations and offers context beyond them.

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

  Conciseness5/5

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

  The description is two sentences: the first states the core purpose, and the second lists expectations and usage context. It is front-loaded, free of fluff, and each sentence earns its place. No unnecessary repetition or filler.

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

  Completeness5/5

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

  For a list-and-return tool with no output schema, the description adequately explains what it returns, the prerequisite (get_user), and when to use it. It covers everything an agent needs to invoke it correctly. The lack of pagination or error details is minor given the tool's simplicity and the annotations covering the safety profile.

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

  Parameters3/5

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

  Schema description coverage is 100%, so each parameter is already documented (e.g., user_id says 'Numeric Sleeper user_id obtained from get_user, not a username'). The tool description does not add parameter-specific meaning beyond what the schema provides; it only reiterates usage in the body. With full schema coverage, the baseline of 3 is appropriate.

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

  Purpose5/5

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

  The description states a specific verb (List), resource (Sleeper leagues), and scope (belonging to a user for a sport and season). It also lists the returned metadata fields, making the tool's function unambiguous. It clearly distinguishes from siblings like get_league (which retrieves a single league) and get_user (which resolves a user).

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

  Usage Guidelines5/5

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

  Provides explicit usage guidance: 'Resolve a username with get_user first' establishes a prerequisite, and 'Use this to discover league IDs before standings, matchup, roster, transaction, or playoff analysis' states the intended workflow. This clearly positions the tool relative to its siblings and prevents misuse.

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