BankrollSZN

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

Annotations only declare destructiveHint=false, so the description carries the burden. It says nothing about side effects, whether creation is user-facing or admin-gated, what defaults are applied (status defaults to pending, featured to false), or what happens on validation failure. For a mutation tool this is a substantial gap.

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

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

The single sentence is front-loaded and free of waste, but it is under-specified rather than concise -- six words cannot adequately frame an 8-parameter mutation tool.

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 8 parameters, no output schema, and only a destructiveHint annotation, the definition should explain required inputs, default behavior, and the admin-controlled fields embedded in the create schema. None of that is present, leaving the agent under-informed.

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 all 8 parameters (including required display_name, comment, rating and the admin-oriented status/featured/reviewed_at fields) are documented in the schema. The description adds no parameter meaning beyond that, so the baseline of 3 applies.

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

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

"Create a Testimonial record" states a verb and resource, but it is essentially a restatement of the tool name create_testimonial and adds no distinguishing detail. It does not differentiate from siblings like query_testimonial, update_testimonial, or delete_testimonial.

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 the sibling testimonial tools, no mention of prerequisites, and no indication of who should call it (e.g., user vs. admin). The description provides no usage context at all.

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 and discloses almost nothing. It implies destruction via the verb 'delete' but never states whether the deletion is permanent or soft, whether it cascades to related data, what authorization is needed, or what the response looks like.

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 tight sentence with no filler and the action front-loaded. It is efficiently sized, though its brevity is partly under-specification rather than pure conciseness.

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 destructive tool with no annotations, no output schema, and zero parameter description coverage, this one-liner is not complete enough. An agent is not told about irreversibility, authorization, id format, or error behavior before committing a delete.

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% and only one parameter exists. The phrase 'by id' confirms the id identifies the target record, but adds nothing about format (UUID, slug, integer-as-string) or whether the id comes from query_testimonial. The description does not compensate for the empty 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 ('Delete') and resource ('a Testimonial record'), scoped by 'by id'. The action is unambiguous and distinguishable from create_testimonial, query_testimonial, and update_testimonial, though it never names those alternatives explicitly.

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 versus query_testimonial or update_testimonial, and no prerequisites such as permissions or confirmation requirements. For a destructive operation, the absence of any 'when to use / when not to use' context is a real gap.

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 it as a read-only, idempotent, non-destructive operation, so the safety profile is covered. The description adds useful behavioral context by specifying the returned account data, including daily call usage, the daily limit, and per-data-set rebuild times, which helps an agent judge quota status and data freshness.

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, well-formed sentence that front-loads the verb and lists the exact information returned. Every phrase earns its place with no boilerplate or 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 and no parameters, the description carries the burden of explaining what the tool returns, and it does so by enumerating the plan, usage, limit, and data rebuild times. Annotations cover the safety profile, so an agent has everything needed to call 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 tool takes zero parameters, so there are no parameter semantics to document. Per the rubric, a zero-parameter tool receives a baseline of 4 even when the schema provides no additional parameter detail.

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 ('Shows') and names the exact resource: the user's BankrollSZN plan, calls used today, daily limit, and data set rebuild times. This clearly distinguishes it from the many sport-specific data-fetch siblings in the tool 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?

The content implies the tool is for checking account status and quota limits, but it never explicitly says when to use it, when not to, or what alternative to call instead. Usage is inferable from the listed outputs, matching the 'implied usage' level.

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

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

Annotations already cover the safety profile (readOnly, idempotent, non-destructive), so the description's value is in disclosing the two distinct response shapes: a list with date and sport versus full article text. It adds no permission, rate-limit, or pagination context (the schema mentions a plan limit that the description never echoes).

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

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

Three short sentences, front-loaded with the resource and then the two mode branches. Every clause carries information (what is listed, what extra fields appear, what full text enables) and there is 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 zero required parameters and no output schema, the description must carry the return-shape burden, and it does for both modes. It is slightly thin on the optional limit/sport filters and on whether list results are paginated, but nothing essential to a correct call 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 baseline is 3, but the description adds real semantic value the schema cannot: presence of slug switches the tool from list mode to full-text retrieval. It adds nothing for limit or sport beyond what the schema already documents.

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 (invoke/read) and resource (BankrollSZN playbook articles) and splits the behavior into two clearly-described modes based on whether a slug is supplied. It does not name or differentiate itself from sibling BankrollSZN tools (account, call, tools), 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?

Usage is implied rather than stated: 'so you can read today's playbook and quote it' hints at the intended scenario, and the slug/no-slug branches imply a browse-then-read workflow. There is no explicit when-not guidance, no prerequisites, and no named alternative among the many 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 declare readOnlyHint=true, idempotentHint=true, destructiveHint=false, but the description explicitly says it runs ANY BankrollSZN tool, and the sibling list includes destructive operations such as delete_testimonial. A tool that can execute destructive siblings cannot honestly be labeled read-only/non-destructive; the description contradicts the annotations.

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

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

Two tight sentences, front-loaded with the core capability and followed by the discovery pointer. No wasted wording.

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

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

For a dispatcher with a fully covered 2-param schema and no output schema, the description covers what it does and how to find callable names. It misses the safety caveat that the invocation can reach destructive tools, which matters given the mislabeled 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 coverage is 100%, so both 'tool' and 'arguments' are already documented in the schema. The description only reinforces that the name comes from bankrollszn_tools and does not add format or constraint detail beyond it, so the 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?

States a specific verb and resource: it 'Runs any BankrollSZN tool by name with its arguments.' An agent can grasp that this is the generic dispatcher versus the specific invoke_* siblings. It stops short of explicitly contrasting with those 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?

It tells the agent where to find tool names and schemas (bankrollszn_tools), which implies a discovery-then-invoke workflow. However it never states when to prefer this generic invoker over the many specific invoke_* siblings, leaving that choice 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?

Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the safety profile is covered. The description adds genuinely new context: results include tools registered after the session connected, explaining the discovery value. It does not describe output size or pagination, minor gaps for a directory listing.

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 waste. The what (list all tools with schemas) is front-loaded before the when-to-use and follow-up routing, which is the correct ordering for a discovery tool.

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?

No output schema exists, and the description states what is returned (each tool's description and input schema). Combined with the explicit pointer to invoke_bankrollszn_call for execution, an agent has everything needed to use this discovery tool correctly.

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

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

Schema coverage is 100%, so the single 'sport' prefix filter is fully documented in the schema. The description says 'every' tool without mentioning the optional filter, so it adds nothing beyond the schema and slightly understates the filtering capability; 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 and resource: it lists every BankrollSZN tool along with its description and input schema. This clearly distinguishes it from the ~110 sibling invoke_* tools, which execute specific data operations, and from invoke_bankrollszn_call, which executes a named 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?

Explicitly gives the trigger condition ('when a tool you need is not in your tool list') and names the follow-up tool ('then run it with bankrollszn_call'), so an agent knows both when to discover and what to do with the result.

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 readOnly, idempotent, non-destructive behavior, and the description stays consistent with them. It adds genuine value beyond the annotations by explaining how to read the results, e.g. 'Higher Elo is better' and that the teams view uses both adjusted and raw Elo.

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?

It is a single dense paragraph that front-loads the primary purpose and then details each view. Nothing is wasted, though the run-on packing of fields into one sentence is slightly harder 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?

With no output schema, the description carries the return-shape burden and does so adequately for both views. An agent has enough to invoke and interpret the tool; only cross-tool routing and pagination behavior remain unaddressed.

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 earns extra credit by explaining what the 'teams' view actually contains (adjusted Elo with league strength bonus, raw Elo, peak, games, league), which the terse 'Default matches.' enum description does not convey.

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

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

The description names a specific resource (League of Legends Elo) and spells out the two output modes, matches and teams, along with exactly which fields each returns. An agent can distinguish this from invoke_lol_optimizer, invoke_lol_projections, and invoke_lol_player_pool without inspecting any 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?

It makes the default explicit ('view matches (default)') and clarifies the purpose of each view, which tells the agent how to choose between them. It stops short of naming when-not-to-use conditions or pointing to a sibling tool for related data.

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 the operation read-only, idempotent and non-destructive, and the description adds useful context beyond that: 'Data refreshes every 30 minutes' (data freshness) and 'Returns DK ids in slot order' (output format). It does not discuss the free-plan lineup restriction's behavior or failure modes, but the annotations carry the safety burden well.

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, then efficiently enumerates format rules, modes, supported options and output/refresh behavior. Dense and largely waste-free, with only minor redundancy in the option list.

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 11-parameter tool with no output schema, the description covers formats, modes, supported modifiers, the returned value and data-refresh cadence. It lacks explicit auth/quota notes and edge-case behavior, but is otherwise complete enough for an agent to invoke 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 schema already documents all 11 parameters, setting a baseline of 3. The description goes further by tying the parameters to concrete constraints ('under $50,000', 'at most 4 players from one team', '2 or more games') and clarifying mode semantics that the schema leaves as 'Default gpp'.

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 ('Builds DraftKings League of Legends lineups') and names the data source (BankrollSZN projections), cleanly distinguishing it from siblings like invoke_lol_projections and invoke_lol_player_pool. It even spells out the supported roster formats (Classic vs Showdown), so an agent knows exactly what it produces.

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?

Explains both the format choice (Classic vs Showdown) and the game-type choice ('gpp scores the ceiling, cash scores the projection'), giving clear context for when to pick each mode. It stops short of explicitly naming alternative sibling tools or stating when NOT to use this optimizer, so it falls just short of the top band.

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), so the description is credited for what it adds beyond them: a 30-minute refresh cadence, the default main-slate behavior when slate_id is omitted, DraftKings scoring, and the classic vs showdown roster structures. Useful operational context an agent could not get from the schema.

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

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

The long field enumeration is dense and reads as one run-on sentence, but it is front-loaded with the resource definition and every clause carries information (fields, defaults, roster formats, refresh rate). Minimal waste, slightly list-heavy rather than prose.

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?

No output schema exists, so the description must carry the return-shape burden, and it does by naming the returned fields. Pagination and limit semantics are documented in the schema rather than the description, which is acceptable. Complete enough for a 0-required-param read tool.

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

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

With 100% schema description coverage the baseline is 3, but the description goes further by fixing the domain meaning of the position enum values, the CPT salary 1.5x multiplier, and the slate_id default. It adds real semantics rather than restating 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 concrete resource with its scope: 'The DraftKings League of Legends pool for one slate', and enumerates the exact fields returned (salary, CPT salary, projections, DK ids), which separates it from a generic projections tool. It never names a sibling to route against, so the agent must infer the difference from invoke_lol_projections rather than being told.

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?

'Without slate_id it returns the main slate and lists the other slates' gives real default behavior context, and the classic/showdown roster strings suggest when each format applies. However there is no explicit when-to-use-this-vs-an-alternative guidance, no note on chaining with invoke_lol_optimizer, and no 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 readOnlyHint=true, idempotentHint=true and destructiveHint=false, so the safety profile is fully covered. The description adds the returned metric set, which is useful return-shape context, but says nothing about plan/credit limits, pagination, slate freshness or auth - all relevant for a paid data endpoint.

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 naming the product, sport, platform and slate, followed by the field list. No filler, though the trailing stat enumeration reads like a return-value list crammed into a description that could have been a clause shorter.

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, enumerating returned fields (salary, floor, ceiling, value, kills/deaths/assists, CS, maps, win probability) is genuinely useful and fills the biggest gap. However, six parameters at 17% coverage and zero guidance on filtering or alternates leave the definition only partially complete for calling the tool correctly.

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

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

Schema description coverage is only 17%: just one of six parameters (limit) is documented, and even that defers to an unexplained 'plan limit'. The description hints at role-based filtering ('by role', which maps loosely to the position enum) but never explains team, league, player or sort_by semantics, so it does not compensate for the coverage gap.

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+resource: DraftKings League of Legends projections for the latest slate, with the stat set enumerated. It is clearly distinguishable in the abstract from siblings like invoke_lol_optimizer or invoke_lol_player_pool, though it never names those siblings to contrast scope.

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

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

The phrase 'for the latest slate' implies a DFS/lineup-building context but there is no explicit when-to-use, no prerequisites, and no routing to alternatives such as invoke_lol_player_pool, invoke_lol_elo or invoke_lol_optimizer. The agent gets no help choosing between the several LoL siblings.

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

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

Annotations already declare readOnlyHint, idempotentHint, and destructiveHint=false, so the safety profile is covered. The description adds the useful 30-day rolling window scope, but discloses nothing further about rate limits, the plan limit, or refresh cadence.

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 compact sentence that front-loads the scope and enumerates the metrics without padding. It is efficient, though the metric list borders on a schema dump rather than a purpose statement.

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 enumerates the returned metrics, which is its main value. It nonetheless omits any indication of row granularity, default sort, or how the team filter behaves, leaving the picture only partially complete for a data-retrieval tool.

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

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

Schema description coverage is 100% with four well-documented parameters (team, limit, sort_by, sort_dir) and two enums. The description adds no parameter meaning beyond what the schema already provides, 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?

The description conveys the resource (MLB bullpens) and a scope (last 30 days) plus the metrics returned, so an agent can infer it retrieves bullpen-form data. However, it uses no verb and offers no differentiation from the many adjacent MLB stat tools (e.g. invoke_mlb_team_splits, invoke_mlb_pitcher_splits), leaving its precise purpose ambiguous.

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 when-to-use guidance, no mention of alternatives among the large MLB sibling set, and no note on prerequisites or the plan-limit interaction hinted at by the schema. The agent must guess when this is preferable to other splits/stats 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?

Adds useful domain context by explaining the 1500 baseline and that higher pitcher ratings mean more strikeouts. However, it does not explain output fields, player-filter behavior, or how team_offense ratings should be interpreted; with annotations already covering read-only/idempotent safety, this is a moderate addition.

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 compact clauses, front-loaded with the resource and track. 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?

No output schema exists, and the description does not specify the return shape beyond mentioning ratings or how to combine this with other MLB tools. It is minimally adequate given full schema coverage and read-only annotations, but leaves an agent with gaps about output.

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 enum and parameter docs already carry the detail. The description only echoes the pitcher/team offense concepts without adding syntax, filtering, or limit behavior 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 that the tool returns MLB Elo ratings for pitcher and team offense on the strikeout track. The resource and scope are clear, though it does not explicitly contrast itself with siblings such as projections or splits.

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?

Offers no explicit when-to-use or when-not-to-use guidance, and does not mention alternatives like invoke_mlb_projections or invoke_mlb_pitcher_splits. The only usage-adjacent content is the rating scale explanation.

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, idempotentHint, and destructiveHint=false, so the safety profile is covered. The description adds useful context by specifying that the data is todays/current market lines and enumerating the returned fields, which matters since there is no output schema, but it omits freshness guarantees, refresh cadence, and auth or rate-limit behavior.

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 leads with the essential scope (todays MLB market lines by game) before listing the data fields. It is slightly dense with field enumeration but every element earns its place as return-value content given no output schema.

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 only two well-documented parameters and annotations covering safety, the main gap would be return content, and the description fills it by listing total, moneylines, no-vig probability, implied runs, run line, and line movement. Minor omissions remain (timezone definition of today, game-level pagination behavior) but the definition is largely complete for a read tool.

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

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

Schema description coverage is 100%, so both the team and limit parameters are already documented in the schema. The description mentions grouping by game but adds no syntax, format, or filtering semantics beyond what the schema provides, so the baseline of 3 applies.

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

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

The description states a specific resource (todays MLB market lines by game) and enumerates the exact data content returned, so the agent knows precisely what the tool yields. However, it does not differentiate itself from siblings like invoke_mlb_line_movement or invoke_odds_comparison, which overlap on line-movement and odds content.

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 explicit when-to-use guidance, no prerequisites, and no alternative tool named. The word Today's implies a recency scope but does not tell the agent when to prefer this tool over invoke_mlb_line_movement or invoke_odds_comparison.

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, so the bar is lower; the description still adds real behavioral context by listing returned metrics and the sample-size floors that make each window meaningful. It omits default behavior when optional filters are omitted, which is the one remaining behavioral gap.

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

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

Three dense sentences, front-loaded with the core purpose, then window semantics, then return payload — no filler. The metric list is long but each item is informative, so it stays close to optimal.

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 7 optional parameters and no output schema, the description does the right work by enumerating return metrics and window thresholds. It falls short of complete because all parameters are optional and the description never states defaults for split, window, or sort, leaving the agent to guess the no-argument behavior.

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, but the description goes beyond the enums by attaching a concrete meaning to 'season' (40+ PA) and 'l30' (20+ PA), which affects how an agent should interpret and trust the output. It does not explain sort_by/sort_dir or limit semantics 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 first sentence states a specific resource and verb-like scope: hitter performance against LHP/RHP, i.e. platoon splits for batters. That implicitly distinguishes it from invoke_mlb_pitcher_splits and invoke_mlb_team_splits, but neither sibling is named, so differentiation requires inference.

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 explains the two window options and their minimum PA thresholds, which is parameter help rather than usage guidance. It never says when to reach for this instead of invoke_mlb_pitcher_splits, invoke_mlb_matchup, or invoke_mlb_probable-style teammates, and gives no 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 readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the safety profile is covered. The description adds useful context by enumerating the returned fields and noting the board is 'Today's'. It does not disclose ordering, pagination behavior, or how the plan limit constrains results.

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. It is dense with feature names but every clause maps to actual board content, so it earns its place. Slightly list-like rather than prioritized, which keeps it from a 5.

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 and only two optional parameters, the description usefully doubles as a return-value explanation by naming the metrics an agent will receive. It omits row ordering and slate/date scoping context, but for a simple read-only board tool this is close to 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% for both parameters (team abbreviation and row limit), so the schema carries the parameter documentation. The description adds no filtering or format detail beyond it. 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 identifies the resource: a daily MLB home run board with a defined set of metrics (calibrated HR probability, edge vs. DraftKings price, barrel rate, park factor, weather boost). An agent knows what data it yields. It stops short of 5 because there is no explicit verb and no sibling is named (e.g. invoke_mlb_props) to differentiate the HR board from adjacent MLB prop/market 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?

No when-to-use guidance, no prerequisites, and no named alternative among the many invoke_mlb_* siblings. The agent must infer on its own whether this supersedes invoke_mlb_props, invoke_mlb_park_factors, or invoke_mlb_weather, all of which overlap with the listed columns.

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), so the bar is lower. The description adds genuine behavioral context beyond that: a 30-minute refresh cadence and a worked example of what a movement signal looks like. It does not address pagination or how far back the price history goes.

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, zero waste. The data payload is front-loaded, the usage cue and refresh cadence follow, and the parenthetical example earns its place by disambiguating 'movement'.

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 return-value burden and does so by naming the returned fields. All four params are optional and fully schema-documented, and refresh cadence is disclosed. Missing only a note on history depth / pagination behavior.

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 team, limit, sort_by and include_series fully, including the sort_by default and enum. The description adds no parameter-level syntax or semantics beyond that, 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?

States a specific verb+resource ('MLB game line movement for today') and enumerates exactly what is returned: opening/current total, moneylines, implied runs, change since open, price history. The concept of movement over time is naturally distinct from a static odds feed, though it never explicitly names sibling invoke_mlb_game_odds to sharpen the boundary.

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?

'Use it to see where the market moved' gives clear when-to-use context, reinforced with a concrete example (total dropping from 9 to 8.5). No exclusions or named alternatives are provided, so it does not reach the top band.

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, idempotentHint=true, and destructiveHint=false, so the safety profile is covered. The description adds useful behavioral context by detailing the returned slate fields (slate_id, name, game count, start time, salary cap, main slate flag) and the showdown list, though it does not discuss pagination or error handling.

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 compact sentences: the first front-loads what the tool returns, and the second provides downstream routing. Every clause earns its place with no redundant restatement.

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, read-only list tool with no output schema, the description sufficiently covers output fields and downstream usage. An agent has what it needs to call the tool and use its results 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 tool has zero input parameters, so there is no parameter semantics to clarify. The description mentions slate_id as returned data rather than an input, and the empty schema already makes the call signature clear.

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: lists today's DraftKings MLB slates, with classic vs showdown types and the returned fields. Names the main slate and distinguishes this tool from downstream siblings by explaining which slate_id feeds which optimizer/pool 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?

Explicitly says to use a classic slate_id with mlb_player_pool and mlb_optimizer, and a showdown slate_id with mlb_showdown and mlb_showdown_optimizer. This routes the agent clearly to the correct follow-up tools based on slate type.

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, idempotentHint, and destructiveHint=false, so safety is covered. The description adds useful behavioral context beyond that: the exact payload changes by mode, the breadth of returned fields, and the 'refreshes every 30 minutes' data-currency note.

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, front-loaded with the tool's identity, then mode behavior, then refresh cadence. Dense field enumerations make it long, but each clause carries information an agent needs to predict the response 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?

There is no output schema, so the description carries the full burden of describing returns, and it does so thoroughly for both modes (hand, implied runs, K props, splits, lineup order, matchup scores, park HR index). An agent can predict the response without guessing.

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 documents team, pitcher, and limit on its own, setting a baseline of 3. The description adds real meaning by spelling out how the presence or absence of pitcher/team toggles between list mode and full-lineup detail mode.

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+resource ('starting pitcher vs opposing lineup matchups') and precisely scopes it to 'Today's' MLB slate. It does not explicitly name or contrast with siblings such as invoke_mlb_pitcher_splits or invoke_mlb_hitter_splits, which it partially overlaps, so an agent must infer differentiation from content alone.

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 clearly explains the two invocation modes: 'Without pitcher or team it lists every starter...' versus 'With pitcher or team it adds the opposing lineup...'. That is genuine when-to-use guidance for the parameters, though it offers no exclusions or pointers to alternative tools for narrower needs.

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, so the bar is lower, yet the description adds substantial behavior: contest_type loads preset lineup counts (20 for 20max, 150 for 150max), stacks limit hitters against own pitchers, postponed games are removed, and the result carries dk_upload plus a csv in DK's export format. Nothing here contradicts 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?

Front-loaded with purpose then constraints, and essentially every sentence earns its place (roster shape, preset counts, stacking rules, continuation protocol, export format). It is dense run-on prose rather than cleanly segmented, which slightly hurts scanability but wastes no words.

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 24 parameters and no output schema, the description carries the return-value burden and does: it documents dk_upload, the csv slot order and cell format, and the next_call/remaining pagination fields. For a 24-param optimizer with two enums and nested objects, an agent has everything needed to call and iterate 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 real meaning on top: preset-driven lineup counts per contest_type, the 4-2 default stack shape with the primary/secondary concept, and the prior_lineups/total_lineups continuation semantics that the schema only names. A few numeric parameters (min_salary, own_lambda) are left entirely to 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 and resource ("Builds DraftKings MLB classic lineups") and immediately fixes the scope: $50,000 cap, BankrollSZN pool, and the exact roster shape (2 P, C, 1B, 2B, 3B, SS, 3 OF). It explicitly differentiates from the closest sibling: "Classic only. For Showdown use mlb_showdown_optimizer."

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?

Names the alternative tool and the condition that selects it (Showdown), and gives an explicit orchestration protocol for large portfolios: when the result has next_call, call again with prior_lineups and total_lineups until remaining is 0, then use the last csv. That is when-to-use guidance the agent cannot infer from the schema.

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, so the safety profile is covered. The description adds useful method context — the numbers are 'adjusted' via 'measured multipliers from graded contests' — and names the returned fields (20-Max number, contest number, change). It does not cover auth, rate limits, or whether contest_type changes recompute or merely rescale.

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 tightly written sentences; the purpose is front-loaded and the output summary follows. The parenthetical contest-type list mildly duplicates the schema enum, but it is brief and never buries the lead.

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 partially compensates by naming what is shown (base number, contest number, change). For a six-parameter read-only retrieval tool with full schema coverage, that is close to sufficient, though it stops short of describing sort/limit interplay or pagination.

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 all six parameters are already documented, including enum meanings and the slate_id default. The description only glosses the contest_type enum ('20-Max base' etc.), adding no new syntax or format meaning beyond the schema — the baseline 3 applies 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?

States a specific verb and resource — projected DraftKings ownership for one slate adjusted to a contest type — and enumerates the adjustment modes (20-Max base, 150-Max, 3-Max, Single Entry). The 'MLB' + ownership + contest qualifier cleanly separates it from sibling invoke_nfl_ownership_by_contest and from invoke_mlb_projections.

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 domain (retrieve ownership projections for a slate/contest type), and the schema points at mlb_list_slates for slate_id, but the description itself gives no explicit when-to-use vs when-not guidance or alternative tools. An agent must infer that this supplements rather than replaces invoke_mlb_projections.

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, idempotentHint=true, and destructiveHint=false, so the safety profile is covered. The description adds useful interpretation context beyond annotations: 100 is league average, results split by batter handedness, and metric coverage. It does not describe pagination or default limit behavior, but it substantially helps interpret the 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?

Three front-loaded sentences with no filler: purpose/scope first, then the scale, then the metric list. The metric list is dense but earns its place by telling the agent what the tool returns.

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 tool with no output schema and fully documented parameters, the description gives enough to invoke and interpret the result: scope, normalization scale, and covered metrics. It could be more complete by describing row structure or pagination, but those gaps are minor for this lookup.

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

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

Schema description coverage is 100%, so the baseline is 3. The description loosely relates to the split and metric/sort concepts, but it does not add syntax, defaults, or meaning beyond what the schema already provides for park, limit, split, and sort_by.

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 identifies the resource (park factors), scope (every MLB stadium), and segmentation (batter handedness), with a list of covered metrics. It is specific enough to distinguish this from other MLB tools, though it does not state an explicit verb or directly route against 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?

No when-to-use guidance, prerequisites, or alternatives are provided. The description only defines the dataset; an agent must infer that this is the tool for park-factor queries rather than being told explicitly.

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/idempotent/non-destructive, so the safety profile is covered. The description adds genuinely useful context beyond annotations: a 30-minute data refresh cadence and a full accounting of the computed fields (changepoint flag, consecutive-below-normal starts, reasons), which tells the agent how fresh and how derived the output is.

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?

Purpose is front-loaded and the long metric enumeration is dense rather than padded, with the refresh cadence saved for the end. It is somewhat list-heavy, but every clause adds signal about the returned 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?

With no output schema, the description carries the burden of describing return values, and it does so thoroughly, plus it discloses data freshness. Nothing critical is missing for correct invocation, though it could note filtering/pagination semantics for the limit parameter.

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

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

Schema description coverage is 100%, so the schema already documents all five parameters including the red/yellow/green enum and the starting_today default. The description adds marginal meaning (what 'flag level' represents) but does not extend parameter syntax or behavior, 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?

States a specific verb and resource (pitcher health check) and enumerates the exact metrics returned: velocity, z-scores, spin/release drift, changepoint flag, trend, flag level, bet angles. It is clearly a velocity/health tool, but it never distinguishes itself from the close sibling invoke_mlb_pitcher_splits, 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?

The description implies usage by specifying 'starting pitcher health check for today' and the schema default starting_today=true, so the agent can infer when it applies. However, there is no explicit when-to-use/when-not guidance and no pointer to alternatives such as pitcher_splits or starters, leaving 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?

Annotations already declare readOnly/idempotent/non-destructive, so safety is covered. The description adds genuinely useful behavioral context beyond that: minimum sample thresholds (50+ batters faced for season, 20+ for l30), which tells the agent about data reliability and why rows may be missing for some pitchers.

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 tightly packed sentences with no filler: purpose first, then window semantics, then the return fields. Slightly list-like at the end, but every clause carries information an agent needs.

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 takes on the burden of naming returned metrics (ERA, FIP, xFIP, SIERA, K/BB rates, SwStr, GB rate) and does so. All 7 parameters are documented in the schema, so the remaining gap is only defaults and how pitchers are identified, which is minor for a filterable list tool.

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

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

Schema coverage is 100%, so the baseline is 3. The description earns extra credit by explaining semantics the schema does not: the schema only says 'Time window: season or l30', while the description defines what each window actually means and its sample-size floor, and ties vs_LHH/vs_RHH to the LHH/RHH framing.

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?

Opening sentence states a specific resource and scope: pitcher performance split by handedness of opposing hitters. An agent can infer this differs from invoke_mlb_hitter_splits, but the description never explicitly names or contrasts with that sibling, leaving the differentiation implicit.

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 through the split/window explanations rather than stated: the description never says when to pick this over invoke_mlb_matchup, invoke_mlb_starters, or invoke_mlb_team_splits. Context is present but the agent must infer the selection criteria.

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

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

Annotations already declare readOnly/idempotent/non-destructive, so safety is covered; the description adds genuinely useful behavior: the main-slate default and the exact upload string format 'Name (dk_player_id)'. It does not cover pagination or how the plan limit interacts with results.

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 payload, and the field enumeration substitutes for a missing output schema, so it earns its length. The run-on field list is dense but not padded with 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, listing the returned columns is essential and done well, and the slate default plus cap context orient the agent. Only minor gaps remain (result limits, how the pool relates to the optimizer sibling), which is strong for a seven-parameter read tool.

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

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

Schema coverage is 100%, so the baseline is 3 and the schema already documents all seven filters. The description adds only the main-slate default (relevant to slate_id) and the meaning of the returned dk_player_id; it adds no syntax or filter interaction 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 resource ('the DraftKings MLB pool for one slate') and enumerates the returned fields, so an agent knows exactly what data it retrieves. It does not explicitly distinguish itself from the close siblings invoke_mlb_projections or invoke_mlb_optimizer, which also feed lineup building.

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 usage context ('Use it to build a lineup under the $50,000 cap') and a default ('Defaults to the main slate'), and the schema points to mlb_list_slates for slate_id. However, there is no when-not guidance or explicit routing between this pool and the projections/optimizer siblings.

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

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

Annotations already declare readOnlyHint, idempotentHint and destructiveHint=false, so the safety profile is covered. The description adds the useful fact that it returns both a postponed-games list and risk-alert records with a percent and detail field, which partially compensates for the missing output schema, but it says nothing about auth needs, freshness/latency, or whether results are team-scoped when the parameter is omitted.

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, no filler, and the payload contents are front-loaded before the call-to-action. Slightly tight to the point of leaving the omitted-parameter behavior unstated, but nothing is wasted.

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, single-optional-parameter lookup with no output schema, the description covers what the tool returns and when to reach for it. The remaining gap is behavioral edge cases (empty team parameter, data staleness) rather than anything that would cause a mis-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?

Schema description coverage is 100% for the single optional team parameter, so the schema already carries the parameter meaning. The description adds no filtering semantics of its own, not even what an omitted team returns (all games vs. none), which is the one ambiguity the schema leaves open.

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 (games postponed today) plus a second output class (active postponement risk alerts with weather risk percent and detail), so the agent knows this is not a generic weather tool. It never names the sibling it differs from (e.g. invoke_mlb_weather), so sibling disambiguation is left to inference.

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?

"Check this before you stack a team" gives a concrete moment to use the tool, which is more than nothing. But there is no when-not guidance and no alternative tool is named for the overlapping weather/forecast case, so usage is only implied rather than routed.

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), so the bar is lower. The description's contribution is the 'Today's' recency signal plus the enumeration of returned stat families, which is genuinely useful because no output schema exists. It still says nothing about slate scope, refresh cadence, or whether stats are per-game or per-slate.

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 source and recency before listing fields; nothing is wasted. It is a bit list-heavy, but for a data-feed tool that list is the payload description and earns its place.

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

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

With no output schema, the description partially compensates by enumerating returned fields, which is the most valuable part. It remains incomplete on the points an agent needs to call it correctly: which slate/day the projections cover, how team/position filters behave, and how the result relates to sibling projection sets.

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 75%, just under the high-coverage baseline, and the schema itself documents team, limit, and position. The description implicitly maps its stat list to the sort_by enum values (proj_own, proj_hr, proj_k) but never explains the team or position filters or the interaction between the row limit and the plan limit noted 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 identifies the resource ('Today's BankrollSZN MLB DFS projections') and enumerates the stat categories returned, so an agent knows roughly what comes back. However it is a noun phrase with no verb, and nothing distinguishes it from closely related siblings such as invoke_mlb_player_pool, invoke_mlb_ownership_by_contest, or invoke_mlb_props, several of which overlap the listed fields (ownership, HR, K).

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 statement of when to use this tool versus the many alternative MLB endpoints in the sibling list. The only implied usage is that it is a DFS projections feed; nothing tells the agent whether to reach for this instead of invoke_mlb_player_pool or invoke_mlb_ownership_by_contest, or what prerequisites (e.g., a slate) apply.

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, so safety is covered. The description adds genuine behavioral context the annotations don't: games already started are excluded, and the no-player default ranks by biggest gaps.

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?

Purpose is front-loaded in the first sentence, followed by output columns, then the player-mode and started-game rules. The column enumeration is slightly listy but each element is informative, so no sentence is wasted.

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 describing return values and does so by enumerating the row fields. Modes and the started-game filter are covered; pagination/rate details are only implied via the schema's plan-limit note.

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 and the schema documents all seven params. The description adds real meaning beyond the schema by explaining the `player` param's dual behavior (one pitcher vs. default gap listing), lifting it above baseline.

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

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

States a specific verb and resource (lists today's MLB pitcher props next to BankrollSZN projections) and names the two covered markets (strikeouts, pitcher outs). An agent can distinguish this from the broad invoke_mlb_projections sibling purely from the text.

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

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

Gives clear operational context: pass `player` to target one pitcher, omit it to get the biggest gaps by default. It does not name a sibling alternative or an explicit when-not-to-use, so it stops 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 declare readOnlyHint/idempotentHint/destructiveHint, so the safety profile is covered. The description adds real behavioral context beyond that: the full field payload, the 1.5x CPT projection multiplier, the rp_p_appear reliever probability, the DK opener/bulk tags (dk_tag PO or PLR), and the row-shape change when slots=true. No auth or rate-limit notes, keeping it at a solid 4.

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 purpose leads the paragraph and the enumerated field list is justified because there is no output schema. It is a long single block, but almost every clause carries informational weight; only the dense mid-sentence field run slightly hurts scanability.

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 compensates by listing the returned fields. Slate selection, the slots behavior, and the bullpen inclusion toggle are all covered, leaving only sort semantics and the difference from the showdown optimizer unaddressed.

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 already 88%, so a 3 is the floor. The description goes further by explaining the slots flag's row expansion and the slate_id-versus-game targeting choice, adding meaning the schema entries only gesture at. It does not clarify sort_by semantics or the interaction of limit with the plan limit beyond what the schema says.

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 and mode: 'DraftKings MLB Showdown (captain mode) pool for one game', then enumerates the exact fields produced (salary, projection, CPT projection 1.5x, ceiling, ownership, DK ids, batting order). It is clearly a single-game captain-mode pool, but it never names the siblings it must be distinguished from (e.g. invoke_mlb_showdown_optimizer or the season-long invoke_mlb_player_pool), leaving the boundary implicit.

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?

'Pass slate_id or a game like PHI@ATL' gives concrete input guidance, and 'slots true returns one CPT row and one FLEX row per player' tells the agent how to shape output. However there is no when-to-use versus when-not guidance and no routing to invoke_mlb_showdown_optimizer for lineup construction, so usage is only implied.

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), so the bar is lower, and the description still adds real behavior: the search is exact unless the node limit is hit, plus the return contract (DK ids in slot order) and the scoring model per mode. It stops short of noting runtime or plan limits, but this is well beyond what the annotations give.

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 lineup format, then mode behavior, then supported knobs, then the solver caveat and return format. Dense but every clause carries information; minor redundancy in restating the CPT 1.5x and both-teams constraint.

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 15 optional params and no output schema, the description compensates well: it explains the return value, the optimization modes, and the solver's exact-vs-node-limit behavior. It doesn't restate the slate_id prerequisite from mlb_list_slates, but that lives in the 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%, so 3 is the baseline, but the description goes further by explaining the semantics the schema only labels: gpp scores ceiling minus an ownership penalty, cash scores projection, own_lambda 0 removes ownership, and it ties the listed knobs (captain, locks, excludes, per-team cap, reliever switch, hitter cap) together meaningfully.

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 (Builds) and resource (DraftKings MLB Showdown lineups) and pins down the exact format: 1 CPT at 1.5x plus 5 FLEX under $50,000 with both teams required. This distinguishes it cleanly from the sibling invoke_mlb_optimizer (classic format) and invoke_mlb_showdown.

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 explains what gpp vs cash does and how key knobs behave (own_lambda 0 removes ownership), which is implied guidance for mode selection. However, it never states when to reach for this tool versus invoke_mlb_optimizer or the other showdown siblings, and offers no explicit 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 readOnlyHint, idempotentHint, and destructiveHint=false, so safety is covered. The description adds rich context about the returned data — edge, model chance, no-vig market chance, stake, sim numbers, graded record, and per-pick fields — which is valuable beyond annotations, though it omits auth or rate limit details.

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 tool's purpose and return content, and every sentence carries useful detail since there is no output schema. However, the long comma-separated lists are dense and could be easier to parse with structure.

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?

While return values are described thoroughly enough to substitute for a missing output schema, the two input parameters remain completely unexplained. An agent cannot know how to filter by team or bet_type, leaving a significant gap for a tool with optional filters.

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 has 0% description coverage for team and bet_type, and the description never mentions either parameter. No format, allowed values, or effect of filtering is given, so the description does not compensate for the schema gap.

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 resource — daily BankrollSZN MLB Monte Carlo picks — and lists the output fields, so an agent knows what it returns. It does not explicitly distinguish itself from other MLB siblings like invoke_mlb_projections or invoke_mlb_game_odds, keeping it from 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?

No when-to-use guidance or alternatives are provided. The description implies daily picks retrieval but never says when to choose this over other MLB tools or whether filters 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?

Annotations already declare readOnlyHint, idempotentHint and destructiveHint, so safety is covered. With no output schema, the description usefully discloses the returned fields (team, opponent, venue, handedness, first pitch time) and that times are in Central, adding real value beyond structured 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?

A single, front-loaded sentence that names the resource and enumerates the payload fields with zero filler. Nothing could be trimmed 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 zero-required-parameter read tool with no output schema and fully documented parameters, the description covers scope and returned fields adequately; only finer points, such as how confirmed vs probable status is represented, are 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%, so team, limit and player are already documented in the input schema. The description adds no parameter-level meaning (e.g., how team and player filters interact), so the baseline of 3 applies.

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

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

States a clear resource and scope: today's confirmed and probable MLB starting pitchers by game. An agent can tell this returns today's pitching probables rather than historical splits or health data. It does not explicitly name sibling tools like invoke_mlb_pitcher_health to sharpen differentiation.

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 phrase 'Today's confirmed and probable' implies the usage window, but there is no explicit when-to-use, when-not-to-use, or named alternative such as invoke_mlb_pitcher_splits or invoke_mlb_pitcher_health. Usage is inferable rather than 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 readOnlyHint, idempotentHint, and destructiveHint=false, so the safety profile is covered. The description adds real value by naming the columns returned (probability, odds, DK line, edge, sprint speed, pop time, time to plate), which matters because there is no output schema. It does not disclose freshness guarantees, auth, or rate limits.

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

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

A single compact sentence that front-loads the resource and then lists the payload fields. No filler sentences; the only mild redundancy is the subtitle-like 'model board' phrasing.

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 and annotations covering safety, the description's enumeration of returned fields is exactly the missing piece an agent needs to judge relevance. Filter behavior for the three params is left implicit, which is the main remaining 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 description coverage is 100%, so team, limit, and player are already documented with examples in the schema. The description adds nothing about filtering semantics (e.g., whether team/player act as filters or whether limit interacts with the plan limit). 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 names a specific resource (today's stolen base model board) and enumerates its contents, so an agent can tell it is a stolen-base prop/edge board rather than a generic props feed. It does not explicitly contrast itself with adjacent siblings like invoke_mlb_props or invoke_mlb_hr_board, but the topic 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?

There is no explicit when-to-use, when-not-to-use, or named alternative. The word 'Today's' implies it is a daily snapshot for stolen-base betting/DFS, but the agent must infer that. No prerequisites or routing guidance are given.

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 readOnly, idempotent, and non-destructive behavior, so the safety profile is settled. The description usefully clarifies that these are season-long team aggregates vs LHP/RHP, but adds nothing about return shape, pagination, or the interaction with the plan limit noted in the schema.

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

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

A single front-loaded sentence with no filler; the core resource is stated first and the metric list is compact. It is efficient, though the metric enumeration is somewhat redundant with the sort_by enum values.

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 helpfully names the returned metrics, which is the most important missing piece for a stats endpoint. However, it omits usage context and any note on filtering/split semantics, leaving the description adequate but not complete for an agent deciding among many MLB siblings.

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%, with both enums (split, sort_by) fully documented, so the schema carries parameter meaning. The description lists the metric vocabulary that maps to sort_by keys but adds no syntax or format detail 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?

States a specific resource and scope: team-level offense split by opposing pitcher handedness, naming the exact metrics returned (wRC+, wOBA, OPS, ISO, K%, BB%). It implies distinction from invoke_mlb_hitter_splits via 'team offense' but never names that sibling explicitly.

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?

No when-to-use guidance is given. There are obvious alternatives in the family (invoke_mlb_hitter_splits for individual hitters, invoke_mlb_pitcher_splits, invoke_mlb_team_stacks), and the description provides no conditions for choosing this one over them.

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, idempotentHint=true, and destructiveHint=false, so the safety profile is covered. The description adds useful domain semantics for leverage_gap (above 0 = field owns the stack less than its boom rank) but says nothing about pagination, plan limits, or how 'today' and the default slate interact.

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-loads the resource ('Team stack board for today') and puts the leverage_gap interpretation in a compact second sentence. The metric enumeration is long but each item maps to a returned column, so it earns its place.

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

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

There is no output schema, so the description must convey what comes back, and it does by listing the returned metrics. Remaining gaps are minor: no mention of row ordering defaults (sort_by is optional with no stated default) or how limit interacts with the plan limit.

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 five parameters are already documented in the schema; baseline 3 applies. The description's leverage_gap note adds interpretation for one sort_by enum value but no syntax, format, or per-parameter behavior 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 the resource precisely ('Team stack board for today') and enumerates the metrics it returns (TeamROO score, implied/expected runs, boom/bust chance, ceiling runs, opposing starter, ownership). This lets an agent distinguish it from siblings like invoke_mlb_optimizer or invoke_mlb_ownership_by_contest, though the verb is only implicit ('board', not 'returns/lists').

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?

No when-to-use or when-not guidance and no alternatives named. 'For today' and the leverage_gap definition imply context, but nothing tells the agent when this board is preferable to invoke_mlb_sim_picks, invoke_mlb_optimizer, or invoke_nfl_team_stacks (the sibling variant).

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, idempotentHint=true and destructiveHint=false, so the safety profile is covered. The description adds data-freshness context ('Today's first pitch') and clarifies the proprietary impact split, but does not discuss auth, rate limits, pagination, or return format.

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 wasted wording. Weather is stated first, followed by the impact metrics, which is efficient and appropriate for a low-complexity data retrieval tool.

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-required-parameter, read-only MLB data tool with full schema coverage and no output schema, the description identifies the returned subject matter well. It is slightly incomplete on usage context and parameter behavior, but sufficient 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?

Schema description coverage is 100%, so the schema already defines both parameters. The description adds no parameter meaning, such as whether team filters the result set or how limit interacts with the plan cap. The baseline is 3 when the schema carries 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 resource and scope: today's first pitch weather for each MLB game plus BankrollSZN impact on HR, runs and extra base hits split by handedness. It is clear enough to distinguish this from generic weather or park-factor tools, though it does not explicitly name an alternative sibling.

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

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

The description says what data is returned but gives no when-to-use guidance, prerequisites, or alternatives. It does not tell an agent when to choose this over invoke_mlb_park_factors, invoke_mlb_hr_board, or other MLB stat 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/idempotentHint/destructiveHint, so the safety profile is covered. The description still adds substantive behavior beyond that: the 0-100 scoring scale, the fact that higher favors the hitter, the three sub-metrics (combined/pitch_mix/zone_overlap), opponent implied total for pitchers, and the 30-minute refresh cadence.

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 carrying distinct information (purpose, three views, refresh), with the primary purpose front-loaded. Slightly dense but no filler sentences; every clause earns its place.

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

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

With no output schema, the description does the work of describing returns (combined/pitch_mix/zone_overlap scores, opponent implied total, lineup ranking) and refresh timing, so an agent knows what comes back. It stops short of explaining how the team/player/limit filters interact, but is otherwise complete for a read-only scoring tool.

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

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

Schema coverage is 100%, so the baseline is 3, but the description meaningfully expands the 'view' enum by explaining what each value returns (hitter scores, starter vulnerability, lineup ranking), which the terse schema text ('Default hitters.') does not. Team, player and limit are not elaborated beyond the schema, keeping it short of a 5.

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 resource and outcome: it scores hitters against the opposing starter's pitch mix and zone locations, and enumerates three distinct views (hitters/pitchers/teams). This is far more specific than a tautology, but it never explicitly contrasts itself with similarly-themed siblings such as invoke_mlb_matchup, invoke_mlb_hitter_splits or invoke_mlb_pitcher_splits.

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 real guidance for choosing among the tool's own views (hitters is the default, pitchers covers vulnerability, teams ranks lineups) and implies 'today' freshness. However, it never says when to reach for this tool versus the many adjacent MLB matchup/split tools, so cross-tool selection is left 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?

Annotations cover the safety profile (readOnly, idempotent, non-destructive), and the description adds substantial context beyond them: nightly rebuild, data window since 2016, K=64, 1.5x finish weighting, the exact fields returned, and a candid accuracy limitation. This is more behavioral disclosure than most read-only tools 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?

Front-loaded and dense with no filler sentences; the mechanics parenthetical and the log-loss caveat each earn their place. Only minor density cost from packing multiple facts into one sentence.

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 fully compensates by enumerating returned fields for both views, plus data provenance and a fitness-for-purpose caveat. Nothing needed to call 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 100%, so the baseline is 3, but the description adds real meaning: it explains that 'view: card' returns each bout with both ratings, the Elo win probability and the market win probability, and that 'fighters' returns rating/peak/fights/last date/change/weight class. This clarifies what each view actually yields rather than just echoing the enum.

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: UFC Elo ratings for every active fighter, with the two view modes (fighters vs card) distinguished by content. An agent can separate it from siblings like invoke_mma_projections or invoke_mma_fight_sim 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?

Gives explicit conditional guidance: because Elo is weaker than the market (log loss 0.671 vs 0.590), it is used only when no odds exist, and the 'card' view is scoped to the next card. It stops short of naming sibling tools such as invoke_mma_odds as the preferred alternative, so routing still takes a small inference step.

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, idempotentHint and destructiveHint=false, so the safety profile is covered. The description adds real value beyond that: it discloses the data sources (de-vigged DraftKings/FanDuel moneyline, method and round odds), the modeling approach, and a backtest benchmark (30.9 vs 35.6 points on 2,267 fights), which tells an agent how much to trust the output.

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 operation ("Monte Carlo simulation (4,000 runs) of every bout on the next UFC card"), and the long output enumeration is dense but each item is a distinct capability. The second sentence on methodology is a run-on but earns its place by grounding the projections.

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 return-value burden and does so thoroughly, listing every output family including props and model-vs-market edges. It is slightly incomplete on scope (which card(s), one or many) and does not explain how filters interact, 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 description coverage is 100%, so limit, min_ev and fighter are already documented in the schema, which sets the baseline at 3. The description gestures at the edge/EV concept but adds no parameter-specific syntax or defaults beyond what the schema 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 gives a precise verb+resource: a 4,000-run Monte Carlo simulation of every bout on the next UFC card, then enumerates the exact outputs (win probability, method, round, distance, props, edges). It never distinguishes itself from near-identical siblings such as invoke_mma_sim_picks, invoke_mma_projections, or invoke_mma_odds, so an agent cannot route between them from the text alone.

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 when-to-use guidance, no prerequisites, and no named alternative. A reader can infer this is a simulation/edge tool, but nothing tells them when to pick it over invoke_mma_sim_picks or invoke_mma_projections, or that it targets only the next card.

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 cover the safety profile (readOnly/idempotent/non-destructive), but the description adds real behavioral context: the source and sample of the history flags (7,169 bookings, 2019-2026), the effect sizes, and the honest caveat that they separated risk only weakly out of sample. That tells the agent how much weight to place on the flags, going beyond anything structured.

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 purpose is front-loaded, but the bulk is a dense run-on enumeration of return fields that reads as a wall of text rather than tight prose. It is informative yet heavier than necessary, so it lands below the concise ideal.

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 return values, and it does so thoroughly — field-by-field including bouts pulled from the card. It is nearly complete for a data-heavy tool; only the when-to-use framing is thin.

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

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

Schema description coverage is 100%, so the baseline is 3. The description adds no extra meaning to level/limit/fighter beyond the schema, which already defines 'flagged' as everything except Clear. Baseline applies.

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

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

The description states a specific resource (UFC fighters booked in the next 14 days) and enumerates the exact data returned — watch level, slate lock, DK/FD status, injury news, odds movement, etc. It is clearly distinguishable from siblings like invoke_mma_late_changes or invoke_mma_odds, so an agent can tell what this tool is 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 only implied by the content described; there is no explicit 'use this when' statement and no routing against the neighboring invoke_mma_* tools (late_changes, odds, matchups). The one interpretive note — that history flags are context not a forecast — guides reading results rather than choosing this tool.

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, idempotentHint, and destructiveHint=false, so the safety profile is covered. The description goes well beyond that by disclosing how scratch_pct is computed (base 1.8% from a logistic fit, raised by live news, site status, and odds moves), what the not100 flags mean, and that data is refreshed hourly.

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 tool's purpose in the first sentence and then details the two views. It is dense but every sentence adds substantive information about output fields, with no filler or repetition of the schema.

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, so the description carries the burden of explaining return values. It thoroughly enumerates the fields for both views, explains the scratch_pct methodology, defines the not100 flags, and notes the hourly refresh cadence, leaving no major gaps for an agent to invoke the tool correctly.

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

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

Schema description coverage is 100%, so the structured field descriptions already define each parameter. The description adds value by detailing exactly what the fighters view and changes view return, which helps an agent pick the correct view enum, and by contextualizing scratch_pct for min_scratch_pct filtering.

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 resource: a scratch risk board for UFC fighters over the next 14 days plus a log of card changes. It is highly specific and an agent can tell it apart from generic MMA tools, but it never names or contrasts with any sibling tool, so it falls short of full sibling differentiation.

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 implies usage by describing the scratch risk board and its 14-day horizon, and it explains what each view returns. However, it never says when to choose this tool over alternatives like invoke_mma_injuries or invoke_mma_projections, and it provides no exclusions or prerequisites.

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, idempotentHint, and destructiveHint=false, so safety is covered. The description adds useful behavioral context beyond annotations: it is limited to the next card, distinguishes DraftKings and FanDuel formats, and lists the returned slate 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?

The description is front-loaded with the resource and scope, then adds only relevant details about site formats, returned fields, and downstream use. It is dense but 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 read-only listing tool with no output schema, the description provides enough detail: what it lists, which sites and formats are covered, what fields are returned, and how to use the slate_id. Nothing essential for correct invocation appears to be 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, so there are no parameter semantics to document. With an empty input schema, the baseline score is 4.

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 exactly what the tool returns: UFC/MMA DFS slates for the next card, with site-specific DraftKings and FanDuel formats plus the fields included. It is specific enough that an agent can distinguish this as the slate-listing tool among the many MMA sibling tools.

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

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

It gives clear downstream usage: use the returned slate_id with mma_projections and mma_optimizer. It does not explicitly state when not to use this tool or name alternatives, but the next-card scope and downstream handoff make the intended use clear.

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

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

Annotations already declare readOnlyHint, idempotentHint and non-destructive, so the safety profile is covered. The description adds the meaningful scope constraint that this is limited to the next UFC card (not historical bouts), but omits pagination, freshness or how the simulated outcome table is produced. This is moderate added context over the structured hints.

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

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

The purpose is front-loaded in the opening clause before the field inventory. The single long sentence is dense, but with no output schema the field enumeration substitutes for one and largely earns its length; it could still be split for readability.

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 compensates by spelling out the returned payload in detail, and parameters plus safety annotations are handled in structured fields. The one real gap is the absence of usage/routing guidance against the crowded mma_* sibling set.

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 both parameters (limit with its plan-limit caveat, and fuzzy fighter name matching), so the schema does the heavy lifting. The description adds no parameter guidance of its own, making the baseline 3 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 names the resource precisely — a side-by-side bout profile for the next UFC card — and enumerates the exact data fields returned, so an agent knows this is a stat-heavy per-bout lookup. It stops short of distinguishing itself explicitly from overlapping siblings like invoke_mma_elo, invoke_mma_fight_sim or invoke_mma_projections, which the field list partially (but not explicitly) overlaps.

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 when-to-use or when-not-to-use guidance and no alternative is named. The description implies usage by describing the payload, but with nine sibling mma_* tools an agent gets no routing help for choosing this over invoke_mma_elo or invoke_mma_fight_sim.

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/idempotentHint/destructiveHint already declaring a safe read, the description adds genuinely new context: prices refresh several times a day (freshness expectations) and each price carries the time it was pulled. It does not discuss auth, plan limits beyond the schema's 'plan limit applies,' or pagination, so 4 rather than 5.

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, front-loaded with what the tool returns, then enrichment (model probabilities), then the routing hint and freshness note. Dense but every sentence carries information; the market enumeration is slightly long but justified for a comparison tool.

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?

No output schema exists, and the description compensates well by enumerating the returned markets, the accompanying BankrollSZN model probabilities, and price timestamps. Only freshness pagination behavior and the meaning of 'plan limit' remain unaddressed, which is minor.

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

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

Schema coverage is 100%, so the schema fully documents limit, market, and fighter, including the enum. The description's list of markets echoes the enum values and adds no syntax or formatting 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?

States a specific verb-and-resource: retrieves DraftKings and FanDuel prices for every bout on the next UFC card, and enumerates the exact markets returned. This clearly separates it from invoke_odds_comparison and invoke_mma_projections, which an agent can distinguish without opening any 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 routes the agent: 'For the best price and expected value per market use mma_fight_sim,' naming the alternative and the condition that selects it. It stops short of stating when NOT to use this tool or how it relates to invoke_odds_comparison, so it falls just short of a 5.

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

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

Annotations already declare readOnly/idempotent/non-destructive, so the safety profile is covered. The description adds real behavioral value beyond that: it discloses the exact solver, the platform-specific lineup rules (DK 6 under $50k; FD MVP 1.5x, 5 more under $100), and the returned fields, which matters since there is no output schema.

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

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

Three dense sentences, front-loaded with the core action and platform rules, with no filler. The platform-rules sentence is long but each clause carries usable constraint 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 an 11-parameter solver with no output schema and no required params, the description covers the domain rules, the option set, and the return payload (lineup salary/projection/ceiling/ownership plus fighter exposure). Nothing an agent needs to 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 100%, so the baseline is 3. The description goes further by tying parameters to domain meaning the schema omits — lock/exclude by name, the objective blend ratio, ownership cap semantics, and the DK/FD lineup structures that govern count and min_unique behavior.

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 (Builds) and resource (UFC lineups) with an exact solver, and names the two supported platforms. It is clearly the MMA member of the optimizer sibling family (invoke_lol_optimizer, invoke_nba_optimizer, etc.) without needing to open a 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?

Gives clear usage context: objective=proj is for cash games, ceil for tournaments, and max_total_own is flagged 'For tournaments'. However, it never names an alternative tool (e.g. invoke_mma_projections or invoke_mma_sim_picks) or states when NOT to use it, so it stops short of explicit 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 establish readOnly/idempotent/non-destructive, and the description layers on meaningful extra context beyond them: the data refresh cadence (every 30 minutes), the derivation method (de-vigged sportsbook market plus opponent-adjusted strike/takedown/control rates), and a backtest benchmark (30.9 vs 35.6 mean miss). This is well beyond the annotation-implied safety profile.

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

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

Front-loaded with a one-line statement of what the tool returns, followed by context. The field enumeration and methodology/backtest sentences are dense but each carries information an agent needs (returned columns, provenance, freshness). Slightly long, but no clear waste.

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?

No output schema exists, so the description must convey the return shape — and it lists the per-fighter fields (projection, floor, ceiling, ownership, win/KO/submission probabilities, etc.) plus data source and refresh cadence. For a read-only projection tool this is complete enough to call correctly.

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

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

Schema description coverage is 100%, so all six parameters (site, limit, fighter, sort_by, slate_id, contest_type) are already documented in the schema, including enum meanings and defaults. The description adds nothing parameter-specific beyond a passing reference to 'the chosen contest type', 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?

States a specific verb and resource: UFC DraftKings/FanDuel projections for the next card. The DFS-specific fields it enumerates (salary, value per $1K, projected ownership, leverage-adjacent metrics) clearly set it apart from sibling tools like invoke_mma_odds, invoke_mma_elo and invoke_mma_fight_sim, which cover the betting and simulation angles separately.

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: it says 'for the next card' and mentions the slate/contest-type defaults, so an agent can infer this is the DFS-projection tool. However, there is no explicit when-to-use versus alternatives (e.g., invoke_mma_odds, invoke_mma_fight_sim, invoke_mma_optimizer) and no prerequisites or exclusions 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 readOnly/idempotent/non-destructive, so the safety profile is covered. The description adds useful context that moneyline and method props are 'live' while total rounds picks are 'paper' (non-published), which exceeds the annotations. Beyond that it largely enumerates output content rather than disclosing freshness, limits, or auth needs.

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?

It opens with the core identity, but the bulk is a single long run-on sentence with heavy comma enumeration of outputs. It is information-dense without filler, yet not cleanly structured or front-loaded for scanning.

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?

No output schema exists, so the description must carry the return-value burden and does so well, enumerating win/KO/submission/decision chances, end round, distance, total rounds, de-vigged DraftKings/FanDuel prices, picks, and graded record with CLV. For a read-only analytics tool this is nearly complete; only freshness/limit context 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 75%, so the schema carries most of the load (limit and fighter are documented there). The description only adds meaning for 'view' by stating card is the default and history is the alternative, which the enum alone doesn't disclose. This is about the expected baseline 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 states a specific resource (UFC fight sim across the next card) and verb (simulate 20,000 times, return chances/picks/graded record), so an agent knows exactly what comes back. It distinguishes itself in spirit from single-fight or odds siblings by emphasizing sim picks + graded record. It does not, however, explicitly name a sibling like invoke_mma_fight_sim or invoke_mma_odds to sharpen the boundary.

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 closing phrase 'view card (default) or history' gives the two operating modes and the default, which is light usage guidance. There is no explicit when-to-use-this-vs-alternatives statement nor any exclusions relative to the many sibling MMA 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 establish readOnly/idempotent/non-destructive, so the safety profile is covered. The description adds real behavioral context beyond that: the board is scoped to the next main card, leverage is defined as win-chance share divided by ownership share, and the explicit caveat that underdog outcomes are DFS leverage rather than a betting edge steers how the result should be used.

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-loads the resource and scope before the field list, and the field enumeration is dense but earns its place for a tool with no output schema. The historical-stat sentence is verbose (3.2 wins per card, 95.5%, 93.8 vs 97.7 points) and the key 'not a betting edge' caveat is buried at the end rather than surfaced.

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 fully compensates by enumerating every returned field, defining the derived leverage metric, and supplying base rates that let an agent interpret results. Scope (next main card), default site context, and the interpretive caveat round it out; nothing needed to call or explain the 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?

Schema description coverage is 100%, including enum explanations and defaults, so the schema already carries the parameter burden. The description adds conceptual meaning for two of them (leverage as a sortable metric, ownership varying by contest type) but no 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 resource and scope: 'Every underdog on the next UFC DraftKings main card,' then enumerates exactly which metrics come back (moneyline and movement, win/KO/sub/R1 chances, DK/FD points, salary, ownership, leverage). This is self-differentiating from siblings like invoke_mma_odds or invoke_mma_projections, which do not produce an underdog-only leverage board.

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 closing clause 'this is DFS leverage, not a betting edge' plus the leverage definition and historical base rates give clear context for when the output is appropriate. It stops short of naming alternatives (e.g., invoke_mma_odds for straight odds work) or stating exclusions, so it is clear context without explicit 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?

The annotations already declare read-only, idempotent, non-destructive behavior, and the description adds substantial context beyond that: model version, data recency, fallback slate behavior, early-season rate handling, and out-of-sample calibration. There is 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?

The description is front-loaded and dense with useful content, especially the output field list, which is necessary because there is no output schema. It is somewhat run-on in the first sentence, but overall most information 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?

Given the absence of an output schema and the complexity of the tool, the description is complete: it enumerates returned fields, explains model provenance and refresh cadence, covers early-season behavior, and provides calibration evidence. An agent has enough context to call and interpret it correctly.

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

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

Schema description coverage is 100%, so the input parameters are fully documented in the schema. The description focuses on output fields and model behavior rather than adding meaning to the input parameters, which is the baseline case when the schema already does the heavy lifting.

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

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

The description states a specific resource and scope: foul trouble risk for each NBA player on today's slate, with a defined fallback to the next slate. It clearly distinguishes itself from general NBA projection or rotation tools by focusing on foul risk outcomes and the BankrollSZN foul model.

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 temporal context (today's slate, or next slate if today has no games) and freshness (refreshes every 30 minutes), which implies when the data is applicable. However, it does not explicitly say when to use this versus sibling tools like invoke_nba_projections or invoke_nba_rotations, nor does it state 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 the safety profile (readOnly, idempotent, non-destructive), so the bar is lower, and the description adds genuinely useful behavior: results are sorted by impact and data refreshes every 30 minutes, which affects caching/staleness decisions. It omits rate limits and the concrete 'plan limit' interaction hinted at in the limit parameter.

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?

Purpose and impact-scoring concept are front-loaded in the first clause, followed by a dense field inventory and the refresh note. It is one long sentence, but with no output schema the field list earns its space; only the trailing teammate clause feels slightly padded.

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 return-value burden and does so thoroughly, listing every field plus sort order and refresh interval. The remaining gap is usage context — when an agent should prefer this over the other NBA tools — but the payload description is complete.

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

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

Schema description coverage is 100%, so all six filters (team, limit, player, status, min_impact, plays_today) are already documented, setting the baseline at 3. The description's 'impact score from 1 to 10' reinforces the min_impact semantics but adds no new filter syntax or default behavior.

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 resource (NBA injury report) and enumerates the exact payload — impact score 1-10, player, team, status, DK points, usage, priced-in flag, teammates who gain minutes — which makes the tool's output unmistakable. It is clearly distinct from stat siblings like invoke_nba_projections or invoke_nba_foul_risk, though it never explicitly names those alternatives.

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 when-to-use guidance: no statement of what question this answers, no exclusions, and no reference to the many adjacent NBA siblings (invoke_nba_rotations, invoke_nba_projections, invoke_nba_foul_risk). The 'priced in' field hints at DFS lineup use but the agent must infer it. Only the refresh cadence gives any operational context.

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 readOnly/idempotent annotations, the description discloses meaningful behavior: contest_type applies the site preset (mode, ownership penalty, salary floor, contest ownership), explicit parameters override it, and cash mode scores projection plus 0.25 x floor. It does not mention runtime, lineup generation limits, or failure modes if constraints are infeasible.

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 dense sentences with no filler and the core purpose is front-loaded. The second sentence stacks several preset/formula clauses, making it slightly heavy to parse but every clause adds real 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 13-parameter tool with no output schema, the description covers most constraints but omits how to obtain slate_id and player identifiers for lock/exclude, and does not state whether lineups are returned as a list or aggregated string. Adequate, but an agent still has unresolved questions before a first call.

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?

With only 23% schema description coverage across 13 parameters, the description carries most of the load and does so for locks, excludes, unique lineups, salary floor, ownership cap, per-team cap, and contest_type override semantics. Still unexplained are slate_id (source and format), the lineups count, and the exact id format expected by lock/exclude.

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+resource ('Builds DraftKings NBA classic lineups') and the data source ('BankrollSZN projections'), which cleanly separates it from sibling tools like invoke_nba_projections, invoke_nba_player_pool, or the other sports' optimizers. Roster size (8 players) and output ('DK ids in slot order') are also stated.

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: it's clear you call it to construct lineups, but there is no explicit when/when-not guidance, no mention of an alternative (e.g. build manually from invoke_nba_projections), and no prerequisites such as where slate_id or player ids must come from. The contest_type sentence explains behavior, not tool selection.

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

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

Annotations already establish read-only, idempotent, non-destructive behavior, so the bar is lower. The description adds genuine context the annotations cannot: the data source (box scores), the definition of pace with overtime removed, and a 30-minute refresh cadence. It does not mention auth requirements or pagination behavior.

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 definition, then a dense but substantive enumeration of return fields. Given there is no output schema, the field listing earns its place, though the single run-on paragraph could be split for scanability.

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 full burden of describing return values, and it does so thoroughly for both views. Combined with the refresh cadence and pace definition, an agent has everything needed 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 already 100%, so baseline is 3, but the description adds meaning beyond the schema labels: it defines what the 'tier' enum values (Up/Neutral/Slow) represent, what each 'view' returns, and that sort_by applies to the teams view. This is real added value over bare enum lists.

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 pace/possessions for today), the computation method (from box scores, possessions per 48 minutes with overtime removed), and the source. An agent can immediately distinguish this from invoke_nba_projections, invoke_nba_rotations, or invoke_nfl_pace.

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?

Clearly explains the two operating modes and what each returns, letting the agent pick 'games' (default, per-game pace vs market totals) or 'teams' (all 30 teams with ratings). It does not, however, say when to reach for this tool instead of related NBA siblings such as projections or sim_picks.

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 this is a safe read (readOnlyHint, idempotentHint, destructiveHint=false), so the bar is lower. The description still adds real behavioral context: model scope (regular season since 2022-23), freshness (updated daily in season), and an accuracy backtest (3.71 vs 4.41 baseline). It omits any return/format or pagination behavior, but that gap is minor given the annotation coverage.

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?

It is front-loaded with the metric definition before moving to views and provenance, and most sentences carry load-bearing information about the data model. It is somewhat dense and includes promotional/backtest material that is not strictly needed to call the tool, but nothing is truly wasted.

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 10-parameter read tool with no output schema, the description defines the returned metrics, the archetype categories, freshness, and model scope, which is most of what an agent needs. Return shape and pagination handling are left to the schema, which is acceptable given there is no output schema to lean on.

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 70%, so the schema already documents most fields. The description earns extra credit by expanding the view enum with real meaning (systems = team lift for latest season; step_up = gains when the star sits over 5+ games) and by noting the player param accepts part of a name, which goes beyond the terse schema strings.

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 Player Index) and verb-level detail: it decomposes DK points per 36 into player_value, system_lift and teammate_drag. It also explicitly distinguishes itself from the nearest sibling by declaring it is 'a ranking of who is real and who rides the team, not a nightly projection,' which separates it from invoke_nba_projections.

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 enumerates the three views and when each applies: players (default; pass player for a single player's season history), systems (team lift, latest season), and step_up (biggest gains when the star sits, 5+ games). That is clear context for selecting a mode, but it never names an alternative tool to use instead, so exclusions are 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 declare readOnly/idempotent/non-destructive. The description adds real interpretive value: it explains that questionable players' proj/ceiling/minutes are play_p times the if-plays line, and names the if_plays_* columns - behavior an agent couldn't infer from annotations alone.

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 what the tool returns, then roster format, then the projection caveat. Dense but every sentence carries information relevant to interpreting the result.

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 explain the key return columns (play_p scaling and if_plays_* fields), which is valuable. But it omits the meaning of both input parameters and any pagination/scope behavior for slate selection, leaving meaningful gaps.

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 never mentions the two parameters (slate_id, min_projection) or their format/effect. It describes output columns instead of input semantics, so it fails to compensate for the undocumented 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 specifically that it returns the full NBA DraftKings classic pool for one slate in compact form, with DK ids, and describes the roster format. Clear verb+resource, though it doesn't explicitly differentiate from siblings like invoke_nba_player_index or invoke_nba_projections.

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?

Implies usage for lineup building via the roster format and $50,000 cap context, but never explicitly says when to use this vs invoke_nba_projections, invoke_nba_player_index, or invoke_nba_optimizer. No exclusions or prerequisites stated.

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