v12-dfs

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

With no annotations, the description fully covers behavior: idempotent key issuing, reuse of existing keys, optional rotation that revokes and mints new keys, and admin gating. No contradictions.

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 well-structured with sections, but includes example responses which add length. Generally concise given the complexity, though could be slightly trimmed.

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 includes response format and examples, covering main points. Lacks details on error conditions beyond validation, but adequate for the tool type.

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 33%, only 'rotate' has a description. Description adds context for rotate behavior but does not explain 'tier' values beyond the regex pattern. It adds some value but insufficiently compensates for low coverage.

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 issues API keys idempotently and returns a connect block. It distinguishes itself from sibling tools (mostly betting-related) as an admin function. The verb 'issue' and resource 'API key' are specific.

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

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

The description provides context that it is admin-gated and used server-side, but does not explicitly state when to use vs. alternatives or when not to use it. Given siblings are unrelated, a 3 is appropriate for implied usage.

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 burden. It discloses that no authentication is required, returns a placeholder key (not a real key), and lists response contents. However, it does not mention error handling, idempotency, or potential prerequisites beyond the key issuance note. Overall adequate for a simple read-only config tool.

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

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

The description is front-loaded with the main purpose, but includes a redundant 'Responses' section that merely states '200: Successful Response' and 'Content-Type: application/json', which adds no value. This verbosity could be trimmed 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 zero parameters and no output schema, the description provides sufficient context: what the tool does, what it returns (config with placeholder key, endpoint map, generate body fields), and an operational note about key management. It covers the essential aspects for an agent to decide to use it.

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

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

The input schema has zero parameters, so the baseline is 4. The description adds no parameter specifics because none exist, and it does not need to compensate for missing schema detail since the schema is fully covered.

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 an agent to the V12 motor, returning copy-paste MCP and REST config. It differentiates from siblings like 'betting_agent_guide' by specifying it is for connecting any agent rather than a betting-specific agent.

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 initial setup ('Self-serve onboarding') and mentions an operational follow-up ('issue each user their OWN key via POST /v1/admin/create-key'), but does not explicitly state when to use this tool vs alternatives or provide exclusions. The guidance is implicit, not clear.

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

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

No annotations are provided, so the description carries full burden. It only notes a 200 response with JSON, but fails to disclose that the tool is read-only, has no side effects, or what the guide content entails. Behavioral traits are underdescribed.

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 concise, consisting of two short sentences and a response note. It is front-loaded with the title and purpose. However, it could be slightly more structured (e.g., separating sections 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 tool is a guide with no parameters and no output schema, the description is minimally adequate. It states its purpose and response format. However, it does not explain what the guide includes or how to interpret it, which is important for a documentation tool.

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

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

With zero parameters and 100% schema description coverage, the baseline is 4. The description adds no parameter info because none exist, which is acceptable. No further elaboration is needed.

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 guide for using MLB betting tools and reading output. It distinguishes itself from sibling tools which are operational (e.g., betting_game_lines, betting_best_bets). However, it could be more explicit that it returns static documentation rather than performing an action.

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

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

The description mentions the guide is for agents, but does not specify when to use this tool vs alternatives. No context like 'use first to understand the system' or exclusions for when not to use it. Sibling tools include many similar betting tools, but no selection guidance is provided.

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

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

With no annotations, the description carries full burden. It does not disclose if the tool mutates data, requires authentication, or has side effects. The response format is standard and adds 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 opening line is clear, but the inclusion of response status codes and an example response adds length without aiding tool selection. It is adequately structured but not maximally 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 4 parameters, no output schema, and 26 sibling tools, the description is incomplete. It fails to explain parameter usage, edge computation, or selection criteria relative to similar tools.

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 provides no explanation for 'name', 'prop', 'season', or 'threshold'. The agent cannot infer parameter semantics without additional knowledge.

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 a single player's prop against a FanDuel line to compute an edge. It distinguishes from siblings like 'betting_scan_edges' and 'betting_best_bets' by focusing on a single player prop.

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 is provided on when to use this tool versus alternatives. It does not mention exclusions or prerequisites, leaving the agent to infer usage from the brief purpose statement.

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, description provides some behavioral context (e.g., scans all markets, power props have Savant validation, screen vs vig line) but lacks details on destructive potential, authentication, or rate limits. Adequate but not exhaustive.

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

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

Description is somewhat verbose with boilerplate response codes and an example that is not tool-specific. Main purpose is front-loaded but includes unnecessary formatting. 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 2 default parameters and no output schema, the description explains the tool's scope and alternative tools well, but missing parameter documentation and output expectations leaves gaps for effective use.

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 does not explain the 'limit' and 'min_edge' parameters or how they affect results. Completely fails to compensate for schema's lack of param info.

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 scans all main prop markets in one call and returns top edges, distinguishing it from single-market scans and mentioning sibling tools (betting_sharp, betting_game_model) for separate use cases.

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

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

Explicit guidance: 'Use this for an open what's hot / best plays / what do you recommend tonight' and explicitly excludes game-side value, directing to siblings. Clear when to use and when not to.

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

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

With no annotations provided, the description fully carries the burden. It discloses determinism, de-vigged market pricing, fallback behavior, independence assumptions, correlation warnings, ticket odds verification, mismatch flags, and caution not to trust misread slips — detailed and actionable beyond any annotation.

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 content is dense and front-loaded, with no filler, but the appended 'Responses' section and Example Response repeat generic OpenAPI boilerplate rather than adding useful behavioral detail. Still, every substantive sentence earns its place.

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

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

For a complex tool with two leg shapes, multiple game markets, pricing logic, and validation edge cases, the description explains input structure, input semantics, behavioral assumptions, warnings, and output dimensions (payout, breakeven, fair prob, EV). No output schema is provided, yet the description still covers the essential return values.

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%, but the description compensates richly. It explains the body shape, both leg shapes, the role of ticket_odds, what american_odds means, which markets are allowed, and how prices are used. This goes far beyond the raw schema.

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

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

The description states a specific verb+resource: 'Build Parlay' — deterministic parlay analysis for both leg shapes. It clearly differentiates from siblings by framing this as the math endpoint for parlay construction, not a general betting analysis 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?

It gives strong context for when to use it: users paste slips, legs need pricing, or a parlay must be evaluated. It implies 'this endpoint is the math' and warns not to estimate in prose, but it does not explicitly list alternatives or exclusions compared to siblings like betting_scan_edges or betting_best_bets.

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 must fully convey behavioral traits. It does not explain what the tool returns, whether it performs side effects, requires authentication, or has rate limits. It mentions 'CONFIRMED edges' and 'no model needed' but does not describe the actual behavior or output of the tool.

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

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

The description includes unnecessary boilerplate about HTTP status codes and an example validation error, which inflates length without adding value for an AI agent. The first sentence 'Cross Book' is not informative. The description is unstructured and does not front-load key information.

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

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

Given no output schema and no annotations, the description is incomplete. It does not explain what the tool returns, how to interpret the cross-book value, or how to use the response. The mention of 'LINE_SHOP' and 'PRICE_SHOP' is unexplained, leaving the agent without necessary context 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?

Schema description coverage is 0% and the description does not explain the single parameter 'prop' (default 'pitcher_strikeouts'). The description mentions 'pitcher_strikeouts' in context but does not clarify that it is the parameter, nor what values it accepts or how it affects results. The parameter is left completely undocumented.

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

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

The description states 'Cross Book' and mentions 'cross-book value' but lacks a clear verb indicating what the tool does (e.g., 'get', 'calculate', 'list'). It implies it provides information about edges between books but the action is ambiguous. The title is null and the description does not specify a distinct resource or operation.

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

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

The description gives no explicit guidance on when to use this tool versus its many betting-related siblings like betting_scan_edges or betting_best_bets. It mentions arbitrage is not auto-reported but fails to clarify scenarios where cross-book is preferred. No exclusions or alternatives 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?

With no annotations provided, the description discloses that data comes from ESPN's public scoreboard as-is, that V12 has no game-outcome model, and that lines are the book's own number (never fabricated). It also warns about null fields and advises not to invent lines.

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 lengthy and includes a verbose response section with an example 422 response that adds little value. The main functional description is clear but 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?

Given that there is no output schema and no annotations, the description covers purpose, data source, behavior with nulls, and one parameter. However, it omits explanation of the date parameter and does not describe the response structure beyond HTTP 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?

The schema has two parameters (date, team) with 0% description coverage. The description only explains the team filter with examples like 'Yankees' and 'NYY', but does not explain the date parameter at all, leaving a significant 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 it provides MLB game lines (moneyline, run total, run line) and answers specific Spanish queries like 'quién gana' and 'cuántas carreras'. It distinguishes from sibling tools by noting that player props cannot answer these questions and that V12 used to refuse them.

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

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

It explicitly says when to use this tool (for game-level markets, not player props) and provides guidance on handling null fields when a book hasn't posted a game. However, it does not directly address alternatives among sibling tools like betting_market or betting_matchup.

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?

There are no annotations, so the description carries the burden, and it is unusually detailed: it discloses the anchoring formula, de-vigged fair-probability semantics, the role of structural inputs, and the anchored=false / edge=null behavior. It only falls short of a 5 by not explicitly describing read-only behavior, response shape, 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?

Most of the content is dense and useful, but the description leads with a formula and heavy methodology before basics, and the Responses section is only generic error content with no success example. It is organized enough to navigate, but not front-loaded around the call itself.

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

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

There is no output schema and no meaningful success response example, and the description makes no attempt to define the return fields beyond edge=null and expected_runs. For a domain-specific, formula-heavy tool, an agent still can't fully predict what a valid call returns and how to consume it.

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

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

Schema description coverage is 0%, and the description adds nothing about the actual arguments — team or date. No format, date scope, identifier type, or example is given; the 'structural inputs' it mentions are internal model inputs, not the caller-provided parameters.

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

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

The description names a specific verb and resource: 'MODEL the GAME run markets — TEAM TOTALS (over/under) and NRFI/YRFI — vs the FanDuel line'. It also explicitly separates itself from betting_market via 'For raw lines on every market use betting_market', so an agent can reliably distinguish it from close siblings.

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

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

There is an explicit routing instruction to betting_market for raw lines, and the 'screen vs market, not a lock — validate with CLV' caveats help an agent understand how the result should be treated. However, it does not fully explain when to choose this over other model-adjacent siblings such as betting_game_lines, betting_analyze_prop, or betting_matchup.

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 discloses 'append-only' and the purpose of proving edge, but lacks details on auth requirements, idempotency, or confirmation of success. The example response only shows an error schema, not a success payload.

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 fairly concise, front-loading the purpose and listing parameters. The response code and example add some bulk but are relevant. Could be tighter by removing the generic example or merging the body list.

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

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

Given 10 parameters and no output schema, the description is incomplete. It fails to explain return values for successful calls, leaving the agent without confirmation of what the response contains. Additional detail on each parameter's semantics is also missing.

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

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

Schema coverage is 0%, so the description must compensate. It lists required/optional params and notes odds are American, but does not explain the meaning of fields like 'market' or 'selection'. This adds moderate value but leaves gaps.

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 logs a bet per user to track P&L and CLV, using specific verbs and resources. It distinguishes from siblings like 'betting_my_bets' (listing) and 'betting_settle_bet' (settling) by its write-only nature.

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

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

It provides context (append-only, evidence base) and lists the fields, implying when to use. However, it does not explicitly state when not to use or mention sibling alternatives, though the verb 'log' itself provides some differentiation.

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 discloses that it returns real odds and de-vig fair price, and that the market is as-is (no model). This adds behavioral context 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?

Description is informative but somewhat wordy, listing many market types. Includes response codes and example response which is not essential. 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 the complexity of a full market board, the description provides a comprehensive list of market types. Lacks parameter descriptions, but the purpose is well covered.

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%. Description mentions 'team's game' but does not explicitly describe the 'team' or 'date' parameters. No additional meaning beyond 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?

Description uses specific verb 'returns' and resource 'full FanDuel market board for a team's game', listing many market types. Distinguishes from siblings by stating it covers all markets and suggesting betting_analyze_prop for model edge.

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

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

Explicitly states when to use this tool for any market question and directs to betting_analyze_prop for model edge on props. Could be more explicit about not using it for just game lines (use betting_game_lines instead).

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

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

No annotations are provided, so description must disclose behavior. It explains that moves are derived from captured snapshots and their meaning, but does not state if the operation is read-only, required permissions, rate limits, or pagination. Adequate but not exhaustive for a data retrieval tool.

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

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

Core description is relatively concise, but the inclusion of a full '### Responses:' section with HTTP statuses and a JSON error example adds unnecessary length and detracts from focus. It is front-loaded with the key concept but could be trimmed.

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, no output schema, and 0% parameter coverage, the description lacks critical information: output structure, filtering options, and error handling. It explains the concept well but leaves the agent guessing on how to effectively use the tool among many similar siblings.

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

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

Schema coverage is 0% with three parameters (date, prop, min_move). Description does not explain any parameter meaning or usage. Agent receives no guidance on how to use these parameters, making it difficult to invoke correctly.

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 returns market moves of FanDuel lines today, explaining the direction of moves (shortening = money in, drift = money off). It distinguishes itself from model opinions, which differentiates it from sibling tools like betting_sharp or betting_game_model.

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

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

Provides context that this is the 'obvious opportunity' signal market-confirmed and independent of model, and warns that 'needs accumulated capture; thin → thin.' This implies when to use (for market-based signals) and limitations (need sufficient data). Does not explicitly exclude alternatives but gives clear usage context.

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

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

With no annotations provided, the description carries full burden for behavioral transparency. It details what data is returned (probable pitchers, lineup, market line, umpire, injury report, bullpen health) and includes important usage behavior (must be called first, only use returned players). It does not mention side effects or authentication, but the provided context is strong.

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 lengthy and includes verbose emphasis (CAPS) and a generic error response example that is not helpful for successful calls. While it packs essential context, it could be more concise and front-loaded. The structure includes separate sections but some content is redundant.

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, output schema, or param descriptions, the description covers the tool's purpose and usage well but lacks details on the output format (only an error example) and does not explain parameter usage. It is partially complete but missing critical information for an agent to fully understand the tool's behavior and 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?

The input schema has two parameters (team required, date optional). The description does not explain these parameters; it mentions 'a team today' but does not clarify the date parameter or how to specify teams. With schema description coverage at 0%, the description fails to add meaning to the parameters beyond what the schema provides, missing key details like possible values or format.

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 matchup data for a team's real game today, including probable pitchers, lineup, market line, umpire, injury report, and bullpen health. It distinguishes itself by specifying its grounding in actual data and the directive to call before mentioning players, differentiating it from sibling tools like betting_game_lines or betting_market.

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 instructs when to use the tool: 'Call this BEFORE naming any player or discussing a game.' It also warns against using roster memory and states to 'Name ONLY the players this returns'. This provides clear guidance on when and how to use it versus 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?

No annotations provided, so description must disclose behavioral traits. It explains that the tool returns a summary of bets with P&L and CLV, and adds an interpretive note about avg_clv_pct. However, it does not explicitly state that it is a read-only operation, nor does it discuss authentication, rate limits, or side effects. The response code section is boilerplate and does not add 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 core description is concise and front-loaded with the purpose. The inclusion of response code examples and a large error response JSON adds some clutter that could be omitted as standard boilerplate, but the overall structure is clear and efficient.

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 an output schema, the description should fully explain what the tool returns. It mentions 'bet history + P&L / CLV summary' but does not detail the fields, structure, or pagination. The error example provides no insight into the success response. The tool is therefore incomplete for understanding the exact 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?

The input schema has one required parameter 'uid' with no description, and the tool description does not mention it at all. Schema description coverage is 0%, and the description fails to add any meaning about what 'uid' represents (likely user ID) or its constraints.

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 a user's bet history with P&L and CLV summary, and provides interpretive context about avg_clv_pct indicating edge. It effectively distinguishes this from other betting tools like betting_log_bet (write operation) and betting_analyze_prop (analysis). However, it could be more precise about what data is returned (e.g., fields, format).

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 implies it's for checking a user's own betting history and performance, but does not mention when not to use it or suggest other tools for specific needs (e.g., for market lines or sharp ratings).

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 the description must carry the full burden. It only states it returns form data but does not discuss permissions, read-only nature, rate limits, or other 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 cluttered with HTTP response codes and a validation error example that does not illustrate a successful response. It is not front-loaded and contains unnecessary 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 the simplicity (2 params, no output schema), the description should at least outline the return fields. It only mentions 'Success Response' without specifics, leaving the agent uncertain about the response structure.

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

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

Schema coverage is 0% and the description does not explain the 'name' or 'season' parameters. The word 'player' hints at 'name' but does not clarify usage or format.

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

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

The description states 'Streak / splits / recent form for any player', which clearly indicates the tool retrieves player form data. However, it is mixed with response codes and a generic example, slightly reducing clarity.

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 betting_matchup or betting_game_model. The description does not mention when to prefer this tool or any exclusions.

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

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

With no annotations, the description must fully disclose behavior. It mentions ranking by edge but does not state whether the tool is read-only, requires authentication, or has any side effects. The inclusion of HTTP response codes provides minimal API structure detail but 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 core description is a single phrase, but it is followed by an unnecessary copy of HTTP response codes and an example that does not add value for the agent. The real content is front-loaded but wasted space makes it less concise than it could be.

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 no annotations, the description is grossly incomplete. It fails to explain parameter meanings, return format, pagination, or any usage context, leaving the agent with little to work with.

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% (no parameter descriptions in schema). The description does not explain any of the 6 parameters (prop, coors, limit, season, min_edge, threshold) beyond noting 'edge' in the summary. This is insufficient for an agent to use parameters correctly.

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

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

The description states the tool scans the prop board and ranks by model edge, with VALUE first. This gives a clear verb (scan) and resource (prop board edges), but it does not distinguish from sibling tools like betting_analyze_prop or betting_best_bets, and the phrase 'Tonight's prop board' may conflict with the season parameter.

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. The description lacks any when-to-use, when-not-to-use, or prerequisite information.

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 explains that closing_odds computes CLV and lists response types, but does not disclose effects on bet state, irreversibility, or permissions.

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 structured with body details and response info, but includes a lengthy example response that could be omitted. Not optimally 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?

Covers required and optional parameters and response types, but lacks details on side effects, idempotency, or error conditions beyond validation errors.

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%. Description clarifies result values ('won|lost|push') and purpose of closing_odds, but uid and bet_id are left to schema alone.

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?

Title 'Settle Bet' and description 'Settle a logged bet' clearly state the action and resource. Distinguishes from sibling tools like 'betting_log_bet' and 'betting_my_bets'.

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 or prerequisites. Only implies that bet must be logged first.

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?

Discloses behavioral traits such as data availability (upcoming games only), the calculation methodology, and possible response codes (200, 422). With no annotations, this covers key aspects, though lacks discussion of idempotency or rate limits.

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

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

The description contains relevant information but is verbose with a full example response and unclear phrase 'Plus total line-shop.' Could be streamlined for 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?

Explains the core concept and response codes, but lacks a clear description of the output structure. Without an output schema, more detail on the return value fields is needed for 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 description does not explain the 'team' and 'date' parameters despite 0% schema coverage. No guidance on valid values or how they affect results, 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 identifies the tool as computing a sharp value signal by comparing FanDuel vs Pinnacle, with an explicit formula for edge calculation. It distinguishes itself from siblings like betting_scan_edges by emphasizing reliability and no-model-needed nature.

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

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

Provides strong usage context: when to use (most reliable value signal, no model needed) and data freshness constraint (Pinnacle only lists upcoming games). Does not explicitly exclude alternatives or compare to siblings.

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

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

No annotations are provided, so the description carries the full burden. It explains the resolution order (live lobby first, then registry) and mentions response codes (200, 422). The tool is advisory and read-only, so side effects are not a concern. The behavioral description is detailed enough for an agent to understand the process.

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 sized with a clear title, a paragraph explaining the process, and a response section. It is well-structured and front-loaded with the purpose. The bug fix story adds valuable context but is slightly 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?

The description adequately explains the core functionality (advice for contest names) and the resolution logic. However, it lacks explanation of the sport and platform parameters, and the return format is only partially illustrated (example response is a validation error). Without output schema, more detail on the advice content would be beneficial.

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%. The description only implies the 'name' parameter is a contest name, but does not explain 'sport' or 'platform' (though they have defaults). This is insufficient for an agent to use these parameters correctly without guessing.

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' with a specific two-step process (resolve against live lobby then layer registry advice). This distinguishes it from sibling tools like list_contests or list_live_contests which only list contests without providing strategic advice.

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

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

The description gives clear context on when to use the tool: when you have a contest name and want advice, including a note about the bug fix. However, it does not explicitly state when not to use it or provide alternatives, though the sibling list context is available.

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 VIP-only access, the source data (owner's P&L), and response status codes, but does not describe the success response format or any side effects. This is moderate but insufficient for full transparency.

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 opening repeats the tool name, and the response section contains generic boilerplate. The core explanation is concise, but some parts add little value. Overall, it is adequately structured but not front-loaded efficiently.

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

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

With no output schema and no parameter explanations, the description leaves the agent guessing at input semantics and response format. The internal file reference 'core/data/contest_semaforo' is not actionable for an AI agent, making the description incomplete for a tool with this complexity.

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

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

The description does not mention any of the three parameters (limit, sport, platform). With 0% schema description coverage, the agent has no semantic guidance for choosing parameter values, making this dimension critically weak.

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

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

The description states it provides a per-contest play/skip verdict based on P&L bands, structure gates, and rake/fill math, which is a specific action on a specific resource. However, it does not explicitly distinguish from sibling tools like contest_advice, and the jargon may obscure clarity for an agent.

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 contest_advice or list_contests. The 'VIP-only' note is an access restriction, not a usage guideline.

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

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

With no annotations provided, the description carries full burden and delivers: it discloses the tool is non-destructive (fills template without re-running optimizer), details the specific column manipulation, explains lineup cycling behavior for excess entry rows, and includes response codes (200, 422) with an example. This fully informs the agent of 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 well-structured with a clear title, a concise purpose statement, and a bullet-like list of behavioral details. It includes a response example, which adds some length but is helpful. Overall, it is front-loaded and efficient, though the example could be slightly trimmed.

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 adequately covers the tool's behavior, parameters, and potential responses. It explains the input format (CSV with headers), the transformation logic, and error handling (422). Minor gaps exist regarding malformed input or specific validation, but overall it is complete for a tool with two well-documented parameters.

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

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

Schema description coverage is 100%, but the description adds value by explaining the process context: 'keeps each entry row's leading columns... and replaces the roster-slot columns with a lineup's upload tokens'. This clarifies the relationship between the parameters and the expected transformation, going beyond the schema descriptions alone.

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 specifies the tool's purpose: 'Fill a downloaded FanDuel/DK entries-template with already-generated lineups WITHOUT re-running the optimizer.' It clearly distinguishes from the sibling tool 'generate_lineups' by explicitly stating it avoids re-running the optimizer, and it positions itself as 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?

The description explains when to use the tool: after lineups have been generated, to fill a template without re-optimizing. It details what the tool does (keep leading columns, replace roster-slot columns, cycle lineups). While it does not explicitly name alternatives or state when not to use, the context of the sibling tools and the instruction to use after generation provides adequate 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?

Even though no annotations are provided, the description reveals valuable behavioral context through parameter documentation: plan_only does NOT run the optimizer and costs 0 credits, allow_locked controls the replay/late-swap override, refresh_data notes backtests should set false, and contest_fallback explains failure modes and fail-closed behavior. This gives the agent meaningful operational awareness beyond the name and schema. However, the core description does not explicitly state that generate_lineups can be expensive or that it may make external API calls.

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 dominated by a large response-example block that repeats schema-like fields ('Status', 'Generated At', 'warnings', etc.) without explaining actual response semantics. The useful behavior notes are buried inside parameter descriptions rather than in a concise overview. The core summary is only the two-word phrase 'Generate Lineups', which is under-specified and not front-loaded with operational guidance.

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 32-parameter tool with no annotations and no output schema, the description is incomplete: it does not explain the returned lineup structure, credit costs, required data prerequisites (e.g., needing a valid slate), or error handling beyond a generic 422 example. The parameter descriptions and plan_only flow help, but the description itself lacks a coherent narrative tying the operation together. The rich schema compensates somewhat, so it is not a 2, but it is far from complete.

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

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

Schema description coverage is 97%, so the schema already documents almost every parameter thoroughly. The description adds some value through its plan_only, contest_fallback, and refresh_data notes, but most of the parameter meaning is already present in the input schema. The response examples are not parameter documentation, and some descriptions are copied from schema rather than enriched.

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 'Generate Lineups' is clear about the verb and resource, and the description context plus parameter hints (slate date, sport, strategy, exposures) make it evident this generates DFS lineups. However, it does not explicitly distinguish itself from sibling tools like get_slate_players or fill_template, and the description itself is mostly response examples rather than a clear statement of what the tool does.

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

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

The description does not explicitly state when to use this tool vs alternatives, but the parameter hints (e.g., slate_id, contest_id, plan_only) imply it is the main lineup generation endpoint. It lacks guidance on when to prefer other tools such as list_slates, scout_field, or plan_only for review. The plan_only parameter does provide a clear 'use this to preview before spending credits' cue, which is helpful.

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 must disclose behavioral traits. It only implies a read operation via 'Get,' but does not confirm safety, idempotency, required permissions, or any side effects. The response codes listed are standard HTTP statuses and 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 includes extraneous details such as HTTP status codes and a generic error response example that is not tool-specific. This filler takes space that could be used for more relevant guidance, violating the principle that every sentence should earn its place.

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

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

The tool has no output schema, no annotations, and low schema coverage. The description does not describe the return structure (e.g., fields, pagination) or any side effects, leaving the agent with insufficient information 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?

The input schema has 3 parameters with 0% description coverage. The description does not explain 'slate_id', 'limit', or 'compact' beyond the schema definitions, leaving their meaning and usage entirely to the agent's inference.

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

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

The description states the tool retrieves the 'V12 player pool for a specific slate ID,' which identifies the action and resource. However, it does not differentiate this tool from siblings like 'list_slates' or 'slate_diff,' and the term 'player pool' is vague without further context.

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 other sibling tools (e.g., list_slates, slate_health). There is no mention of prerequisites, when-not-to-use, 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?

No annotations exist, and the description offers minimal behavioral disclosure. It implies a read-only status check via the response example, but does not confirm idempotency, side effects, or required permissions.

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 contains unnecessary formatting with markdown code fences. It could be expressed more succinctly, for example: 'Returns health status including version and timestamp.'

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

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

For a parameterless tool, the description is minimally adequate but lacks context. It does not explain the meaning of status values or when this health check differs from sibling tools like 'health_v12'. An example response is provided, but no further details.

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 fully covered. The description adds a response example showing fields like status, version, and timestamp, which provides some context about what the tool returns, but it is not detailed enough to fully compensate for the lack of output 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 is extremely vague, stating only 'Health'. It does not specify the verb or resource, but the response example suggests it checks service health. This is barely informative and does not distinguish from sibling tools like 'health_v12' or 'slate_health'.

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 usage guidelines are provided. The description does not indicate when to use this tool versus alternatives, nor does it give any context about prerequisites or 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?

Without annotations, the description discloses that it's a read-only monitoring endpoint with no auth, and lists specific data returned. No destructive behavior mentioned, which is appropriate for a health check.

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 brief and well-structured: purpose first, then bullet-like listing of outputs, then auth note. Every sentence adds value, no 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?

Given zero parameters and no output schema, the description sufficiently explains the tool's behavior and return content (200 response with JSON including regression, baseline, blockers). Complete for a health check.

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 100%, so the description adds no param info. Baseline 4 is appropriate as there's nothing missing.

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, listing specific outputs (last nightly regression, baseline metadata, preflight blockers). This distinguishes it from sibling tools like health_check or slate_health.

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 no auth required and that it's a monitoring endpoint, implying usage for health monitoring. Could mention when to use V12-specific vs. general health check, but context is clear.

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

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

No annotations are provided, so the description carries full burden. It includes an example error response but does not disclose read-only nature, authentication needs, pagination, or response structure for successful calls.

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 has a header and response section but includes a long example error response that may be unnecessary. Could be more concise while covering missing details.

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

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

For a tool with no annotations, no output schema, and 0% param coverage, the description is incomplete. It fails to explain what the tool returns, how to filter, or any behavioral 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?

With 0% schema description coverage, the description must explain parameters but completely omits any mention of sport or platform. Their defaults (MLB, fd) are present in schema but not explained.

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 specifies 'List contest strategy registry entries' providing a clear verb and resource. It distinguishes itself from sibling 'list_live_contests' but does not clarify exactly what 'strategy registry entries' are.

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 'list_live_contests'. Does not state prerequisites or recommended contexts.

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

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

With no annotations, the description carries the behavioral burden. It discloses that backend identifiers are excluded and lists response codes 200 and 422, but it does not describe the success response structure, side effects, or how parameters influence behavior. The example response shown is actually a 422 validation error, which is misleading rather than transparent.

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 sentence is concise, but the description is padded with a response section that focuses on an error example rather than a successful response. The 'Live Contests' heading is redundant with the tool name. The structure does not prioritize the most useful information.

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

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

For a tool with four optional parameters, no annotations, and no output schema, this description is incomplete. It lacks parameter semantics, a success payload example, and usage context; an agent would struggle to know what 'contest context' means, what each parameter does, or how to interpret the return value.

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 does not mention any of the four parameters (limit, sport, compact, platform). It provides no meaning, examples, or constraints beyond the raw schema defaults, leaving an agent without the information needed to set these parameters appropriately.

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

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

The description states a specific action and resource: 'Return latest V12 contest context without backend identifiers.' This clearly identifies what the tool does. It is somewhat differentiated from the sibling 'list_contests' by the emphasis on 'latest V12' and 'without backend identifiers,' though it does not explicitly name the contrast.

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 like list_contests or list_slates. The phrase 'live' and 'latest' implies current contests, but there are no explicit context cues, exclusions, or comparisons to sibling tools.

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

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

No annotations are provided, so the description carries the burden. It states "No auth required" and implies a read-only operation (listing presets), but does not disclose rate limits, data freshness, or any behavioral traits 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 somewhat verbose, including a full response example for a 422 error and a vague success response. The core information (listing presets, no auth) could be conveyed more succinctly. Front-loading is decent.

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 one optional parameter and no output schema, the description should explain the parameter and the response structure (e.g., what configurations are returned). It lists preset names but omits details on the response format beyond a placeholder success response. The example provided is for an error case, not the primary use case.

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 single optional parameter "sport" (default "nba"). The description lists preset names but gives no context on how or when to use the parameter, failing to add value beyond the schema.

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

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

The title "Get Presets" and description clearly state the tool lists available strategy presets with configurations. It is distinct from sibling tools which focus on betting, slates, or administration, though it does not explicitly differentiate from similar list tools.

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

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

No guidance on when to use this tool versus alternatives. The only usage hint is "No auth required," which is helpful but insufficient for deciding between this and other 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 the full burden. It implies a read-only operation (list/GET) and mentions response codes, but does not explicitly state that it is read-only or non-destructive. The example response shown is for an error case, not the successful 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 moderately concise but includes a large JSON example that is only for an error response, which is not the primary use case. The structure with response sections is helpful but 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?

While the description notes the return values (slate IDs, game counts, lock times), it omits important context such as pagination, limit behavior, or the meaning of parameters. With no output schema, more detail on the response structure would be beneficial.

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 provides no explanation for any of the 5 parameters (site, limit, sport, compact, playable). This leaves the agent unable to understand parameter semantics from the description.

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 lists available V12 slates for today and returns slate IDs, game counts, and lock times. This is a specific verb+resource combination. However, it does not explicitly distinguish itself from sibling tools like list_contests 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?

No guidance is provided on when to use this tool versus alternatives. There is no mention of prerequisites, context, or use cases.

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. The response structure suggests a read operation (e.g., 'generated_at', 'results'), but there is no explicit statement of safety, side effects, or required permissions. The description fails to disclose 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 is dominated by verbose JSON response examples that do not help an agent understand tool purpose. The actual useful content is limited to the first line. Better structure would front-load a brief functional summary.

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 8 parameters, no output schema, and no annotations, the description is severely lacking. It does not explain expected inputs, outputs, or operational context. The tool likely involves complex postmortem analysis, but no such detail is provided.

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 description does not mention any parameters or add meaning beyond the input schema. With 63% schema coverage, baseline would be 3 if the description contributed, but it adds nothing. The response examples do not clarify parameter usage.

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 repeats the tool name 'Run Mlb Postmortem' but provides no definition of what a postmortem entails. It lists response fields like 'status' and 'entries' but does not explain the tool's core function or how it differs from siblings like 'betting_matchup' or 'generate_lineups'.

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 vs alternatives. There is no mention of prerequisites, context, or exclusions. The description solely consists of API response examples, which are irrelevant for decision-making.

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

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

With no annotations, the description carries the full transparency burden and succeeds by disclosing VIP-only access, data sourcing from harvested fields, a fallback snapshot to prevent 500s, and fail-closed allowlist behavior. It also lists what fields are returned, though it omits any rate limits or side-effect information.

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 description is moderately concise and front-loaded with the purpose and access restriction. However, the included 'Responses' section with a 422 validation error example is boilerplate that adds little value for an agent, making the overall structure slightly cluttered.

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

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

For a tool with no output schema and two undocumented parameters, the description gives a strong sense of the return content but misses essential invocation details. It does not clarify how contest and min_days affect the response, nor does it provide a complete result structure, leaving an agent uncertain about expected inputs and outputs.

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 does not explain the two parameters (contest, min_days) at all. The mention of 'days seen' is insufficient to infer that min_days filters the results, and contest is never tied to the contest selection. The description fails to compensate for the schema's lack of parameter 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 identifies scout_field as returning opponent-scouting fingerprint profiles for a specific single-entry band, with explicit details like days seen, avg score, chalkiness, and favorite pitchers/bats. It uses the verb 'returns' and describes a unique resource, though it does not explicitly contrast with sibling tools beyond referencing the semaforo allowlist.

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 context is implied through the VIP-only restriction and the specific scenario of the owner's $65 table, but there is no explicit guidance on when to use this tool versus alternatives like contest_semaforo or generate_lineups. The fail-closed allowlist is mentioned but not framed as a decision rule.

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?

Despite no annotations, the description explicitly states it requires no authentication, is read-only, and operates on in-memory snapshots. It details detection thresholds for different field changes, providing comprehensive behavioral transparency.

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 purpose, body shape, thresholds, auth, and response examples. It is informative without being overly verbose, though slightly longer than necessary.

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 the tool's purpose, input format, output structure (structured diff), thresholds, authentication, and side effects. Given the complexity and lack of output schema, it provides complete contextual information.

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 is empty (0 parameters), but description provides an example request body with all necessary fields, effectively defining the parameter semantics beyond the schema. This adds significant 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 verb 'Compute' and the resource 'what changed since a previously-stored snapshot'. It distinguishes itself from sibling tools like get_slate_players and list_slates by focusing on diff functionality.

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 implicitly defines when to use the tool (to compute changes since a snapshot), but lacks explicit exclusions or alternative tool recommendations. However, the context is clear enough for an agent to infer appropriate usage.

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 extensive behavioral context: meaning of age_min, that generate_fetches_live indicates live fetch, and guidance on not treating stale cache as a blocker. It also explains limitations when only date is given. However, it does not explicitly state idempotency or absence of side effects, though heavily implied.

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

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

Well-structured: starts with one-line summary, then sections on parameters and behavioral notes. The MLB freshness section is lengthy but necessary for correct usage. Some redundancy could be trimmed, but overall efficient.

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?

Covers high-level behavior and critical warnings, but lacks detailed output schema (e.g., the actual response fields indicating readiness). The example only shows validation error. Given 6 parameters and no output schema, the description leaves some gaps that an agent would need to infer from sibling tools or experience.

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 describes 6 parameters with 0% coverage. The description adds meaning for 'slate_id' and 'date' (requirement and behavior difference) but does not explain 'include_snapshot', 'last_known_fingerprint', 'site', or 'sport'. While site and sport are common, the other two lack guidance, partially compensating for low coverage.

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 as a 'Pre-flight diagnostic for a slate' that checks readiness of odds, projections, etc., before invoking /v1/generate. It uses specific verb+resource and distinguishes from sibling tools.

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

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

Explicitly states when to use the tool (before /v1/generate). Provides detailed guidance on using slate_id vs date, including behavior differences. Includes a comprehensive note on MLB projection freshness, warning against misinterpretation and advising to check actual player pools instead.

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

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

With no annotations, the description fully carries the burden. It explicitly states it is a write operation, writes to Supabase in prod, costs API calls, and requires specific auth. This is thorough disclosure.

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 into sections (purpose, behavior, responses) and relatively concise. The inclusion of a validation error example is somewhat unnecessary but not detrimental.

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?

Considering the complexity (3 params, no annotations, no output schema), the description covers the key behaviors, return value structure, auth, and cost. Missing details on site/sport values, but defaults are given. Overall adequate.

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 description mentions 'for a date' implying the date parameter, but does not explain site or sport parameters. Schema coverage is 0%, so the description adds some value but not enough for full clarity on all three parameters.

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

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

The description clearly states the tool's purpose: 'Re-fetch projections + odds + slate metadata for a date.' This is a specific verb and resource that distinguishes it from siblings like list_slates or slate_diff.

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 important usage context: auth requirements (X-API-Key or X-Internal-Secret), cost (Stokastic + ESPN API call), and that it is a write op. However, it does not explicitly contrast with alternative tools or specify when not to use it.

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