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

With no annotations provided, the description carries the full behavioral burden. It discloses name-vs-ID matching behavior, unresolved-name handling with candidate IDs, the default week behavior, and the full row structure. It does not discuss potential errors, rate limits, or whether the operation is read-only, but it is substantially transparent for a comparison tool.

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

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

The description is dense but every sentence earns its place: purpose, input semantics, unresolved behavior, default week, and output row structure. The most important scoping information is front-loaded, and no filler or repetition is present.

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

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

Given the tool's moderate complexity, two parameters, and an output schema, the description is fully adequate for an agent to select and invoke it correctly. It covers input formats, defaults, edge-case handling, and return layout; nothing essential 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?

Schema description coverage is 0%, so the description must fully compensate. It explains that players may be names or player_ids, that IDs are precise, that names are matched against ESPN's active-player index, and how unresolved names behave. It also explains the week parameter's default and how to use it for future weeks, adding rich meaning beyond the bare schema.

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

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

The description opens with a specific verb and resource: 'Compare 2-6 players side by side for "X or Y?" decisions.' This clearly differentiates the tool from single-player siblings like get_player and projection-focused tools, and the scope (2-6 players) is explicit.

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

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

The description gives clear context for when to use the tool: comparing players for roster decisions, including planning ahead by passing next week's number. It does not explicitly name alternatives or exclusion conditions, so it stops short of a full when/when-not guide, but the intended use case is unmistakable.

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

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

With no annotations, the description carries the full burden and does so thoroughly: it explains status values (FREEAGENT vs WAIVERS), ownership trend interpretation, the ambiguity of 0.0 week points, and explicitly notes next-week projections are unavailable. This goes well beyond a basic list description.

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

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

The description is long but every section earns its place: purpose and usage are front-loaded, args are compact, and the row-field explanation adds semantic nuance. 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?

For a three-optional-parameter list tool with no annotations, the description covers what the tool does, when to use it, all parameter semantics, and the meaning of every returned field. Nothing needed to invoke or interpret results 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 coverage is 0%, but the description fully documents all three parameters: position values including aliases and case-insensitivity, limit range and default, and sort options with their meanings. It compensates completely for the bare schema.

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

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

The description opens with 'List available players (free agents and waiver claims) in the user's league', a specific verb and resource that clearly distinguishes it from sibling tools like get_my_team or get_player. The scope ('available', 'free agents and waiver claims') makes its purpose unambiguous.

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

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

It gives explicit use cases: 'who should I pick up?', 'best available RB', or 'who's trending'. It does not explicitly state when to prefer a sibling tool, though the output row directs passing player_id to get_player, providing a mild routing hint.

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

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

With no annotations, the description carries the behavioral disclosure burden. It goes beyond a simple 'returns settings' by explaining important value semantics: scoring.rules maps stat names to points, unmapped ESPN ids appear as stat_<id>, FAAB budget is present when applicable, and trades.deadline is a UTC date. It does not discuss read-only status or data freshness, but the tool name and lack of parameters make those less critical.

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 opens with a compact summary of the returned categories, then uses each subsequent sentence to add meaningful detail about how to interpret the fields. It is dense but every sentence earns its place, with no filler or repetition of schema data.

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 settings retrieval tool, this is complete: it explains the major output sections, clarifies edge cases in scoring and trade data, and tells the agent when to call it. The presence of an output schema reduces the need to re-describe raw return shapes, and the description adds the interpretive context the schema likely cannot.

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

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

The tool has zero parameters, so there are no parameter meanings to clarify beyond the schema. The baseline for a zero-parameter tool is 4, and the description appropriately focuses on output shape and interpretation rather than inventing parameter guidance.

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

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

The description clearly identifies the resource (league settings) and enumerates its contents: scoring, roster construction, schedule/playoffs, waivers, and trades. It is immediately distinguishable from siblings like whoami, get_my_team, and get_free_agents because it is the only tool focused on league-wide rules.

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 an explicit when-to-use directive: 'Call this before start/sit, pickup, or trade advice.' It references get_player for stat-name conventions, but does not explicitly state when not to use this tool or name alternatives for other tasks, so it stops short of the full when/when-not/alternatives guidance.

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

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

With no annotations, the description fully discloses behavioral details: the lack of a per-player game-state field, the ambiguity of 0.0 points, the meaning of projected_source, possible null win_probability, and roster field nuances. It also explains how scoring works (non-BENCH/IR slots), which is critical for correct interpretation.

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 well-structured: a lead sentence with purpose and usage examples, followed by a clear breakdown of the top-level and nested fields. Every sentence adds value, covering semantics, edge cases, and data interpretation without redundancy. Despite length, it is efficient for the complexity it addresses.

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 comprehensive: it explains the tool's purpose, parameter semantics, output structure (including nested objects), edge cases, and data interpretation pitfalls. With an output schema present, the description still adds critical context about field meaning and ambiguity, making it complete for correct usage.

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

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

Schema coverage is 0% for the only parameter, but the description thoroughly explains the 'week' parameter: defaulting to current matchup period, passing earlier weeks for final results, and next week for previews with projections. This far exceeds the schema's minimal definition and fully compensates for the lack of schema documentation.

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

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

Description uses a specific verb ('Return') with a clear resource ('head-to-head matchup') and immediately provides concrete use-case examples ('am I winning?', 'who am I playing?'). It clearly distinguishes from sibling tools like get_my_team by focusing on the matchup context, and the detailed output structure further differentiates it.

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 the tool via the example questions and explains the week parameter semantics (default current, earlier for final, next for preview). It does not explicitly name alternatives or exclusion conditions, but the context makes the appropriate usage 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?

With no annotations provided, the description carries the full behavioral disclosure burden. It explains roster row fields (player_id, name, position, slot, pro_team, injury_status, projected) and gives important semantics: slot values BENCH/IR mean not starting, rows are ordered starters/bench/IR, projected is ESPN's projection for the current week and can be null, and record/points are season-to-date for the configured season. This goes beyond a simple return statement and gives an agent enough to interpret results correctly. It does not mention side effects, but as a 'get' tool, read-only nature is implied.

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 front-loaded with the main purpose, then proceeds to detailed roster field explanations. It is about 120 words, which is slightly longer than minimal, but every sentence adds meaningful detail (field semantics, ordering, null handling). 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?

Given the zero-parameter tool and the presence of an output schema, the description adds semantic richness beyond what schema field names would provide: it clarifies slot behavior, ordering, and the meaning of 'projected'. It also mentions the configured season, which ties into configuration context. For a simple getter, this is complete; it only lacks explicit details about authentication or error cases, which are likely not needed.

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

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

The tool has zero parameters, so the baseline is 4. The description adds no parameter documentation (there is nothing to document) but does add cross-tool linkage by noting player_id can be passed to get_player. This is useful context beyond the empty schema, though not technically parameter semantics.

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

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

The description states a specific action ('Return the user's fantasy team') and enumerates the included content (record, points, full roster). The word 'user's' distinguishes it from the sibling 'get_team' by indicating it is the current user's team. This is clear 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 clearly implies when to use this tool: when you need the current user's fantasy team, including roster and stats. It also provides a practical usage tip by telling the agent to pass player_id to get_player. It does not explicitly state when not to use it or name alternatives, but the context is clear enough that no exclusions are needed.

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

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

With no annotations, the description carries the full burden, and it does so thoroughly. It discloses the name lookup snapshot limitation, game log ordering, zero-valued stat omission, headshot_url verification caveat, season coverage, and rendering behavior. This is far beyond what annotations could provide.

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

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

The description is long but every sentence carries operational value: usage conditions, parameter semantics, full return structure, caveats, and rendering notes. It is front-loaded with the core purpose and usage before diving into field details.

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

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

Given the tool's complexity, zero annotations, and no output schema, the description is remarkably complete. It covers inputs, output fields, data provenance, limitations, and return format, leaving an agent with enough information to invoke the tool correctly and interpret results.

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

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

Schema coverage is 0%, and the description fully compensates by explaining both parameters: name semantics ('full name is best; a partial name works if it matches one active player') and player_id semantics ('from any other tool's rows -- prefer this when you have it'). It also clarifies the relationship between them with 'Pass exactly one of'.

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: 'Full profile for one player' with a detailed list of contents including status, league ownership, season numbers, outlook, and game log. It clearly distinguishes this from siblings like get_free_agents and get_my_team by focusing on a single player's profile.

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 ('tell me about X', 'how has X been doing', 'who has X in my league', 'is X worth a claim') and parameter selection guidance. It also states exclusions ('No news articles or opponent-matchup ratings'), but does not explicitly name sibling tools as alternatives, leaving some routing to inference.

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

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

With no annotations provided, the description carries the full behavioral burden and does so thoroughly: it discloses that projections are null until ESPN publishes them, that suggested_lineup fills league starting slots with eligibility rules, that IR/OUT/suspended players are never started, and that changes lists only the moves needed while continuing starters appear only in suggested_lineup. It also gives presentation guidance to show changes rather than the whole table.

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 front-loaded with the core purpose, then organized into usage guidance, return-field semantics, and presentation advice. Every sentence adds actionable information, and none merely restates the tool name or title.

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

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

The description covers what the tool returns, how the suggested lineup is computed, how changes should be presented, and how the week parameter behaves. Although an output schema exists, the description still explains the semantics of players, suggested_lineup, and changes in enough detail for an agent to select and invoke the tool correctly.

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

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

The input schema has one parameter, week, with 0% description coverage, so the description must fully compensate. It does: it explains that week defaults to current_week, defines current_week as the league's current NFL week, and instructs callers to pass current_week + 1 once games have kicked off to plan ahead.

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: it returns ESPN projections for the user's roster for one NFL week along with a suggested optimal lineup. It also anchors concrete use cases like 'set my lineup' and 'start X or Y?', making it easy to distinguish from sibling tools such as get_my_team or compare_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?

It gives explicit scenarios for when to use the tool ('set my lineup', 'start X or Y?', 'who's on bye?') and explains the week default plus how to plan ahead with week = current_week + 1. It does not explicitly 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?

With no annotations provided, the description carries the full behavioral burden and does so thoroughly. It explains ordering by ESPN playoff seed with fallback logic, field markers like is_me and clinched, and the caveat that records/points are not live until ESPN finalizes the week.

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

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

The description is compact and well-structured: a one-line overview, explicit use cases, then detailed behavioral notes. Every sentence adds value, and the most important information is front-loaded.

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

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

For a parameterless tool with an output schema, the description is complete. It covers the meaning of key fields, ordering semantics, update timing, and the appropriate sibling tool for live data, leaving no critical ambiguity for an agent.

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

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

The tool has zero parameters and the schema completely documents this, so there is no parameter semantics burden on the description. The description appropriately focuses on output content rather than inputs.

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

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

The description clearly defines the tool as providing league standings with a specific list of fields: rank, record, points for/against, streak, projected finish, and waiver order. It goes beyond the title by specifying exactly what data is returned and includes concrete natural-language use cases, distinguishing it from sibling tools like get_team or get_matchup.

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 with example queries like 'where do I stand' and 'who's in the playoff picture'. It also directs users to get_matchup for live scores, providing a clear exclusion and alternative.

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

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

With no annotations, the description carries the behavioral burden and details exactly what is returned: owner, record, points_for/against, and roster rows with specific fields. It also discloses flexible lookup behavior including case-insensitive names, abbreviations, and unique partial names.

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 front-loaded with a concise summary, followed by practical usage contextchers, then parameter semanticsholas, and finally return-shape details. Every sentence earns its place and no redundant filler is present.

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

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

For a single-parameter read-only tool with an output schema, the description covers what the tool does, when to use it, how to resolve the parameter, and the exact return fields. Nothing an agent needs to select and invoke it correctly is missing.

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

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

Schema coverage is 0%, so the description fully compensates by explaining the team parameter accepts an ID from get_standings or get_matchup, or a name/abbreviation, and clarifies case-insensitivity and unique partial-name matching. This adds substantial meaning beyond the bare anyOf 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 specific verb and resource: retrieving another league team's roster with record, points, and players with current-week projections. It clearly distinguishes itself from get_my_team by specifying 'another' and directly referencing get_my_team's shape.

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?

Provides explicit use cases such as trade targets, 'who has the most RBs', and 'what does Lucas's team look like'. It also tells where to get team IDs from (get_standings or get_matchup), but does not explicitly contrast when to use get_my_team 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?

No annotations are provided, so the description carries the full behavioral burden. It discloses sorting ('Newest first'), pending/processed semantics, filtering behavior for team including trades where the team is the other side, hidden lineup moves, and response field details. This is unusually transparent for a read-only log tool.

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

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

The description is dense but every sentence adds value: scope, use cases, ordering, status semantics, filtering, parameter meaning, and output fields. It is front-loaded with the most important identification sentence and flows logically into usage, behavior, args, and return shape.

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 transaction log tool with three optional parameters and an output schema, this description covers all the behavioral nuances an agent needs: pending status, processed timestamps, team-side trade filtering, lineup move suppression, and the meaning of each returned field. 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 0%, so the description must explain parameters. It does explain team (id or name/abbreviation, case-insensitive, partial name ok, omit for whole league), limit (1 to 100, default 25), and include_lineup_moves is described in the prose though not in the Args section. This is strong coverage, though including all params in the Args section would make it complete.

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

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

The description opens with a precise statement: 'League transaction log: adds, drops, waiver claims (including pending), and trades.' This clearly identifies the resource and scope. It also separates this tool from sibling tools by listing its specific transaction types and typical use cases.

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: 'who dropped X', 'did my waiver claim go through', recent trades, or waiver activity. It also explains when not to care about lineup moves and how to include them. It does not explicitly contrast with sibling tools like get_free_agents, but the scope is clear enough for 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?

No annotations are provided, so the description carries the full behavioral burden. It discloses side effects, return contract, config-file precedence, and ordering between writing values and the ESPN check, including the distinction between a cookie error and a validation error.

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

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

The description is compact, front-loaded with purpose, and every sentence adds necessary usage, return, or side-effect detail. It covers invocation, success/failure responses, storage precedence, and error semantics without 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 tool with no annotations and low schema parameter coverage, the description is unusually complete: it includes return values, error semantics, side effects, precedence, and conditional behavior. An agent can call this tool correctly and relay the right message to the user on failure.

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

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

Schema description coverage is 0%, so the description must compensate for missing parameter docs. It references 'ESPN credentials and league id' and the espn_s2/SWID cookies, but it does not formally map each schema parameter to its meaning, format, or default behavior. It adds useful context but not full per-parameter clarity.

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

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

The description opens with a specific action: 'Save ESPN credentials and league id, then verify them against ESPN.' This clearly names the resource, the mutation, and the verification behavior. It is easy to distinguish from sibling read tools like get_league_settings and whoami.

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 call it directly ('if the user pasted values into the chat') and identifies its normal invocation path via the setup card's Save & test button. It does not explicitly list alternatives to avoid, but the usage context is clear enough for an agent to route correctly.

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

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

With no annotations, the description carries the full transparency burden. It discloses that the tool saves and verifies settings via save_settings and instructs the agent to ask the user to fill the card rather than paste cookies. However, it doesn't explicitly state that the tool has no return value or that it triggers a UI interaction, though these are implied. Overall, it is fairly transparent but not exhaustive.

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 well-structured with a clear front-loaded purpose, followed by usage triggers, content details, and a fallback. It is somewhat lengthy but every sentence earns its place—no fluff. The structure is logical and easy to scan.

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

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

For a zero-parameter tool with no output schema, this description is highly complete. It covers when to use, what the tool does, what the agent should tell the user, and how to handle clients without card support. Nothing an agent needs to correctly invoke this tool is missing.

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

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

The tool has zero parameters and the schema coverage is 100% (empty schema). The description adds useful context about the cookie inputs (espn_s2 and SWID) that the user must provide, which enriches the agent's understanding even though there are no formal parameters. Baseline for zero-param is 4, and the description meets that adequately.

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 shows an in-chat setup card for connecting the user's ESPN league. It uses a specific verb ('Show') and a concrete resource, distinguishing it from sibling data-query tools like get_standings or get_player. It is immediately clear this is a configuration action.

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 defines when to call: when any tool reports the league is not configured, or when the user asks to set up, connect, update, or change their league/cookies. It also provides a clear alternative instruction for clients that cannot display cards, which prevents misuse.

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

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

With no annotations provided, the description fully carries the behavioral burden and does so thoroughly. It discloses the request cost, that no roster data is fetched, exactly what fields are returned, and the failure mode with an explanatory message when cookies expire or the league/team cannot be resolved. This is model behavior for a zero-annotation tool.

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

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

The description is three short, information-dense sentences with no filler. It front-loads the core purpose and 'Call this first' instruction, then supplies cost, return details, and failure behavior. 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?

For a zero-parameter preflight tool with an output schema present, the description is complete: it covers when to call it, what it returns, cost characteristics, failure modes, and error messaging. There is no significant information an agent needs that is missing. The output schema handles return-value detail, so the description's summary of return fields is sufficient.

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

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

The tool has zero parameters and the schema trivially covers this with an empty properties object. Per the baseline for zero-parameter tools, the description need not add parameter semantics. It adds value by describing what is returned rather than parameters, which is appropriate here.

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 a specific action: 'Verify ESPN credentials and league configuration', and the phrase 'Call this first' immediately positions it as a preflight/bootstrap check. It distinguishes itself from sibling data-fetching tools by noting it returns the league and team identifiers, not league settings, matchup, or free-agent data. This is enough for an agent to know what the tool is for and how it differs from siblings.

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

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

The description explicitly says 'Call this first' and supports that with cost and scope information: 'Cheap (one small request, no roster data)'. This gives concrete guidance on when to invoke it before more expensive or data-heavy sibling calls. It also indicates when not to expect detailed data, effectively distinguishing it from retrieval tools.

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