Keel Stats

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

Annotations already establish read-only, idempotent, non-destructive and closed-world, so the safety profile is covered. The description adds meaningful extras the annotations don't carry: the paywall on window="recent" (last 10 games requires Pro) and the rank convention (1 = most allowed). Return shape is only loosely characterized.

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 core purpose and appendices the taxonomy, rank direction, and tier gating. No filler and nothing the agent must read twice.

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

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

With no output schema, the description correctly describes what comes back (per-game allowed by position group plus ranks). Given only one required parameter and full schema coverage, this is close to complete; a hint at team identification or default ordering would close the gap.

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 enums on league and window, so the schema already carries the parameter documentation. The description reinforces the position-group values per league and clarifies rank direction, but adds only modestly beyond the structured fields — 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?

Specific verb+resource: what each team allows per game, broken out by position group, with league ranks, and the exact position taxonomy per league. An agent can tell this apart from a generic team_profile call. It doesn't name a sibling explicitly, which keeps it just under 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?

Usage is implied (defensive matchup / pace analysis) and the free vs. Pro distinction on window="recent" is stated, which is genuinely actionable. However, there is no explicit when-to-use vs. alternatives like team_profile, player_splits_and_on_off, or game_projection, and no stated 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?

Annotations already declare read-only/idempotent/non-destructive, so the bar is lower; the description adds meaningful context by disclosing Pro-tier gating, that Pro viewers automatically get factor weights and absence costs, and how include_breakdown behaves by default.

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

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

Front-loaded with the core purpose and outputs in the first sentence, with the Pro-tier detail pushed to a second sentence; dense but nearly every clause carries specific information, though the output list is a bit long.

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

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

With no output schema, the description does the heavy lifting by enumerating the returned fields, and it covers the Pro gating; it could be slightly more complete on game_id sourcing, but nothing critical for calling 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 description coverage is 100%, so all three parameters are already documented in the schema; the description only restates the breakdown/Pro concept without adding syntax or format detail beyond the schema, so 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?

States a specific verb (Get) and resource (pre-game win probability/projection for an NBA or NFL game), and it enumerates the exact outputs, so an agent can distinguish it from team_profile or player_profile siblings without opening the schema.

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

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

Usage is implied by the enumerated outputs and the schema note that game_id comes from tonight_slate or team_profile, but the description never says when to prefer this tool over siblings like team_profile or props_research, nor any 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?

Annotations already cover safety (readOnly, idempotent, non-destructive, closed world), and the description adds valuable content detail about what is returned (win probability/spread shift, teammate minutes and target/carry share increases). It doesn't discuss pagination or result size, but the substantive behavior is disclosed.

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?

One front-loaded sentence with a parenthetical that earns its place by enumerating the concrete outputs, and the alternate mode is stated last. 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?

With no output schema, the description carries the burden of explaining returns, which it does adequately by naming the key metrics. Minor gaps remain around output structure and result size, but an agent has enough to call it correctly.

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

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

Schema coverage is 100% so the baseline is 3, but the description adds meaning beyond the schema by spelling out what inspecting a player's absence yields (who absorbs minutes/targets and projection movement) and tying omission to the league report.

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: it returns what a player absence changes (win probability, spread shift, teammate usage shifts) and offers a distinct league-wide injury report mode. An agent can distinguish both modes without opening the schema.

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

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

Explicitly explains the two invocation modes: pass player_id for a specific absence, omit it for the full league injury report. It doesn't name when to prefer a sibling tool like player_profile or defense_vs_position, so it stops short of full alternative routing.

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

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

Annotations already declare readOnlyHint=true, destructiveHint=false, and idempotentHint=true, so the safety profile is covered. The description adds useful context about the data returned (injury status, recent 10-game log, Keel Impact headline), but does not disclose behavioral details like rate limits, caching, or response format 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 a single, front-loaded sentence that lists the key outputs efficiently. Every element earns its place, and there is no redundant or vague language.

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

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

There is no output schema, but the description enumerates the return contents (season averages, efficiency metrics, injury status, 10-game log), which compensates well. The only gap is the lack of explicit guidance on sourcing player_id (though the schema notes it comes from the search tool) and no note on response structure.

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 fully documents the three parameters (league, season, player_id). The description adds marginal value by implying that season averages and current injury status are returned, but it does not explain parameter usage or formats beyond the schema. 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 states a specific verb ('Get') and resource ('player profile'), and enumerates the contents (season averages, efficiency metrics, injury status, 10-game log), making it clear what the tool returns. However, it does not explicitly differentiate itself from sibling tools like player_splits_and_on_off or injury_consequences, leaving the agent to infer boundaries.

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?

There is no guidance on when to use this tool versus alternatives such as player_splits_and_on_off, injury_consequences, or game_projection. The usage is only implied by the contents listed, with no explicit conditions or 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?

Annotations already establish that this is a read-only, idempotent, non-destructive, non-open-world tool. The description adds useful scope by listing the NBA and NFL split types and noting that it is a "Pro" capability, but it does not clarify access requirements, data freshness, response shape, or limits. With annotations covering the safety profile, this is adequate but not rich.

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

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

The description is a single front-loaded sentence with no filler, opening directly with the core action. The semicolon-separated NBA/NFL branch is dense but efficient. It is slightly packed and run-on, but every phrase contributes to scope.

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, annotated tool with four fully documented parameters and no output schema, the description gives a useful inventory of the returned split categories for both leagues. It omits return formatting and some access details, but those gaps are minor for an agent deciding whether and how to invoke it.

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

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

Schema description coverage is 100%, so the schema already documents league, season, player_id, and teammate_id. The description reinforces the teammate concept with "with/without a teammate," but it adds no syntax, defaults, or additional meaning beyond the schema. Baseline 3 is appropriate when the schema does the heavy lifting.

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

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

The description clearly states a specific verb and resource: it returns player splits, including NBA on/off, clutch, garbage-time, and teammate splits, or NFL usage shares. The metric list makes the tool's data scope concrete. It does not, however, explicitly distinguish itself from sibling tools such as player_profile or props_research.

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 names the data types available but gives no explicit guidance on when to use this tool versus alternatives. It does not mention prerequisites, exclusions, or sibling tools, so the agent must infer selection criteria from the tool name and metric list.

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

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

Annotations already cover safety (readOnly, idempotent, non-destructive), and the description adds substantive mode-dependent behavior: the two distinct result sets and the specific analytics each returns. With no output schema, this return-shape disclosure carries real weight; only rate limits, auth/Pro-entitlement requirements, and pagination are left unstated.

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 two-mode split is front-loaded and each clause maps to a real capability rather than filler. However, it is delivered as a single semicolon-chained run-on, which makes the branch structure harder to parse than two or three short sentences would.

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

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

With five optional-style parameters, no output schema, and a read-only profile already declared by annotations, the description supplies exactly the missing piece: what each mode returns. An agent can decide which mode to invoke and what to expect without further documentation.

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

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

Schema coverage is 100%, so the baseline applies, and the description largely restates what the schema already documents for player_id, game_id, date, and stat. It does add that player_id selects the entire output mode, which is marginally useful, but no format or interaction detail goes 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 names a specific verb and resource ('Get Pro player props research') and enumerates the concrete payload: book-by-book odds & moves, line comparisons, hit rates, model probability, closing-line records, alternate ladders, and a daily cheat sheet. That enumeration does implicitly separate it from siblings like game_projection or defense_vs_position, but no sibling is named, so it stops short of 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?

It gives an explicit branch condition: pass player_id for per-player research, omit player_id for today's board plus cheat sheet, with an optional game_id filter. What is missing is when to prefer this over a sibling such as player_splits_and_on_off or game_projection, so it's clear context without 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?

Annotations already declare readOnly, idempotent, non-open-world, non-destructive behavior, so the safety profile is covered. The description adds one genuinely non-structured fact — that the deeper breakdowns (RAPM, on/off) are gated behind Pro — which is real value. It says nothing about result volume, pagination, or whether standings/power rankings cover a full league.

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 front-loaded sentence with no filler; each clause corresponds to one kind value. It is dense but readable, and the parenthetical detail is placed where it disambiguates 'ratings' rather than tacked on at the end.

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

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

With no output schema, the description must carry the return-value burden; it does so for 'ratings' but leaves standings and power_rankings undescribed (all teams? current week?). For a read-only tool whose annotations cover safety, this is adequate but incomplete.

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

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

Schema coverage is 100% with enum values enumerated, so the baseline is 3; the description earns a bump by spelling out what the abstract kind labels actually return (Keel Impact with offense/defense, box prior, RAPM vs. NFL EPA/play and success rate). That mapping helps the agent choose a kind rather than guess from bare enum tokens.

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?

Specific verb ('Get') plus concrete resources: NBA Keel Impact player ratings, NFL EPA/play leaderboards, standings, power rankings. The kind enum maps 1:1 to the sentence's clauses so an agent can tell what each mode returns. It stops short of differentiating from siblings like player_splits_and_on_off, whose 'on/off breakdown' overlaps with the Pro bullet here.

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?

Usage is only implied through the four kind names — nothing tells the agent when to pick this over player_profile, player_splits_and_on_off, or team_profile for related statistics. The 'Pro' note hints at an entitlement requirement but is not framed as a precondition.

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

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

Annotations already declare readOnly, idempotent, non-destructive and closed-world, so safety is covered. The description adds genuinely new behavior — accent- and typo-tolerant matching and the shape of the return payload — but says nothing about ambiguous/multiple matches, result limits, or what happens when nothing is found.

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

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

Two short sentences with zero filler: what it finds first, what it returns second. Nothing could be removed without losing 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?

For a two-parameter read-only resolver with rich annotations and full schema coverage, the description covers purpose, matching behavior and return type. It stops just short of telling the agent how to use the ids downstream, which is the one thing left implicit.

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 includes examples for query and the league enum, so the description adds no parameter detail beyond the schema. Baseline 3 applies since the schema does all the work.

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 resource (NBA and NFL players/teams) and a specific lookup mechanism (name or abbreviation), plus what comes back (numeric player_id or team_id). It is distinguishable from the analytics-oriented siblings, though the verb 'Find' is generic enough that the differentiation comes mostly from the domain nouns.

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?

Usage is only implied: an agent can infer this is the id-resolution entry point before calling player_profile or team_profile, but the description never says so. There is no explicit when-to-use or when-not statement and no mention of how the returned ids feed the sibling tools.

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

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

Annotations already cover the safety profile (readOnly, idempotent, non-destructive, closed-world), so the bar is lower. The description adds real value by disclosing what comes back (ratings, ranks, roster, game schedule) and that NFL metrics differ from NBA metrics, which matters since there is no output schema. It doesn't say what happens with an invalid team_id or how much game history is returned.

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 that front-loads the resource and then lists contents. No filler, no repetition of the 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?

With no output schema, the description does the expected work of naming the return categories, and the schema fully documents the three parameters. Missing only secondary detail such as season-over-season behavior or limits on 'recent games'.

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%, including the league enum and the note that team_id comes from the search tool, so the schema carries parameter meaning. The description only indirectly signals that league affects returned metrics; it adds no syntax or edge-case 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?

States a specific verb ('Get') and resource (NBA/NFL team profile) and enumerates the payload: record, offensive/defensive/net ratings or EPA per play & success rate with ranks, roster, and recent/upcoming games. That content profile clearly separates it from player_profile and rankings_and_ratings without needing an explicit exclusion.

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?

Usage is only implied by the content description; there is no explicit when-to-use, no prerequisites (e.g. requiring a team_id from search), and no named alternatives such as rankings_and_ratings or game_projection. An agent can infer the right context from the data described, but nothing is stated.

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

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

Annotations already declare this is a safe, idempotent, closed-world read, so the description only needs to add content-level context — which it does by enumerating what is returned (scores, pre-game probabilities, starters, injury changes). What it does not disclose is how 'tonight' is resolved without a date (timezone/rollover) or how stale/live data is refreshed.

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 front-loaded sentence that packs the resource, the date variation, and the full payload list with no filler. Nothing is redundant with the 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?

With no output schema, the description usefully inventories the return payload, which is exactly what an agent needs to decide whether to call it. Minor gaps remain: how the default 'current/next slate' boundary is determined and whether probabilities are model-derived or book-sourced.

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 both parameters (date format, league enum) are fully documented in the schema. The description reinforces the date parameter's optional nature and league options but adds no format or edge-case detail beyond the schema, so the 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?

Uses a specific verb ('Get') with a precisely enumerated resource set: tonight's or a given date's NBA/NFL games, live/final scores, pre-game win probabilities, NBA last-game starters, and injury status changes. None of the sibling tools (game_projection, injury_consequences, player_profile) covers a daily slate, so the scope is unambiguous.

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

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

The parenthetical '(or a specific date's)' implicitly tells the agent when to supply a date, but there is no explicit guidance on when to pick this over overlapping siblings like game_projection or injury_consequences. Usage is inferable from the resource list rather than stated.

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