v12-dfs

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

With no annotations, the description carries the full burden. It explains idempotency (returns existing active key or mints one), the rotate behavior, and the admin-gated nature. It also mentions that it always returns the pasteable connect block. It does not cover edge cases like invalid email or rate limits, but the main behaviors are well-described.

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

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

The description is well-structured with a clear purpose statement, behavioral details, and response examples. It is front-loaded with key information. However, some redundancy exists (e.g., repeating idempotency), and the response examples add length. Overall, it is appropriately detailed without being overly verbose.

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 no annotations and no output schema, the description provides substantial behavioral context: idempotency, rotate functionality, admin-gating, and response format. It covers the core aspects but lacks explicit error scenarios beyond validation errors. It is complete enough for an AI agent to understand the tool's behavior and constraints.

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 only 33% (only 'rotate' has a description). The description adds context for 'email' (user identifier) and 'rotate' (revoke and mint), but 'tier' is not described beyond the schema's pattern and default. The description compensates partially, but the tier parameter lacks explanatory guidance.

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

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

The description clearly states the tool's purpose: idempotently issue a user's API key and return the pasteable connect block. It specifies the action (issue key), resource (user's API key), and key behaviors (idempotent, rotate). It distinguishes itself from sibling tools, which are mostly betting-related, by being an admin-only key management tool.

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

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

The description explicitly states that this is 'Admin-gated' and is called server-side via the dashboard's per-user provision route. It provides guidance on when to use rotate=true (to revoke existing keys and mint a fresh one). However, it does not explicitly state when not to use the tool or mention alternative tools for similar operations.

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 description discloses that no authentication is required and details the returned content (config with placeholder key, endpoint map, generate body fields). With no annotations provided, this adequately covers behavioral traits like read-only nature and output structure.

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 reasonably concise and front-loaded with the core purpose. Minor redundancy (title 'Agent Guide' followed by same phrase) and an incomplete response section prevent a perfect score.

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 no input parameters and no output schema, the description sufficiently covers the tool's function and output. The response section is thin but adequate for decision-making. Error handling or additional details are not critical but would improve completeness.

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 no parameters, so the baseline is 4. The description adds value by explaining what the tool does without needing input, making it easy for an agent to understand invocation.

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

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

The description clearly states the tool's purpose: self-serve onboarding to connect any agent to the V12 motor. It specifies the output (copy-paste MCP + REST config) and distinguishes from sibling tools like admin_issue_key and betting_agent_guide.

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

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

The description provides guidance on authentication (no auth) and key management (issue each user their own key via POST /v1/admin/create-key). While it doesn't explicitly list when not to use the tool, the context is clear for initial setup.

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, and the description does not disclose any behavioral traits (e.g., read-only, side effects, permissions). The mention of a 200 response is too minimal to inform 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?

The description is very short but lacks structure. The 'Responses' section is incomplete and adds little value. A guide tool should have a more informative overview.

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 lack of parameters and output schema, the description could still explain what information the guide provides. It only mentions a 200 response, leaving the agent uninformed about the guide's content.

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 no parameters, so the baseline score is 4. The description does not need to add parameter details, but it could have outlined the guide's scope.

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 name and description clearly indicate it is a guide for using MLB betting tools and reading output, distinguishing it from action-oriented sibling tools. However, it lacks specificity on what exactly the guide covers.

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 explicit guidance on when to use this tool versus alternatives like agent_guide or other betting tools. The description implies it's for understanding tool usage but offers no exclusion 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?

No annotations provided; description does not disclose side effects, data sources, or write operations. It merely states it 'models' and yields edge, leaving ambiguity about computational cost, API calls, or mutability.

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 short but includes irrelevant HTTP response details and an error example that adds no value. The title 'Analyze Prop' is redundant. The core line is buried under noise.

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, yet the description fails to describe the return structure (only vague 'edge'). Parameter domain knowledge is missing. Given 4 parameters and complex domain (sports betting), the description is insufficient 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 coverage is 0% and description provides no explanation for any of the 4 parameters (name, prop, season, threshold). The defaults and possible values for 'prop' are not described, leaving the agent to guess.

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

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

The description clearly states the verb 'Model' and resource 'a single player's prop vs tonight's FanDuel line', with output 'edge'. This distinguishes it from siblings like betting_scan_edges (broader) and betting_player_form (only form).

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: analyzing a single player's prop for edge. But no explicit when-to-use or when-not-to-use compared to similar tools like betting_scan_edges or betting_best_bets. No prerequisites or common pitfalls mentioned.

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?

Description mentions it's a screen vs vig line and includes Savant validation for power props, but does not disclose rate limits, auth requirements, or the exact structure of the response. With no annotations, it provides some behavioral context but lacks thoroughness.

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 longer than necessary, including response codes and example that could be separated. The core purpose is front-loaded, but there is some redundancy. It earns its place but could be more concise.

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 no output schema, the description should explain the return format of top edges, but it does not. Parameter semantics are missing. The tool has moderate complexity, and the description does not fully equip the agent to predict behavior or interpret results.

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

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

Input schema has two parameters (limit, min_edge) with no descriptions. The description does not explain what these parameters control or their acceptable ranges, leaving the agent without guidance on how to set them. Schema coverage is 0% and description fails to compensate.

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

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

Description clearly states the tool performs a board sweep of multiple main prop markets and returns top edges. It distinguishes itself from single-market scans and game-side value tools, providing a specific verb and resource.

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 this for open 'what's hot' queries to avoid concluding from single-market scans. It also mentions that game-side value is separate, pointing to alternative tools (betting_sharp, betting_game_model).

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 description discloses returns (naive vs correlation-adjusted EV, Kelly stake, honest verdict) and explains correlation effects for same-game vs cross-game parlays. However, it includes an irrelevant validation error example, which can be confusing, and does not mention any side effects or authorization needs. With no annotations, transparency is adequate but could be clearer.

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 purpose but includes a lengthy example response for a 422 validation error that is not the primary output. This detracts from conciseness and could confuse agents about the expected response format. It could be streamlined to focus on the actual return 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?

Given no annotations or output schema, the description lacks details on valid parameter values (e.g., prop types), output format structure (beyond mentioning EV and stake), and error handling. The validation error example is not a substitute for output schema. The tool's complexity is moderate, but the description leaves gaps for an agent to infer.

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 only echoes the structure '{legs:[{name, prop, threshold}]}' without explaining what these fields mean. The defaults suggest 'prop' types like 'home_run' and 'threshold' as integer, but no semantic guidance is provided, leaving agents to guess valid values.

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 title 'Build Parlay' and description 'Correlation-aware analysis of a parlay (>=2 prop legs)' clearly state the tool's purpose. It specifies it's for parlays with at least two legs, but does not explicitly differentiate from siblings like 'betting_analyze_prop' for single props.

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 it should be used for parlays with >=2 legs, but does not provide explicit when-to-use or when-not-to-use guidance, nor does it mention alternatives. Usage context is implied but not fully 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?

The description reveals data source (ESPN API) and that no model is needed for certain edges, but it lacks details on data freshness, error handling beyond 422, and does not explicitly confirm read-only behavior in the absence of 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 somewhat verbose and includes a response example that is not directly relevant to the tool's primary output. While it covers multiple aspects, the structure could be improved for clarity.

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 low parameter count and no output schema, the description provides some context on edge types and timing but fails to describe the success response format or fully define the parameter, leaving 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?

The schema has one parameter with no description, and the description only hints at its meaning by mentioning 'pitcher_strikeouts' in the context of overnight use. It does not define possible values or explain the parameter clearly.

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 explains that the tool identifies cross-book value between FanDuel and DraftKings, mentioning LINE_SHOP and PRICE_SHOP edges. However, it does not explicitly state the tool's purpose in a clear verb-resource format, and the purpose is implied rather than direct.

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

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

The description provides usage context such as noting that arbitrage is not auto-reported and that overnight only pitcher_strikeouts overlaps, but it does not explicitly specify when to use this tool versus sibling tools like betting_scan_edges or betting_market.

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 burden. It discloses that data comes from ESPN's public scoreboard and is surfaced as-is, that V12 has no game-outcome model (so lines are from books, not fabricated), and that fields may be null if a book hasn't posted. This is transparent about data source and limitations, though it does not discuss pagination, rate limits, or authentication.

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 verbose and includes an unnecessary example response for validation errors and code blocks for response types. It front-loads some useful information but contains fluff that could be trimmed. A more concise description would improve clarity.

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 is present, so the description should explain the return structure. It mentions the types of markets (moneyline, run total, run line) but does not provide the actual JSON shape or fields. The example response is for a validation error, not a success, leaving the output format ambiguous. The description is incomplete for a tool with no output schema.

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

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

The schema has 2 parameters (date, team) with 0% description coverage. The description only adds meaning for the 'team' parameter (optional filter for team names like 'Yankees' or 'NYY'). The 'date' parameter is not mentioned at all, leaving its format and purpose unclear. This fails to compensate for the schema's lack of descriptions.

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

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

The description clearly states the tool retrieves GAME markets (moneyline, run total, run line) for today's MLB games. It specifies the resource (game lines) and action (retrieve), and distinguishes from player props by mentioning that player props can't answer these questions. The verb is implied (retrieve) and the scope is clear.

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

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

The description provides some usage guidance: use for game lines, not player props, and warns that books may not have posted games. However, it does not explicitly differentiate from sibling tools like 'betting_market' or 'betting_matchup', leaving the agent to guess when to use this over alternatives. The context is helpful but not comprehensive.

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

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

With no annotations, the description partially discloses behavior: it's a model that screens for edges, grounded in real inputs, and returns success or validation errors. However, it lacks details on the success response structure, side effects (if any), and internal behavior beyond the model type.

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 verbose, including an example error response and extraneous details (e.g., 'negative-binomial'), which could be condensed. It lacks front-loading of critical information and would benefit from tighter organization.

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

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

Given the tool's complexity (statistical modeling) and lack of output schema, the description is incomplete. It does not explain the input parameters, the output format for success, or how to interpret the model results, leaving an agent underinformed for effective 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 coverage is 0% and the description provides no explanation of the 'team' and 'date' parameters. The agent must infer from names alone, with no format, constraints, or examples for 'date', leaving significant ambiguity.

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

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

The description clearly states the tool models run markets (team totals over/under and NRFI/YRFI) vs FanDuel line, and distinguishes from sibling betting_market for raw lines. However, jargon like 'negative-binomial' and 'empirical ~0.53 base' may reduce clarity for some agents.

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

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

Explicitly states this is a screening tool ('A SCREEN vs the market, not a lock') and advises validation with CLV. Also directs users to sibling betting_market for raw lines, providing clear when-to-use and when-not-to-use guidance.

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

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

With no annotations, the description provides some behavioral context (append-only, evidence base) but lacks details on permissions, idempotency, rate limits, or side effects. It mentions response codes but not deeper 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?

The description is short and front-loaded with purpose and field list. The example response adds some visual structure but is not essential. Writing is efficient with minimal redundancy.

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 tool with no schema descriptions or output schema, the description should include field explanations. It lists fields but does not clarify them, leaving the agent to infer meaning. The success response format is omitted.

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

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

Schema coverage is 0%, but the description lists all 10 parameters with optionality markers (?), adding structure beyond the schema. However, it does not explain each parameter's meaning (e.g., market, selection), leaving gaps in 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 explicitly states the tool records a bet per user to track P&L and CLV, clearly defining its action and resource. It distinguishes from siblings like betting_settle_bet and betting_my_bets through its unique logging purpose.

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 for logging bets and notes append-only behavior as evidence, but does not explicitly mention when not to use it or compare with alternatives like betting_my_bets or betting_settle_bet.

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

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

With no annotations, the description carries full behavior disclosure burden. It states the market is 'as-is (no model)' and mentions real odds and de-vig fair price. However, it lacks details on authentication, rate limits, or potential destructive actions. The example response is for a validation error, not a success, which may confuse.

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 purpose and market lists, but includes verbose response code sections and a misleading example. The market list could be more streamlined. Overall, it is moderately concise but contains clutter that reduces efficiency.

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 no output schema, the description should detail return values. It mentions 'real odds + de-vig fair price' and lists market types, but does not specify the structure, format, or how markets are organized. It is adequate but not thorough for a comprehensive market board 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 0%, so the description must compensate. It does not explain the 'team' or 'date' parameters beyond implying 'team's game'. No format hints or optionality cues are provided. The description adds minimal semantic value beyond the schema definition.

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

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

The description clearly states the tool retrieves 'FULL FanDuel market board for a team's game' and lists all market types (game lines, F5, team totals, player props). It distinguishes from siblings by mentioning 'betting_analyze_prop' as a follow-up for model edge, implying this is the comprehensive market view.

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

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

The description provides usage context: it surfaces the book's market as-is. It explicitly names an alternative: 'For our model edge on a prop, follow up with betting_analyze_prop.' This gives clear direction on when to use another tool, though it doesn't explicitly state exclusions or when not to use.

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?

Since no annotations are provided, the description carries the full burden. It discloses that the tool shows line movements from snapshots, interprets shortening/drift, and notes that results depend on data accumulation ('needs accumulated capture; thin → thin'). No contradictions with annotations (none provided).

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 verbose and includes unnecessary elements like a separate title line, an API response format section, and a generic JSON example for validation errors. The core functional description could be conveyed in half the length without losing meaning.

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 lack of parameter descriptions, the description is incomplete for effective tool use. It explains the concept well but does not cover how inputs control the output or what the response contains beyond generic status codes.

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 does not explain any of the three parameters (date, prop, min_move). The entire description focuses on the concept of market movers, leaving the agent without any guidance on what each parameter does or how to format inputs.

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

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

The description clearly states the resource (FanDuel line movements) and verb (how lines moved), and distinguishes itself from sibling tools by emphasizing it is market-pattern-based, not model opinion. The single sentence 'MARKET pattern (not model opinion): how FanDuel lines MOVED today' effectively communicates the purpose.

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

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

The description provides context for when to use the tool: it is described as an 'obvious opportunity signal' that is market-confirmed and independent of the model. It also warns about needing accumulated capture. However, it does not explicitly state when not to use it or name alternative tools.

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

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

No annotations are provided, so the description carries full burden. It transparently lists the data sources (MLB statsapi) and types of data returned (probable pitchers, lineup, umpire, etc.). It does not mention authorization or rate limits, but the behavior is well explained.

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 comprehensive but slightly verbose. It is well-structured with a clear first sentence, then a list of contents, followed by usage instructions and an example. Every part adds value, though it could be more concise.

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?

Without an output schema, the description should detail the return format. It lists the kinds of data but not their structure or field names. The example only shows a validation error, not a successful response, leaving agents without enough context to parse the 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 coverage is 0%, and the description does not explain the parameters. It implies 'team' is the subject and 'date' is optional (today), but does not specify format or constraints. The example only shows an error response, adding no semantic value.

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

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

The description clearly states the tool provides detailed matchup data for a team, including probable pitchers, lineup, market line, umpire, injury report, and bullpen health. It distinguishes itself from sibling tools by being the prerequisite for discussing any game or player.

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

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

Explicit instructions are given: 'Call this BEFORE naming any player or discussing a game.' It also warns not to use rosters from memory and to only use players returned by this tool, providing clear when-to-use and how-to-use guidance.

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

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

Without annotations, the description should disclose read-only nature, permissions, or potential side effects. It only states it provides a summary, not that it is a read operation or any constraints. The response section lists HTTP codes but no behavioral 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 begins with a title repeated from the tool name, then a useful sentence, but includes a verbose response section with an error example that is not relevant for success. Could be more concise and front-loaded.

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

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

Given no output schema, the description should describe the success response structure (e.g., fields, pagination). Instead, it only shows a validation error example. Missing information on data format and scope of bet history.

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 only parameter 'uid' is required but not described in the schema (0% coverage). The description implies uid identifies the user by stating 'A user's bet history', but does not explain format or source. Baseline 3 for basic implication.

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

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

The description clearly states the tool returns a user's bet history and P&L/CLV summary, specifying the resource (my bets) and action. It distinguishes from siblings by focusing on personal history and edge analysis.

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 explicit guidance on when to use this tool versus alternatives. It does not mention prerequisites, limitations, or when not to use it. Sibling tools exist for related tasks (e.g., logging, settling), but no comparison is provided.

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

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

With no annotations, the description should disclose behavioral traits. It only mentions response codes and a validation error example, but does not describe the actual data returned, authentication needs, rate limits, or 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 short but includes irrelevant boilerplate about HTTP status codes and an unhelpful validation error example. The key action is stated concisely, but the structure is not front-loaded and includes clutter.

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 lack of output schema and annotations, the description should explain what the tool returns and how to interpret it. It only gives a broad purpose, missing details on response format or usage constraints.

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 adds no meaning to the 'name' or 'season' parameters beyond 'any player'. It does not clarify what format 'name' expects or what 'season' represents.

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

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

The description clearly states it provides 'streak / splits / recent form' for a player, distinguishing it from siblings like 'betting_matchup' or 'betting_game_model'. However, the verb is implied rather than explicit (e.g., 'retrieve').

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 guidance is given on when to use this tool versus alternatives, such as when a specific type of form data is needed. No exclusions or prerequisites are mentioned.

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 provided. Description only mentions that it 'ranks by model edge (VALUE first)' and lists standard HTTP response codes. It does not disclose any side effects, authentication requirements, rate limits, or whether the tool is read-only. Minimal behavioral insight beyond the basic operation.

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 relatively short but includes unnecessary boilerplate about response codes and a generic example that does not add tool-specific value. The core functional description is front-loaded but could be more concise by omitting the generic HTTP details.

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

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

Given the tool has 6 parameters with defaults, no output schema, and no annotations, the description should provide more context about the output format, pagination, or behavior. The generic example response does not clarify what the actual response contains. Incomplete for an agent to use effectively.

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%, meaning the description provides no explanation for any of the 6 parameters (prop, coors, limit, season, min_edge, threshold). The schema defaults give some hints but not semantic meaning. The description fails to add value beyond the schema, and with low coverage, it should compensate but does not.

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

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

Description states 'Scan Edges' then 'Tonight's prop board ranked by model edge (VALUE first).' This clearly indicates the tool scans betting edges and returns them ranked by model edge value. It distinguishes from sibling tools like betting_best_bets or betting_build_parlay by focusing on the edge ranking. However, it could be more specific about which sport or time period.

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 explicit guidance on when to use this tool versus alternatives. The description does not mention conditions for use or provide comparisons to siblings. Users are left to infer its role from the context of betting 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?

Describes the purpose and the role of closing_odds in computing CLV, but does not disclose important behavioral traits such as whether settling is destructive if the bet is already settled, whether special permissions are needed, or what the successful response returns. No annotations exist, so the description carries the full burden.

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 core purpose is stated concisely, but the description includes lengthy response headers and a generic example that takes space without adding value. Not optimally front-loaded.

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

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

For a write operation with no annotations and no output schema, the description lacks critical details: success response format, safety (destructiveness), error conditions beyond validation, and idempotency. Incomplete for the complexity of the 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?

Adds meaning for 'result' (won|lost|push) and 'closing_odds' (optional, used for CLV) beyond the schema, but does not explain 'uid' or 'bet_id'. Schema description coverage is 0%, so the description partially compensates.

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

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

The description clearly states 'Settle a logged bet' and lists the required fields (uid, bet_id, result) and the optional closing_odds. It distinguishes from sibling 'betting_log_bet' by implying a different lifecycle stage, though not explicit.

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

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

No guidance on when to use this tool versus alternatives like betting_log_bet or betting_my_bets. No prerequisites or exclusions are provided.

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

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

Without annotations, the description must disclose behavioral traits. It mentions that Pinnacle only lists upcoming games, which is a constraint. However, it does not discuss read-only nature, error responses, or any side effects.

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 includes unnecessary details such as response structures and error examples, which bloat the text and detract from clarity. It could be significantly shortened to focus on the tool's purpose and parameters.

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 low schema coverage, no annotations, and no output schema, the description is incomplete. It lacks parameter semantics, error handling, and output format details, leaving the agent with insufficient information to use 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?

With 0% schema description coverage, the description should explain the parameters (team and date). It only indirectly refers to team and date via the context, but does not specify that team is required or describe the expected format of date.

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

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

The description clearly states that the tool computes a value signal by comparing FanDuel prices to Pinnacle, the sharpest book, and defines edge_vs_sharp. It distinguishes itself as providing the most reliable value signal without a model, which sets it apart from potentially similar tools.

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

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

The description explains that the tool should be used to get a reliable value signal and that no model is needed. However, it does not specify when not to use it or mention alternatives among the sibling tools (e.g., betting_scan_edges).

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

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

With no annotations, the description carries the full burden. It discloses the resolution order (live lobby first) and the fact that it layers registry strategy advice, which is useful. However, it does not mention authorization needs, rate limits, or behavior when a contest is not found (beyond a 422 response).

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

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

The description is front-loaded with the main purpose, but includes a verbose example response that is not essential for tool selection. It could be more concise by omitting the example or moving it elsewhere.

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 complexity (3 parameters, no output schema, no annotations), the description is incomplete. It does not describe the output format of the advice, return value schema, or any pagination/limits. The example only shows validation error structure.

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

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

Schema description coverage is 0%, yet the description only hints at the 'name' parameter ('concrete contest name'). It provides no additional meaning for 'sport' or 'platform', which are left entirely to the schema. This fails to compensate for the lack of schema documentation.

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

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

The description clearly states the tool provides 'advice for a concrete contest name' and specifies it resolves against the live lobby first, then applies registry strategy advice. This distinguishes it from sibling tools like list_contests. However, it could be more explicit about what the strategy advice contains.

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 for getting strategic advice on a specific contest and mentions a bug fix, but it does not explicitly state when to use this tool over alternatives (e.g., list_contests) or provide any when-not-to-use conditions.

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?

Describes key behavior: keeps leading columns (entry_id, contest_id, fee), replaces roster-slot columns, and cycles lineups if more entries than lineups. But lacks details on side effects (e.g., does it modify the original file?), return value, or error conditions beyond HTTP codes. No annotations available to supplement.

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 moderately structured with headings and paragraphs, but includes a response code section that shows example error format without explaining the successful response content, adding some redundancy. Could be more streamlined.

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?

Lacks output schema, and the description does not explicitly state what the successful response returns (e.g., filled CSV content). Only shows error response example. For a two-parameter tool, the absence of output format guidance makes it incomplete.

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

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

Schema coverage is 100% with descriptions for both parameters. The tool description adds meaningful context: 'Each lineup = upload tokens in template roster-slot order' for lineups and 'Raw CSV of the entries-template (headers + entry rows)' for template_csv, going 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?

Clearly states the tool fills a FanDuel/DK entries-template with lineups without re-running the optimizer, distinguishing it from the optimizer. It specifies the resource (template) and action (fill), and mentions it is the MCP-callable equivalent of the dashboard's fill_template.

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?

Indicates usage context when you have a downloaded template and already-generated lineups, and explicitly says 'WITHOUT re-running the optimizer.' However, it does not provide explicit when-not-to-use criteria or contrast with sibling tools like generate_lineups, leaving some ambiguity.

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 full burden. It does not disclose any behavioral traits such as whether the tool is destructive, requires authentication, has rate limits, or side effects (e.g., consumes credits). The response examples show status codes but no behavioral context.

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

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

The description is overly long with response examples that do not explain the tool's purpose. It lacks a concise, front-loaded summary. Every sentence should earn its place, but here the response formats are not useful for understanding what the tool does.

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 complex tool with 27 parameters, no output schema, and no annotations, the description is completely inadequate. It does not explain the generation process, how to interpret results, or what the lineups array contains. The agent would be left 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 96%, so the baseline is 3. The description does not add meaning beyond the schema; it only shows response examples. However, the schema itself has detailed descriptions for each parameter, so the tool is functional without extra explanation.

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 title is 'Generate Lineups' but the body only shows response examples (200, 422) without explicitly stating what the tool does. It restates the name without adding specifics. The agent can infer purpose from the name and schema, but the description itself fails to state it clearly.

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 guidance on when to use this tool vs alternatives like get_slate_players or list_presets. The description does not mention prerequisites, typical workflow, or when to avoid using it. Only response examples are provided.

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

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

No annotations provided; description lacks details on side effects, authentication needs, rate limits, or data freshness. Only response codes are listed, no behavioral traits.

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 short but includes unnecessary response format details (example error) that do not aid understanding. Could be more focused on core purpose.

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 0% parameter coverage, the description is incomplete. It does not inform the agent about the response structure or how to use parameters effectively.

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 does not explain any of the three parameters (limit, compact, slate_id). It only mentions 'for a specific slate ID' which is insufficient.

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

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

The description clearly states it retrieves the V12 player pool for a specific slate ID. The verb 'Get' and resource 'player pool' are specific and distinct from sibling tools like list_slates.

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 guidance on when to use this tool versus alternatives. It only describes the action without providing context for selection.

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

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

No annotations provided. The description does not disclose behavioral traits such as whether it is read-only, quick, or requires authentication. The example shows a successful response but no error cases.

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

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

The description is very short: one word 'Health' plus an example response. It is concise but the one-word opener adds little value. The example is well-structured.

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

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

For a simple health check with no parameters, the example response gives some context, but the description lacks explanation of response fields or potential error scenarios. It is adequate but not 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?

There are no parameters, so the schema is complete. The description adds an example response with status, version, and timestamp, which provides useful context beyond the schema.

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

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

The description only says 'Health' and provides an example response. It does not clearly state what the health check does (e.g., API health, server health) or how it differs from sibling tools like health_v12.

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 guidance on when to use this tool versus alternatives like health_v12. The description lacks context about intended use cases 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?

No annotations provided, so description carries full burden. It declares it is a monitoring endpoint requiring no auth, and lists what it surfaces. However, it does not disclose any potential side effects, caching behavior, or rate limits. Adequate for a read-only health check, but not rich.

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

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

Description is concise with bullet points for readability. The redundant 'Responses: 200' section adds minimal value and could be omitted. Overall well-structured and front-loaded.

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

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

Given zero parameters and no output schema, the description covers the tool's purpose and what data it provides. It mentions response format is JSON but does not detail structure. Complete for a simple health check, though could be more explicit.

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?

No parameters exist, and schema coverage is effectively 100%. The description adds no parameter-specific information, but none is needed. Baseline for 0 params 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?

Description clearly states it performs a 'deep health check for the V12 pipeline' and lists three specific items it surfaces (nightly regression, baseline metadata, preflight blockers). This differentiates it from sibling health tools like health_check which may be more general.

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?

Indicates no auth required and that it is a monitoring endpoint, but does not explicitly state when to use this tool over alternatives like health_check or slate_health. The context is clear but lacks exclusions or when-not-to-use guidance.

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

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

No annotations exist, so the description must cover behavioral traits. It only states the action without mentioning read-only nature, authorization needs, or what happens during listing. The response examples add no behavioral insight.

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 short but includes unnecessary HTTP response details (200, 422) that are likely auto-generated and add bulk. The core functional description is one sentence, which is concise but could be better structured.

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

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

Given the absence of output schema, annotations, and parameter descriptions, the tool definition is incomplete. It fails to explain what contest registry entries are, how parameters affect results, or what data the response contains.

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

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

The input schema defines two optional parameters (sport, platform) with defaults but no descriptions. The tool's description does not explain these parameters, their purpose, or valid values, leaving the agent without guidance. Schema description coverage is 0%.

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

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

The description clearly states the action ('list') and resource ('contest strategy registry entries'), but the term 'registry entries' is vague and doesn't fully clarify what contests are. It distinguishes from sibling tools like 'list_live_contests' only by implication.

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 guidance is provided on when to use this tool versus alternatives like 'list_live_contests' or 'list_slates'. The description does not specify context, prerequisites, or exclusions.

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

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

The description notes that identifiers are stripped ('without backend identifiers'), which adds some behavioral context. However, it doesn't disclose idempotency, side effects, or rate limits. With no annotations, the description carries the burden but provides only partial insight.

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 relatively short but includes boilerplate about HTTP responses and an example showing a validation error, which is not useful for understanding the tool's main purpose. The first sentence is concise, but the rest adds little value.

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 four optional parameters and no output schema, the description does not clarify what 'contest context' entails or how parameters affect results. The example response is misleading and doesn't reflect a successful call. The tool is incomplete for an agent to use effectively.

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 coverage is 0%, meaning the description does not explain any of the four parameters (limit, sport, compact, platform). The agent must rely solely on the parameter names and defaults, which lack explanation (e.g., what values for 'sport' or 'platform' are valid). This is a critical 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 clearly states that the tool returns the latest V12 contest context without backend identifiers, which is a specific verb+resource. However, it doesn't explicitly distinguish from the sibling tool 'list_contests', leaving ambiguity about what 'live' adds.

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 guidance is provided on when to use this tool versus alternatives like 'list_contests' or other contest-related tools. The description lacks any context about appropriate scenarios 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?

With no annotations, the description adds the behavioral trait 'No auth required' and lists the presets, but fails to disclose parameter effects or 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 bloated with detailed response status codes and an example for validation error, which is not concise and outweighs the core 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?

Despite no output schema, the description does not explain the successful response structure (only shows error example) and omits parameter details, leaving gaps for proper usage.

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

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

Schema coverage is 0% and the description does not mention the 'sport' parameter or its default, providing no additional meaning beyond the schema.

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

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

The description clearly states the verb 'List' and the resource 'the available strategy presets', and names specific preset IDs. It distinguishes from siblings as no other tool deals with presets.

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 includes a usage condition ('No auth required') but does not specify when to use this tool versus alternatives or provide exclusion 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?

With no annotations, the description carries the burden. It mentions return values (slate IDs, game counts, lock times) and response codes, but the example response is for a validation error, not the success case. The behavior of parameters like compact or playable is not disclosed.

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

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

The description is somewhat concise but includes a large, verbose example response for a 422 error that is unlikely to be helpful. The content could be more compact without the full JSON bloat.

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 5 parameters, no output schema, and 0% schema coverage, the description is insufficient. It does not describe the success response format, parameter effects, or completeness of the returned data. An agent would lack critical context to use the tool effectively.

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 the description adds no meaning to any of the 5 parameters. It does not explain what each parameter does or how to use them, leaving the agent with only the parameter names.

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

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

The description clearly states 'List available V12 slates for today' with a verb (list), resource (slates), and scope (V12, today). It distinguishes from sibling tools like list_contests or list_live_contests which refer to different resources.

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

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

The description provides no guidance on when to use this tool versus alternatives. It does not mention any exclusions, prerequisites, or hints about the context in which list_slates is appropriate.

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, and the description does not disclose behavioral traits such as side effects (e.g., data mutation via sync_supabase), required permissions, or performance implications. The description is silent on all behavioral aspects.

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 not concise: it begins with a redundant line and then includes a lengthy JSON response example that does not aid tool selection or invocation. The structure is poor as it lacks an initial summary or 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 8 parameters, no output schema, and no annotations, the description is woefully incomplete. It only provides a response example without explaining return values, error conditions, or usage context, leaving the agent uncertain about how to use the 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 63%, and the description adds no additional meaning beyond the schema. The response example does not explain parameters; the schema descriptions are the only source of information. Given moderate coverage, the description fails to compensate.

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 only provides the name 'Run Mlb Postmortem' and a large response schema example, but fails to explicitly state what the tool does. The name implies a post-game analysis, but the lack of a clear verb+resource statement leaves the purpose vague.

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

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

There is no guidance on when to use this tool versus alternatives. The description contains only a response example; no context on prerequisites, typical use cases, or exclusions is 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?

With no annotations provided, the description fully discloses behavior: it's a read-only computation, requires no authentication, and specifies exact thresholds for detecting changes. It also details the input shape and output structure, leaving no ambiguity.

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

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

The description is well-structured with sections for body shape, thresholds, and notes on auth. While relatively long, every sentence adds value. Could be slightly more concise, but content justifies length.

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 no output schema, the description fully explains the return value (structured diff with thresholds). It also provides input shape and auth notes, making the tool's usage completely unambiguous for an agent.

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

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

The input schema has no parameters (0 properties), so the description carries full burden. It provides a detailed JSON body shape with example fields (slate_id, date, sport, etc.), which adds complete semantic context beyond 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?

The description clearly states the tool's purpose: 'Compute what changed since a previously-stored snapshot.' This is a specific verb+resource combination that distinguishes it from sibling tools like slate_health or get_slate_players.

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

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

The description explicitly notes 'No auth required — read-only computation', providing clear context for when to use it. It also details thresholds for what constitutes a change, but lacks explicit guidance on when not to use it or alternatives.

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

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

With no annotations, the description carries full weight. It discloses that the tool checks specific data pillars, that game coverage is null when only date is provided, and includes response status codes. It could mention that it does not modify state, but the pre-flight nature implies read-only. The description adds significant transparency beyond 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 description is well-structured with sections but somewhat verbose. The example response and repeated requirement statement add length; tightening would improve clarity without losing essential detail.

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 6 parameters, no output schema, and 12 siblings, the description covers the core purpose and key parameter behaviors. However, it lacks details on 'include_snapshot' and 'last_known_fingerprint' and does not fully define the return structure. Adequate but not comprehensive.

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

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

Schema coverage is 0%, so description must compensate. It explains the relationship between 'slate_id' and 'date' and their differing output. However, it omits details for the other four parameters ('site', 'sport', 'include_snapshot', 'last_known_fingerprint'), leaving ambiguity. Partial compensation but not fully sufficient.

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

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

The description clearly states it is a 'Pre-flight diagnostic for a slate' that 'returns whether odds, projections, matchup, and FD master-session are ready' before another specific tool invocation. This verb-resource pair is precise and distinguishes it from siblings like 'health_check' or 'list_slates'.

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

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

The description explicitly advises use 'BEFORE the agent invokes /v1/generate' and clarifies the conditional requiredness of 'slate_id' or 'date' with behavioral differences. It does not list when not to use, but the context is clear and helpful for an AI agent.

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

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

With no annotations, the description carries full burden. It discloses this is a write operation, requires specific auth, costs API calls, and returns a summary dict. This provides sufficient behavioral transparency, though it does not mention potential side effects like overwriting existing 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?

The description is structured with clear sections (auth, cost, responses) but includes a verbose example response that is generic and not specific to the tool. It could be more concise by removing the unnecessary example and focusing on tool-specific details.

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

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

The description covers behavior, auth, cost, and output fields, but lacks parameter details. Given the tool has 3 parameters and no output schema, the description partially fulfills completeness, but the missing parameter guidance is a notable 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?

The input schema has 0% description coverage, and the description only mentions 'date' generically, with no explanation for 'site' or 'sport' parameters or their defaults. This forces the agent to rely on parameter names alone, which is insufficient for correct invocation.

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

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

The description clearly states the tool 'Re-fetch projections + odds + slate metadata for a date,' specifying the verb and resource. It distinguishes from siblings like 'slate_diff' and 'list_slates' by indicating its action is updating/refreshing data.

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 mentions auth requirements and cost (API calls), but does not provide explicit guidance on when to use this tool versus alternatives like 'slate_health' or 'slate_diff'. Usage context is implied but not directly stated.

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