EndzoneAPI

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

Annotations already mark this as read-only. The description adds meaningful context beyond that: a credit cost ('Costs 5 credits'), source-specific availability years (2016+ vs 2018+), and the kinds of data each source provides. This helps the agent anticipate side effects and data scope without contradicting annotations.

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

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

Four sentences, each earning its place: use case, NGS metrics, PFR metrics, and usage/cost. The purpose is front-loaded, and the metric lists are compact and informative without fluff.

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

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

With an output schema present, return-value details are already covered. The description supplies the missing operational context: credit cost, source-year ranges, filter workflow, and metric examples. Nothing an agent needs to invoke this correctly is left out.

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

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

Schema coverage is 100%, so baseline is 3. The description adds value by associating metric families with specific source enum values (e.g., time to throw for NGS, pressures for PFR), which clarifies what each source actually returns. It also reinforces filter dimensions (season, week, player, team) already present in the schema.

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

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

The description uses a specific verb ('tracking and charting') and resource ('metrics the box score does not carry'), then enumerates concrete metric examples for each source (NGS and PFR). This clearly distinguishes it from box-score stat tools like get_player_stats and get_team_stats.

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 states an explicit use case ('metrics the box score does not carry') and gives a usage pattern ('Pick a source, then filter by season, week, player or team'). However, it does not name a specific alternative tool for box-score stats, so the exclusion is implied rather than explicit.

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

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

Annotations already mark the operation read-only; the description adds useful behavioral context: it defaults to the latest week and costs 2 credits. It does not contradict the annotations and no destructive or auth-related disclosure is needed for a read-only 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?

A single sentence packs purpose, output contents, default behavior, and cost with no filler. It is front-loaded and every part earns its place.

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

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

With a full output schema, 100% parameter documentation, and read-only annotations, the description covers operational essentials such as defaults and cost. Nothing critical is missing for an agent to invoke it correctly.

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

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

The input schema has 100% description coverage for all four parameters, so the description is not required to add much. It reinforces the week default but does not materially go beyond what the schema already states.

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 indicates the tool provides a team's depth chart for a week and names key returned fields: formation, position, depth rank, player. It is distinct from all sibling tools, though it uses 'Use for' rather than an explicit retrieval verb and does not name an alternative.

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

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

It states the purpose as depth-chart retrieval and clarifies that week defaults to the latest available and that the call costs 2 credits. This gives clear context for when to use it, but it does not mention exclusions or alternative tools.

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

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

Annotations already declare readOnlyHint=true, and the description adds meaningful behavioral context: the call costs 10 credits and requires a game_id obtained from get_games or get_schedule. 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.

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

Three sentences with no wasted words. The primary use case is front-loaded, the content scope is listed compactly, and the prerequisite and cost are stated at the end. 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 single-parameter tool with an output schema and read-only annotations, the description is complete. It tells the agent what data it will receive, where to get the required ID, and that it costs credits. Nothing essential for calling it correctly appears 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 100% with a concrete example, so the baseline is 3. The description adds value by explaining that game_id should come from get_games or get_schedule, giving the agent provenance for the parameter beyond the schema's type and example.

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

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

The description clearly states the tool returns comprehensive data for one game: teams, box-score stats, odds, weather, surface, and officials. It distinguishes itself from siblings by emphasizing 'everything about one game' and enumerating the specific data categories, though it does not explicitly name alternative tools.

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

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

It gives a clear when-to-use condition: when you need the full detail set for a single game. It also names the prerequisite source for game_id ('from get_games or get_schedule'), which is actionable. It does not explicitly say when not to use it or name alternatives, but the context is strong.

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

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

Annotations already declare readOnlyHint=true, and the description does not contradict this. It adds useful behavioral context beyond annotations: the tool covers both past and future games, it costs 5 credits, and it returns consensus betting lines in addition to basic game data. No destructive or state-changing behavior 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?

Three sentences with no filler. The use case and filters are front-loaded, followed by the return summary, then the sibling alternative and cost. Every sentence serves a purpose, and the structure lets an agent quickly determine applicability.

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 an 8-parameter queried-list tool with an output schema and read-only annotations, the description covers the essential context: what kinds of games are included, what data is returned, when to prefer a sibling tool, and the credit cost. Nothing required for correct invocation or selection is missing.

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

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

Schema description coverage is 100% for all 8 parameters, so the schema already documents parameter types and constraints. The description adds value by grouping these into a filter list and naming 'date range' (mapping to date_from/date_to), but it does not add semantics beyond what the schema already provides. Baseline 3 applies.

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

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

The description uses a specific verb and resource: 'querying past or future games with filters'. It enumerates the key filter dimensions (season, week, team, date range, game type, status) and names a sibling tool it is not (get_schedule), making it easy for an agent to distinguish this from other game-related tools.

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

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

The description explicitly states when to use it ('Use when querying past or future games') and gives an explicit alternative with a condition ('For upcoming-only games prefer get_schedule (2 cr)'). It also includes a cost comparison ('Costs 5 credits'), which helps with tool selection under budget constraints.

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

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

Annotations already readOnlyHint=true and openWorldHint=false. The description adds the cost (10 credits) and describes the return content (recent meetings, win/loss record, average margin), providing behavioral context beyond the annotations. No contradiction.

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

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

Three concise sentences: purpose and outputs, filtering option, and cost. All information is front-loaded, with no wasted words or redundant details.

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

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

For a simple read-only comparison tool with 4 parameters and an output schema, the description covers the core purpose, filtering options, and cost. Any missing details (e.g., error conditions, exact return format) are minor given the schema and annotations.

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

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

Schema description coverage is 100%, so all parameters have descriptions (team1, team2, limit, season). The description mentions season filtering but does not add meaning beyond the schema's 'Season year. Omit for all-time.' It provides no extra detail on team codes or limit syntax, so it stays at the baseline of 3.

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

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

The description clearly states the tool's purpose: comparing two teams' history and specifies the outputs (recent meetings with scores, win/loss record, average margin). This differentiates it from sibling tools like get_team_stats (single team) even without naming them explicitly, but it lacks an explicit sibling disambiguation.

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

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

The opening phrase 'Use to compare two teams' history' provides a clear when-to-use. It also mentions filtering by season or all-time, which guides parameter selection. However, it does not mention when not to use this tool or point to alternative sibling tools, so it lacks exclusions.

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

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

Beyond the readOnlyHint annotation, the description adds valuable behavioral details: the tool costs 2 credits and defaults to the latest reported week of the current season. This gives agents important context for invocation, though it doesn't describe error handling or edge cases.

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

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

The description is a single, dense sentence with no wasted words. It front-loads the purpose and packs in the key details (statuses, participation, grouping, defaults, cost) efficiently.

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

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

Given that an output schema exists, the description doesn't need to explain return values. For a 4-parameter optional tool with full schema coverage, the description covers purpose, usage, defaults, and cost, providing all necessary context for correct invocation.

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

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

The schema already describes each parameter (100% coverage), but the description adds semantics by clarifying that the report is organized by team and week, and by reinforcing the meaning of the status filter (Out, Doubtful, Questionable). It also mentions default behavior for week and season, which goes beyond the schema's generic defaults.

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

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

The description clearly states the tool's purpose: 'official injury report' with specific fields (game status, practice participation) and by team and week. It distinguishes from siblings since it's the only injury-related tool among the list.

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 opens with 'Use for the official injury report', giving a clear when-to-use directive. It doesn't explicitly mention alternatives or when not to use, but the sibling list makes it the obvious choice for injury data, so the guidance is adequate.

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

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

Annotations already mark the tool as read-only and not open-world, so the safety profile is covered. The description adds useful behavioral context: the data is hourly snapshots, grouped by bookmaker, and the tool is the most expensive at 25 cr. This goes beyond what annotations 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?

Two sentences with no wasted words. The core purpose is front-loaded, followed by cost and a clear alternative. Every sentence earns its place.

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

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

With an output schema present, read-only annotations, only one required parameter, and a clear description of the data granularity and cost, the definition is complete for an agent to invoke correctly. The alternative tool is also named for simpler use cases.

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

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

Schema description coverage is 100%, so the schema already documents game_id and bookmaker. The description adds that snapshots are grouped by bookmaker, which clarifies the bookmaker parameter's role, but it does not add significant new parameter-level detail beyond the schema.

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

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

The description states a specific verb and resource: seeing how a game's lines moved via the full time series of hourly snapshots grouped by bookmaker. It clearly distinguishes itself from get_odds, so an agent can tell which tool to choose.

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 when to use this tool versus the cheaper alternative get_odds, naming the exact condition ('if you only need opening, closing, or current lines'). It also provides cost context, making the trade-off obvious.

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

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

Annotations already declare readOnlyHint=true, and the description adds meaningful behavioral context beyond that: the 10-credit cost and the availability boundaries (consensus data since 1999, per-bookmaker data only for the 2026 season). No contradictions with annotations are present.

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

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

A single dense sentence front-loads the purpose and packs in the data scope, bookmaker list, time ranges, and cost with no filler. Every clause contributes actionable information.

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, the output schema, and read-only annotations, the description plus schema fully cover what an agent needs: purpose, supported data, date coverage, cost, optional filters, and default behavior. Nothing essential is missing.

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

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

Schema description coverage is 100%, so the schema already documents game_id, bookmaker, and snapshot_type. The description restates bookmaker names and snapshot categories but adds little parameter-level meaning beyond what the schema provides.

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

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

The description states the exact purpose ('Use for a game's betting lines') and specifies the odds types, bookmakers, and date coverage, making the tool's scope clear. It does not explicitly differentiate from the sibling get_line_movement, so it falls short of a full 5.

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

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

The opening phrase 'Use for a game's betting lines' directly tells an agent when to call this tool, and the description clarifies the data scope. It provides no exclusions or alternative-tool routing, but the context is clear enough to guide selection.

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

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

With readOnlyHint already true, the description adds meaningful behavioral context: 'Counting stats are summed, rate stats averaged' clarifies how stat values are aggregated. It also discloses a non-obvious cost: 'Costs 5 credits.' 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.

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

The description is three sentences, front-loads the purpose, and packs in useful detail without fluff. Every sentence contributes: purpose, stat examples, aggregation behavior, filters, and cost.

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 ranking tool with an output schema and full parameter documentation, the description covers purpose, stat domain, aggregation semantics, filters, and cost. An agent has enough information to select and call the tool correctly without additional clarification.

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

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

Schema coverage is 100%, so parameters are already documented. The description adds value by giving real stat-name examples and explaining aggregation behavior for counting vs rate stats, which helps an agent understand what values the 'stat' parameter can take.

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: 'rank players on any weekly stat over a season,' and opens with 'Use to rank players,' which immediately communicates the tool's function. It lists numerous example stats, so an agent can distinguish this leaderboard tool from siblings like get_player_stats or get_advanced_stats.

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

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

The description provides clear context: use it when you need player rankings for weekly stats over a season, with optional filters. It does not explicitly name alternatives or state when not to use the tool, but the 'rank players' framing gives sufficient usage 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?

Annotations already declare readOnlyHint=true, covering the safety profile. The description adds genuinely useful behavioral traits beyond that: 'Defaults to the player's latest season' discloses default-value behavior, and 'Costs 5 credits' is a resource-consumption disclosure that helps agents budget calls. 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.

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

The description is compact and front-loads the key usage signal ('Use for one player'), with each of the three sentences earning its place (scope, default behavior, cost). However, the first sentence is a long run-on enumeration of content categories that is somewhat hard 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?

Given an output schema covers return values, 100% schema parameter coverage, and read-only annotations, the description is largely complete: it conveys scope, default behavior, and cost. Nothing critical an agent needs to call it correctly is missing, though it could note that the player_id comes from search_players — but that already lives in the schema's parameter description.

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

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

Schema description coverage is 100%, so all three parameters are already documented in the schema (player_id from search_players, season year with default, season_type REG/POST). The description's 'Defaults to the player's latest season' largely duplicates the schema's season parameter note, adding no new parameter-level semantics. Baseline 3 is appropriate.

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

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

The description uses a specific directive ('Use for one player') and exhaustively enumerates the returned content: bio, draft, physicals, headshot, id crosswalk, summed season totals across all stat categories, weekly stat lines, and games played. This clearly differentiates it from siblings like get_advanced_stats (different metric set) and get_player_leaders (aggregate across players, not one player).

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

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

The opening 'Use for one player' establishes clear context for when to invoke this tool, and the content list further scopes it. However, it never explicitly names alternatives or states when not to use it (e.g., no routing to get_advanced_stats for advanced metrics), so it falls short of full exclusion 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?

Annotations already declare readOnlyHint=true, and the description adds useful behavioral details beyond that: it returns a per-query EPA/success summary, requires pagination with offset, and costs 10 credits. It also notes the 2022+ limitation for FTN charting, which is valuable context.

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 yet information-dense, front-loading the tool's core purpose before listing filters and behavior. Every sentence earns its place, and it avoids redundant restatement of schema details.

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

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

For a tool with 27 parameters and an output schema, the description covers the essential context: what the tool returns, how to filter, when charting data is available, how to paginate, and the credit cost. The output schema handles return-value details, so the description is sufficiently complete.

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

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

Schema description coverage is 100%, so the baseline is 3, but the description adds meaning by grouping parameters into logical categories (game vs. season filters, charting flags, pagination) and by clarifying the win-probability band concept and player filters. This is more than the schema alone provides.

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

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

The description clearly states the tool is for play-by-play data with nflfastR metrics (EPA, WPA, CPOE, etc.), which is a specific verb+resource and distinct from siblings like get_advanced_stats or get_player_stats. It also enumerates available filters and features, 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.

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

The description gives clear context on when to use the tool: for play-by-play with advanced metrics, filtering by game or season/week/team/player. It does not explicitly name alternatives or state exclusions, but the 'Use for' phrasing effectively routes the agent to this tool for this purpose.

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

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

Annotations already declare readOnlyHint=true and openWorldHint=false, covering safety and scope. The description adds useful behavioral details: it includes consensus lines where posted and costs 2 credits. These go beyond the annotations but are modest. 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.

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

The description is a single sentence that is concise and front-loaded with the primary purpose. It efficiently conveys the key usage modes, cost, and additional content. No wasted words, though it could be slightly more structured with separate clauses.

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 read-only nature, the presence of an output schema, and complete parameter descriptions, the description is sufficiently complete. It covers cost, usage modes, and inclusions. The only minor gap is the lack of explicit mention of pagination or result ordering, but these are typically handled by the output schema.

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

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

Schema coverage is 100% and each parameter already has a clear description. The tool description adds little beyond the schema, mentioning the default days value (also in schema) and clarifying that days applies to unplayed games while week returns all games. This is adequate but not extra value beyond the schema.

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

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

The description clearly states the tool's purpose: to see upcoming unplayed games or a specific week's schedule. It uses a specific verb ('see') and resource ('schedule'). However, it does not explicitly differentiate from sibling tools like get_games, which might also list games, so it loses one point.

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

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

The description provides clear usage context by explaining the two modes (next N days or a specific week) and the default of 7 days. However, it does not mention when to use this tool over alternatives, nor does it state any exclusions. The guidance is implicit rather than explicit.

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

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

Annotations already signal read-only, and the description adds an operational cost ('Costs 5 credits') that an agent needs before calling. No mention of row limits or response behavior, but with readOnlyHint true and an output schema present the bar is lower.

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

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

Two sentences, front-loaded with the core purpose and scopes, with the cost detail at the end. No filler.

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

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

Given the output schema, readOnly annotation, and high schema coverage, the description supplies the selection-relevant mode context and cost. It could be more explicit about required parameter combinations since all six params are optional, but it is adequate for a query tool of this complexity.

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

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

Schema has 100% coverage, so baseline is 3. The description adds mode-level semantics by mapping 'one game, one player (PFR id), or a team's season' to the available lookup styles, which is useful beyond terse property descriptions. It stops short of stating which parameter combinations are required.

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 names the resource (snaps and snap shares by offensive/defensive/special-teams) and the supported scopes (game, player, team season), making the tool's role clear. It does not explicitly distinguish it from sibling stats tools such as get_player_stats or get_team_stats, so it lacks the differentiator needed for a 5.

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

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

Begins with 'Use for playing time', giving a direct usage context, and spells out the three query modes. It does not mention alternatives or exclusions, so it falls short of a 5.

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

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

Annotations already mark this as read-only, so the description adds valuable behavioral detail beyond that: real NFL tiebreaking procedure, reporting which step decided each rank, computation from final scores, defaulting to current season, and a 2-credit cost. No contradiction with the annotations.

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

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

Three compact, information-dense sentences and a cost note. The purpose and output contents are front-loaded, and every sentence earns its place 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 read-only standings tool with an output schema and fully documented optional parameters, the description is complete: it covers scope, computed values, tiebreak behavior, default season, and cost. It does not need to repeat return fields already covered by the output schema.

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

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

All three parameters are already fully described in the schema, giving 100% schema coverage, so the baseline is 3. The description's season-default mention repeats the schema and adds no new parameter meaning.

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

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

Opens with 'Use for regular-season standings and playoff seeding' and enumerates the exact output fields: record, win%, points, splits, streak, division rank, and conference seed. The scope is unambiguous, though it does not explicitly differentiate itself from sibling tools like get_team_stats or get_advanced_stats.

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

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

Explicitly states when to use the tool: for regular-season standings and playoff seeding. It provides clear context and a default season, but does not mention alternatives or when not to use it.

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

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

Annotations already declare readOnlyHint=true, so safety is covered. The description adds concrete behavioral context: a credit cost ('Costs 5 credits') and the precise data scope (categories like passing, rushing, defense, EPA, standings row, weekly lines), which goes beyond what annotations 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 front-loaded with the core purpose and packs substantial useful detail into two sentences. The enumeration of stat categories is long but earns its place by clarifying exact output scope; the cost line is appended at the end, which is acceptable though not perfectly structured.

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

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

With an output schema present and read-only annotations, the description covers selection-relevant facts: scope, content, and cost. It does not need to describe return shape or safety because those are handled by schema and annotations. It is sufficiently complete for an agent to decide when to call it.

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

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

Schema description coverage is 100%, so all parameters are fully documented. The description adds no parameter-level meaning beyond reiterating that it is for one team's season; it does not explain team codes, season formatting, or season_type semantics beyond what the schema already states. Baseline 3 is appropriate.

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

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

The description clearly states the tool returns a specific bundle of team-season statistics (totals for passing/rushing/etc., EPA, standings row, weekly lines) scoped to a single team. It does not explicitly distinguish from sibling tools like get_advanced_stats or get_standings, but the content list is specific enough to identify its role.

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

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

The opening 'Use for one team's season' gives an explicit use case, but there are no exclusions or pointers to alternatives. The agent must infer that other tools like get_games or get_player_stats are for different resources; no when-not guidance is provided.

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

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

Annotations already declare readOnlyHint=true and openWorldHint=false, so the safety profile is covered. The description adds valuable behavioral context: the exact output contents, the nflverse spelling convention (with examples), and the cost. This goes beyond the annotations and helps the agent set expectations for 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.

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

Two sentences with zero redundancy. The primary use case is front-loaded, specifics are given in the second sentence, and the cost note is included without bloat. Every word earns its place.

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

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

For a simple read-only listing tool with optional filters and an output schema present, the description is complete. It tells what data to expect, the naming convention, and the cost. The only minor gap is that it does not explicitly state how the filters combine, but the schema's parameter descriptions already imply that. No critical information is missing.

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

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

Schema description coverage is 100% – both parameters (division and conference) have descriptive strings in the schema. The description does not add additional meaning about the parameters themselves, but it does imply that without filters all 32 teams are returned. Since the schema already documents the parameters, baseline 3 is appropriate; the description adds no extra parameter-level nuance.

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 ('list') and a specific resource ('teams'), and enumerates the exact data fields returned (conference, division, colours, logo URLs, team codes). It distinguishes itself from all sibling tools, which are about stats, games, players, etc., so an agent can immediately know this is the team-listing tool.

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 when to use it ('Use when you need team codes, or all 32 current teams...'), giving clear context. It does not explicitly name alternatives or exclusions, but given the sibling list contains no other team-listing tool, the usage context is sufficient. The cost hint ('Cheapest tool at 1 credit') adds decision 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?

Beyond the readOnlyHint annotation, the description discloses important defaults and fallback behavior ('returns current-season players by default, falling back to all players back to 1999 when none match'), data-coverage scope, cost (2 credits), and the returned id's role. This is meaningful behavioral context not present in the structured fields.

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

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

Three tight sentences: purpose, scope/defaults, and downstream value/cost. No filler, front-loaded with the actionable verb, and every clause carries information an agent needs before calling.

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 search tool with well-documented parameters, a read-only annotation, an output schema, and a sibling context, this description covers all essentials: what it searches, defaults, fallback, output linkage, and cost. Nothing critical is missing.

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

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

Schema description coverage is 100% and each parameter already has a clear description, so the baseline is 3. The tool description reinforces the query semantics with 'partial match' but does not add meaning beyond what the schema states for individual parameters.

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

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

The description states a specific verb and resource: 'find a player by name (partial match)' and immediately names the downstream purpose ('GSIS player id needed by get_player_stats'). It also scopes the data domain (25,000 players back to 1999), making it unambiguous how this differs from stats/game/roster siblings.

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

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

The description makes the intended context clear — use it to locate a player and obtain their GSIS id before calling get_player_stats. It does not explicitly enumerate when not to use it or name competing lookup tools, so it falls just short of a 5, but the downstream linkage provides strong situational guidance.

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