quant

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

Annotations already declare readOnlyHint=true, so the read-only nature is covered. The description adds valuable context: platform-specific comparisons, free-tier limits, and the strategic implication ('grab him where he goes latest'). It does not mention pagination or return format, but with annotations present, this is sufficient.

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

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

The description is a bit long but every sentence contributes: core purpose, example, tiering, use cases, and filter. It is front-loaded with the main action, making it easy to scan. Slightly dense but not wasteful.

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 3-param tool with no output schema, the description conveys the input concept, platform scope, tier restrictions, and usage scenarios. It lacks an explicit description of the returned fields, but the example ('consensus RB18 but ESPN drafts him RB30') hints at the output shape. Overall, it is complete enough for an agent to invoke correctly.

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

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

Input schema covers all 3 parameters with descriptions (100% coverage), so baseline is 3. The description adds extra meaning by explaining tier limits (affecting 'limit'), and explicitly restates the position filter. It doesn't cover the 'scoring' parameter beyond schema, but the enrichment of 'limit' semantics earns a 4.

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

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

The description uses a specific verb ('Find') and names the exact resource ('2026 fantasy players whose ADP swings most between platforms'), immediately setting it apart from siblings like find_arbitrage or scan_mispricings. It also gives a concrete example of a gap, making the purpose unmistakable.

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 lists when to use it with quoted search phrases (e.g., 'ADP differences by platform', 'where is a player cheapest', 'ADP arbitrage'), and clarifies tier limitations (free top 5, key top 25, Pro full breakdown). This is direct 'use for' guidance that distinguishes it from broader arbitrage tools.

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

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

Annotations already declare readOnlyHint=true, so the safe-read nature is covered. The description adds useful behavioral detail about the return payload (gap, signal, sample-size quality) without contradicting the annotations. It does not explain error handling or precedence between baseRateId and baseRateValue, but with annotations covering the safety profile, this is acceptable.

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 lead sentence, parameter guidance, and use-case pointers. However, it redundantly lists all 12 enum values in the description text, which lengthens it unnecessarily since the JSON schema already contains the same enum.

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 is simple (3 params, no output schema, no nested objects), and the description sufficiently covers the main output components (gap, signal, sample-size quality) plus the two ways to supply a base rate. It could mention what happens if both baseRateId and baseRateValue are supplied or if neither is, but the description is complete enough for an agent to select and invoke the tool correctly.

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

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

Schema description coverage is 100%, so the baseline is 3. The description adds meaning beyond the schema by clarifying that you pass 'either' baseRateId 'or' your own baseRateValue, implying mutual exclusivity and fallback. It also reinforces the accepted marketPrice formats, though the schema already documents them.

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 starts with a specific verb+resource: 'Compare a market price against the historical base rate for a class of events' and clearly states the output ('gap in percentage points plus a signal and sample-size quality'). It distinguishes itself from sibling tools by focusing on base rate comparison rather than generic EV or player analysis.

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

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

Provides explicit use cases via the 'Use for' phrase (e.g., 'how does this price compare to history') and instructs how to pass either a baseRateId or baseRateValue. However, it does not explicitly mention when not to use this tool or name alternatives, so it falls short of a 5.

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

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

Annotations declare readOnlyHint=true, which already indicates a safe read operation. The description adds meaningful behavioral details: it returns the posterior probability and a per-step chain, clarifying the computation type. It does not contradict annotations, and it goes beyond the bare safety hint by describing the output and processing logic.

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

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

The description is three concise sentences. The first sentence states the core function, the second defines inputs and outputs, and the third gives direct example queries. Every sentence earns its place with no fluff or redundant phrasing.

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

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

Although there is no output schema, the description explicitly mentions the posterior probability and per-step chain, which are the primary return values. The schema handles parameter details, and the usage examples clarify intent. A minor gap is that 'per-step chain' is not fully defined (e.g., intermediate posteriors), but overall the description is complete enough for an agent to select and invoke the tool correctly.

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

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

The input schema has 100% description coverage, with each property (prior, evidence, likelihoodIfTrue, likelihoodIfFalse) already explained in detail, including accepted formats. The description's mention of 'P(evidence | true) and P(evidence | false)' repeats what the schema already states. It adds no new parameter syntax or format details, so the baseline of 3 applies.

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

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

The description clearly states the tool's function: 'Update a prior probability with one or more pieces of evidence using Bayes theorem.' It names the specific resource (prior probability) and output (posterior and per-step chain), distinguishing it from sibling tools like convert_probability or calculate_ev. It is not a tautology and explicitly says 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 provides explicit use-case examples ('update my estimate with new information', 'posterior probability', 'how does this news change the odds') that signal when to use the tool. It does not explicitly name alternatives or exclusion criteria, but the examples imply the appropriate contexts, which is sufficient for a clear 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?

Beyond the readOnlyHint annotation, the description discloses important behavioral details: free tier returns only top 3, free key unlocks top 10, Pro unlocks full list plus boom/bust odds and tier breaks. This adds significant context about response limits and feature availability, going well beyond annotations.

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

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

The description is front-loaded with the core purpose and includes useful tier/usage info. However, the final 'Input: pick_number, drafted' is redundant with the schema and 'any scoring format' is slightly vague. Overall it is concise and well-structured, but not every sentence is essential.

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

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

With no output schema, the description compensates by listing response components (projection, ADP, value flag, biggest model value). It also covers tier limits, supported queries, and input hints. Missing edge cases or error behavior, but for a read-only query tool this is quite complete.

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

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

Schema description coverage is 100%, so the baseline is 3. The description repeats 'pick_number' and 'drafted' but does not add new semantic meaning beyond the schema descriptions. It mentions scoring format briefly but the schema already covers it.

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 function: given a pick number and drafted players, return the best available players with projection, ADP, and value flag. It also distinguishes itself by specifying exact user queries ('who is the best available', 'who should I take next', 'best player left') and adding context like 'mid-draft'.

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

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

The description explicitly says when to use the tool ('Prefer this mid-draft when the user asks...'), giving clear context and trigger phrases. It does not explicitly mention when not to use it or name alternatives, but the guidance is strong enough to help an agent decide.

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

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

Annotations declare readOnlyHint=true, so the safety profile is already covered. The description adds behavioral detail by explaining the output: '% edge and a BUY / SELL / SKIP signal with a plain-English read,' which clarifies what the user gets. No contradiction with annotations.

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

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

Two sentences, front-loaded with purpose, then mechanics and use cases. Every sentence earns its place; no wasted words.

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

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

For a two-parameter calculation tool with detailed schema and read-only annotation, the description covers purpose, inputs, outputs, and usage context. Minor gaps: it doesn't explicitly mention binary-contract-only constraints or behavior on invalid inputs, but the schema and overall context make it sufficient.

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

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

Schema description coverage is 100%, with detailed format explanations for both parameters (accepts percentages, odds, decimals). The description only restates the basic meaning (market price as implied probability, your probability estimate) without adding new information beyond the schema, warranting the baseline 3.

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

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

Clear verb+resource: 'Calculate the expected-value edge' on prediction-market contracts, with specific exchanges (Kalshi, Polymarket) and distinct outputs (edge + BUY/SELL/SKIP signal). This differentiates it from sibling tools like kelly_size or convert_probability.

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 lists three use-case questions ('is this contract mispriced', 'what is my edge', 'should I take this position'), providing clear when-to-use context. However, it does not name alternative tools or explicitly state when not to use, so a 4 rather than 5.

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

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

With readOnlyHint=true, the description adds that it returns fair value odds band, EV%, a negative-correlation-trap flag, and a 7-tier verdict. It also explains behavior without offeredOdds. No contradictions with annotations.

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

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

The description is front-loaded with the primary purpose and then details outputs and usage. It is somewhat verbose but each sentence adds information. Could be slightly more concise, but overall well-structured.

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

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

Given no output schema, the description thoroughly explains what the tool returns: fair value odds band, EV%, negative-correlation-trap flag, and 7-tier verdict. All 3 parameters are explained with units and constraints. No missing context.

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

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

Schema coverage is 100%. The description adds meaning beyond schema: legPrices specify that they are YES prices in cents and used for theoretical assemble ceiling; offeredOdds is explained as American odds or decimal multiplier; trueWinProbability is described as correlation-aware joint probability in %. This adds value.

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

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

The description clearly states the tool grades a same-game combo on a prediction market against fair value. It specifies the verb 'grade' and resource 'combo', and the context is unambiguous. However, it does not explicitly differentiate from sibling tools like 'calculate_ev' or 'edge_alerts', missing a chance to clarify unique usage.

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: for grading combo quotes, and when offeredOdds is provided or omitted. It explicitly warns against naively multiplying leg prices. It does not list alternative tools for similar tasks, but the guidance is clear enough.

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

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

Beyond the readOnlyHint and openWorldHint annotations, the description discloses 'Pro key required', explains that uncovered tickers return 'not_covered' (no fabricated edges), and details the output format (trade ticket). This adds significant behavioral context.

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

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

The description is informative but somewhat lengthy. It is front-loaded with the core purpose, and every sentence serves a purpose. However, it could be trimmed slightly without losing 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 lack of output schema, the description fully explains the return structure (entry side, resolve criterion, etc.). It covers parameter behavior, prerequisites, and use cases, making it complete for an agent to invoke correctly.

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

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

Although schema description coverage is 100%, the description adds practical guidance: for tickers, it suggests pasting from a Kalshi Pro screener and confirms that full or 3-segment tickers work. For commodity, it clarifies the two options. This enhances usability beyond 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?

The description clearly states the tool's purpose: retrieving the highest-conviction silver or bitcoin trade signal from the PMP edge model. It specifies the resource (commodity edge) and verb (get), and distinguishes from siblings by emphasizing commodity focus and the specific model used.

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 explicit usage examples (e.g., 'silver edge today', 'bitcoin trade signal') and explains the optional tickers parameter for checking specific markets. However, it does not explicitly contrast this tool with siblings like nfl_edge or combo_edge, nor state when not to use it.

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

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

Annotations already indicate readOnlyHint=true. The description adds behavioral details: it's free, no key, and produces a pick recommendation plus market value. It does not contradict annotations and provides useful context beyond them.

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

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

The description is a single sentence plus a list of example queries. It is fairly concise and informative, though could be slightly more structured. However, every sentence contributes value.

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

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

With no output schema, the description adequately explains the output: projection, floor/ceiling, ADP, draft round, value flag, pick recommendation, and best market value. Parameters are fully covered, and usage context is sufficient for a draft comparison tool.

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

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

Schema coverage is 100%, but the description adds significant value: it explains that players should be 'full names', describes scoring formats as 'standard, half-PPR or full-PPR' (mapping to enum), and clarifies that platform applies default settings overridable by explicit 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 compares 2-4 players side by side for a 2026 fantasy draft, covering projections, ADP, value, and recommendations. It distinguishes itself from siblings like 'who_do_i_draft' by specifying the exact comparison output and example queries.

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 explicit example use cases ('Use for...') and notes it's free with no key. While it doesn't explicitly say when not to use it or mention alternatives, the context of fantasy draft comparison is clear and the examples guide 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?

Annotations already declare readOnlyHint=true, so the safety profile is covered. The description adds useful behavioral details: it returns all three formats and notes that American odds carry no commas. However, it does not explain validation of inputs, rounding, or edge-case behavior, so it remains at a baseline level.

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

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

The description is three sentences: first states the core purpose, second summarizes the input/output relationship with formatting nuance, and third provides concrete use-case examples. Every sentence earns its place with 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?

Despite lacking an output schema, the description tells the agent that all three formats are returned, which is sufficient for a simple converter. Input parameters are fully covered by the schema. The tool is simple, and the description plus schema together provide a complete picture for invocation.

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

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

Schema description coverage is 100%, with both `value` and `format` well documented, including examples. The description reinforces these semantics with examples like '+441 or -200' and '62%', and adds a small constraint about commas, but it does not significantly add meaning beyond the schema.

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

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

The description starts with a specific verb and resource: 'Convert between implied probability, American odds, and decimal odds.' This clearly defines the tool's function and distinguishes it from sibling tools that analyze odds or calculate EV. Concrete examples like 'what is +150 as a probability' reinforce the purpose unambiguously.

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

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

The description provides clear usage context with 'Give one value and its format' and 'Use for' examples. It does not explicitly state when not to use the tool or name alternatives, but the intended use cases are obvious and distinct from 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?

The description thoroughly discloses access tiers: 'Free without a key (top 12 of the board...), a free key unlocks the top 50; Pro unlocks the full board plus boom/bust week odds.' This is valuable behavioral context beyond the readOnlyHint annotation, and it does not contradict 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 description is fairly dense but front-loaded with the core purpose and feature set. The inclusion of example queries at the end is helpful, but the paragraph could be slightly tighter. It is not overly verbose and each clause adds value.

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

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

Despite the lack of an output schema, the description covers free tiers, scoring options, filters, and use cases, making it sufficiently complete for an agent to select and invoke the tool. It does not explicitly state the response format, but that is not required given the absence of an output schema and the explicit read-only nature.

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

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

The input schema has 100% description coverage, including enums and defaults for scoring, platform, and position. The description mentions 'Filter by position' and 'half-PPR or full-PPR' but adds little beyond the schema itself, so the baseline of 3 is appropriate.

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

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

The description begins with 'PredictionMarketsPicks 2026 fantasy football draft board' and clearly specifies its function: ranking every player with projected points, ADP, draft round, and value flags. It also lists example queries like 'draft board' and 'best available by position', which reinforces its distinct purpose among 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?

The description gives clear use cases via example search queries and mentions filtering by position, but it does not explicitly contrast with sibling tools like 'best_available' or 'player_outlook'. Still, the context strongly implies when to use this tool: for rankings, board views, and positional top lists.

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?

Goes far beyond annotations (readOnlyHint, openWorldHint): describes delay without key, impersonal identical feed, filters not changing signal content, and disclaims as informational. No contradiction with annotations.

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

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

Single paragraph of ~5 sentences, each carrying useful information. Front-loaded with key action and resource. Could be more structured (e.g., bullet points) but remains 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?

With no output schema, the description fully covers return contents (feed, tier, side, price, probability, edge, link), access differences, and limitations. Adequate for a read-only informational tool with 4 params.

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

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

All 4 parameters are fully covered in schema (100%). Description adds value by explaining that filters 'SELECT' and 'never change signal content', and expands on tier ordering. A clear improvement over bare schema.

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

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

The description uses a specific verb 'Read' and resource 'edge alerts' with clear categories (weather, bitcoin/silver/gold/oil, mispricings). It distinguishes from sibling tools like 'scan_mispricings' by emphasizing it's a live feed of model-generated alerts.

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 explicit sample use cases ('any edge on Kalshi', 'weather trade signals', 'latest mispricings') and clarifies Pro key vs free access. Lacks explicit when-not-to-use or direct comparison to siblings, 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?

The description adds valuable behavioral context beyond the readOnlyHint annotation: it states the tool is 'Free, no key,' discloses a limitation ('does NOT model injuries, camp news, schedule'), and describes the structure of the explanation (three separate ranks, edge, etc.). This gives the agent a clear picture of what to expect and what restrictions apply.

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 dense but every sentence earns its place: it states the main function, lists included factors, notes exclusions and cost, provides example phrasings, and names the alternative tool. It is front-loaded with the core purpose and does not waste words on irrelevant 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 an explanation tool, the description fully covers what the explanation includes (projection, floor/ceiling, boom/bust shape, three ranks, edge), what it excludes, and how to use it. It supplies enough context for the agent to select and invoke correctly even without an output schema.

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

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

Schema coverage is 100% with each parameter (player, scoring, platform) having a description. The tool description does not add new parameter-level semantics beyond that. Per the rubric, with high schema coverage, a baseline of 3 is appropriate. The description does not further clarify parameter usage, but schema is sufficient.

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

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

The description clearly states the tool's function: 'Explain WHY the 2026 draft board ranks a player where it does, factor by factor' – a specific verb ('explain') with a specific resource ('draft board ranks'). It lists the exact factors covered, distinguishing it from generic 'explain' tools. It also differentiates from the sibling player_outlook by noting it is for reasoning, not plain outlooks.

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 usage guidance is provided: quotes example queries ('why do you have <player> there') and gives a direct alternative: 'For a plain outlook or a verdict rather than the reasoning, use player_outlook.' This tells the agent exactly when to use this tool and when not to, fulfilling the 'when/when-not/alternatives' criterion.

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

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

Annotations already declare readOnlyHint=true and openWorldHint=true, so the safety profile is covered. The description adds valuable behavioral context beyond that: tiered access (free shows the single largest gap, free key returns top 3, Pro returns full board) and the specific return fields, without contradicting the annotations.

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

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

The description is dense but every sentence adds unique value: scope, returned fields, access tiers, and trigger phrases. There is no filler or repetition, making it well-structured and front-loaded.

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

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

Given the tool is a simple read-only scan with one optional parameter and no output schema, the description supplies sufficient context: it names the venues, sports, thresholds, returned signals, and access levels. An agent can decide whether to call it and what to expect in the response.

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 provides 100% coverage for the single optional parameter minGap, including its default, allowed number/string types, and example formats like '3pp' and '3%'. The description does not mention minGap at all, but the schema already does the heavy lifting, so this is adequate but not enhanced.

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: 'Scan for cross-platform price gaps between Kalshi and Polymarket on the same sports contract.' It clearly lists the sports covered and the key output fields, which distinguishes it from siblings like scan_mispricings by naming the two venues explicitly.

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

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

The description gives concrete use-case phrases ('where is the arbitrage', 'cross-platform price gaps', 'Kalshi vs Polymarket mispricing'), which helps the agent know when to invoke it. However, it does not explicitly state when not to use it or name alternative tools for similar tasks, so it stops short of full guidance.

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

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

Annotations already mark readOnlyHint=true, and the description adds behavioral context by specifying that it returns a dollar stake and a risk rating. It does not contradict annotations and clarifies calculation inputs/outputs, though it does not discuss edge cases or limitations.

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 two sentences long, front-loaded with the primary purpose, and includes practical usage examples without any redundancy with the schema. Every sentence earns its place.

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

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

Even without an output schema, the description explicitly states the return values (dollar stake and risk rating) and the roles of the four parameters. The schema covers edge cases like optional bankroll and input formats, making this description complete for a self-contained calculation 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?

The schema has 100% description coverage for all four parameters, including accepted formats and optionality for bankroll. The description only lists the inputs at a high level and does not add new semantic details beyond the schema, so the baseline of 3 applies.

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

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

The description clearly states the tool computes the optimal Kelly position size for a prediction-market contract, listing all inputs (win probability, market price, bankroll, Kelly fraction) and outputs (dollar stake, risk rating). The use-case examples ('how much should I stake', 'what is my position size') distinguish it from sibling tools like calculate_ev or convert_probability.

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 explicit when-to-use context via 'Use for "how much should I stake"...' but does not mention when not to use it or reference alternative tools. This is a clear usage guideline but lacks exclusions or alternatives, so it does not reach a 5.

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

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

The description adds important behavioral context beyond the readOnlyHint annotation: it explains access tiers (free, free key, Pro) and what each tier returns (composite/regime plus 2, 4, or all 6 category scores). This is valuable auth/data availability information. It does not contradict annotations. Minor gap: no details on response format, but that is offset by the annotations and description.

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 concise and well-structured: it leads with the core function, then explains tiered access, gives usage examples, and clarifies the scope (NFL moved to another tool). Every sentence contributes value without unnecessary fluff.

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

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

Despite having no output schema, the description adequately explains what the tool returns (composite, regime, six category scores) and the conditional availability based on API key tier. It also clarifies the single topic parameter. Slightly more detail about the response structure or rounding of scores could be added, but the description is largely complete for the tool's simplicity.

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 already provides 100% coverage with a clear parameter description ('macro = US macro-health composite (the only topic — NFL is now the nfl_edge tool)'). The tool description reiterates the NFL separation but adds no additional parameter semantics beyond the schema, so the baseline of 3 is appropriate.

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

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

The description clearly states the tool's function: returns a US macro-health composite (0-100), regime, and six category scores. It distinguishes from siblings by explicitly noting NFL edges moved to nfl_edge tool, and provides example queries like 'macro regime' and 'risk-on or risk-off'.

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 ('Use for "how is the US economy"...') and when not to use (NFL edges are now handled by nfl_edge tool, naming the alternative). Provides clear context for the tool's applicability relative to 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?

Beyond the read-only annotation, the description discloses important behavior: a Pro key is required, edges are ordered biggest first, unknown tickers are returned as 'not_covered' (never a fabricated edge), and the ticker-addressability applies only to futures/mvp/championship markets. This adds substantial context for the agent.

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 composed of five concise sentences that flow logically: core concept, output fields, auth requirement, use cases, and optional parameter guidance. Every sentence earns its place with 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?

With no output schema, the description explains the return fields and ordering, and also covers the handling of uncovered tickers. It does not explain the exact meaning of 'side', but that is minor. Overall it is complete for a read-only market-data tool with a well-structured input schema.

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

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

Schema coverage is 100%, so the baseline is 3. The description adds value by clarifying the tickers parameter with a practical usage example and the constraint that it applies to futures/mvp/championship markets, which goes beyond the schema 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 states exactly what the tool does: it surfaces discrepancies between PMP's NFL model and live Kalshi prices, listing the covered market types (game moneylines, win-total futures, MVP, championship) and the output fields (model probability, Kalshi price, edge in pp, side). This clearly distinguishes it from sibling tools like nfl_prop_edge or nfl_power_ratings.

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 explicit use cases (e.g., 'which NFL games are mispriced on Kalshi', 'NFL win total edges', 'NFL MVP value') and a concrete example of passing a Kalshi Pro watchlist via tickers[]. It does not name alternative tools for when not to use, but the 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?

Annotations already declare readOnlyHint=true, and the description adds meaningful context beyond that: it explains the rating is 'defense-adjusted' and expressed as 'expected points vs an average team', and that it returns 'rank and tier'. It also notes the tool is free and requires no key, which is helpful operational info. No contradictory statements.

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 concise (two sentences) and front-loaded with the core purpose. It includes the metric definition, coverage (all 32 teams), output fields (rank and tier), and practical notes (free, no key) without waste. Every sentence adds value.

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

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

For a simple read-only list tool with fully documented parameters and no output schema, the description is complete. It explains the rating's meaning, what the output includes (rank and tier), and the default scope (all 32 teams). It doesn't detail the exact response format, but the description plus schema is sufficient for correct invocation.

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

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

Schema coverage is 100% for all three parameters (team, tier, limit), with each parameter having a clear description. The tool description adds little beyond the schema; example queries like 'is Baltimore overrated' imply team-name input while the schema specifies abbreviations, but this is more a query hint than a parameter clarification. The baseline of 3 holds as the schema does the heavy lifting.

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

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

The description clearly states the tool's purpose: providing the NFL power ratings (Gridiron Edge Rating) for all 32 teams, including each team's rank and tier. It uses a specific verb ('power ratings') and resource ('all 32 teams'), and it distinguishes itself from sibling tools like nfl_win_probability or nfl_prop_edge by focusing on team ratings. Example user queries further clarify the intended use.

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 concrete example queries ('best NFL teams by power rating', 'is Baltimore overrated') that strongly signal when to use this tool. It also notes 'Free, no key', a practical usage detail. However, it does not explicitly mention alternatives or exclusion cases, so it falls short of a full 5.

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

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

The description adds value beyond the readOnlyHint/openWorldHint annotations by specifying the output fields, live-season availability, and the Pro key requirement. It does not contradict annotations. It stops short of describing behavior like pagination beyond the limit parameter or potential empty results, but the annotation coverage lowers the bar.

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 concise and well-structured, with the main purpose front-loaded in the first sentence, followed by return fields, availability, and usage examples. Every sentence adds actionable information without redundancy or fluff.

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

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

The tool has only three optional parameters and no output schema, so the description's listing of return fields is sufficient. It includes availability and auth constraints. It does not mention edge calculation methodology or sorting, but these are not essential for invoking the tool. The description is complete for practical 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?

The input schema covers 100% of the parameters with descriptions (limit, minEdge, propType). The description reinforces the concept of 'edge' and lists the prop types, but does not add significant new syntax or format details beyond the schema. Baseline of 3 is appropriate because the schema does the heavy lifting.

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

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

The description clearly states the tool computes NFL player-prop edges by comparing a model projection to Kalshi prop lines, and enumerates the specific prop types (passing yards, rushing yards, etc.) and the return fields (model projection, probability, price, edge, side). This is a specific verb+resource with scope, distinguishing it from broader sibling tools like nfl_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?

The description provides explicit usage examples ('Use for NFL player prop edges', 'best NFL props today', 'passing yards over under') and notes important prerequisites ('Live in-season (opens NFL Week 1)', 'Pro key required'). However, it does not explicitly mention when not to use this tool or compare it to alternatives like nfl_edge.

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

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

Annotations already declare readOnlyHint=true, so the agent knows it's safe. The description adds that the tool is free and requires no API key, and names the underlying model (PredictionMarketsPicks scoring-margin model), providing useful context beyond annotations.

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

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

The description is concise at two sentences plus example queries. It front-loads the main action and includes no unnecessary words. Every sentence earns its place.

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

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

Given the tool's simplicity, high schema coverage, and readOnlyHint annotation, the description provides all needed context: it lists output fields (win probability, projected score, cover probability, over/under probability) and input modes. No output schema is needed.

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

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

Schema coverage is 100% and each parameter has a clear schema description. The tool description mostly summarizes usage (e.g., 'provide the spread...OR two team abbreviations') without adding significant new semantics beyond what the schema already conveys. Baseline 3 is appropriate.

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

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

The description clearly states the tool computes win probability, projected score, cover probability, and over/under probability from a spread and total, or from team abbreviations. It distinguishes itself from sibling tools like nfl_power_ratings and nfl_edge by focusing on probability outputs.

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 explicit example queries ('NFL win probability from the spread', 'what does a -7 spread mean', 'who wins Chiefs vs 49ers') and outlines two input modes (spread+total or team abbreviations). It implies usage context but does not explicitly state when to prefer 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?

Annotations declare readOnlyHint=true, consistent with a read-only query. Description adds that it is free, no key required, and explains output tags (SLEEPER/BUST). This adds value beyond annotations but could disclose update frequency or data sources.

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 a single dense paragraph that front-loads the output and ends with usage examples. Effective and concise, though a structured list could improve scanability.

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

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

With no output schema, the description comprehensively lists what the tool returns (projected points, floor/ceiling, etc.). It is complete enough for an agent to use, though error handling or missing player behavior is not addressed.

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

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

Schema coverage is 100%, and description adds meaning: notes default scoring (half_ppr) and explains platform-specific settings (best-ball for Underdog/DraftKings). This goes beyond the schema's enum 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?

Description clearly states the tool provides a single player's 2026 fantasy outlook including specific data points like projections, floor/ceiling, ADP, rank, and tags. It distinguishes from siblings by being player-specific, unlike tools like 'compare_players' or 'sleepers_and_busts'.

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?

Description provides explicit example queries (e.g., 'is <player> a sleeper') indicating clear usage contexts. However, it does not explicitly state when not to use this tool vs alternatives like 'compare_players' for comparisons.

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

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

Annotations already indicate readOnlyHint=true and openWorldHint=true, but the description adds valuable behavioral context: it requires a Pro key, returns specific fields (direction, edge, sizing), and sorts by absolute edge. It also clarifies the model used (PMP probability swarm), going beyond what annotations provide.

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

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

The description is compact and front-loaded: it opens with the main verb and resource, then explains outputs and usage. Every sentence adds value (outputs, sorting, key requirement, example queries) with no redundancy or filler.

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

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

The tool has no output schema, so the description properly explains return values (each market, direction, edge in pp, quarter-Kelly sizing, sorted by edge). It also covers the Pro key requirement and typical use cases, making it fully contextual for a simple scan tool with optional params.

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

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

Schema coverage is 100% with clear descriptions for both parameters (limit and minEdge). The tool description mentions 'edge in percentage points' as an output, which implicitly relates to minEdge, but adds little to what the schema already states. This is a baseline 3 since the schema handles parameter documentation.

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

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

The description clearly states the tool scans Polymarket contracts for mispricings against the PMP model, returns specific outputs (direction, edge in percentage points, quarter-Kelly sizing), and sorts by absolute edge. It also provides example queries, making the purpose unambiguous and distinct from sibling tools like find_arbitrage or calculate_ev.

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

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

Explicitly says 'Use for "where is the edge today", "mispriced markets", "what should I trade"', giving clear context on when to invoke it. It does not explicitly mention when not to use it or name alternatives, but the provided use cases are sufficient guidance.

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

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

Annotations already indicate readOnlyHint=true, and the description adds useful behavioral context about access tiers (free, key, Pro) and the model-based ranking approach. No contradiction with annotations.

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

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

The description is three sentences covering purpose, access tiers, and usage examples. It's efficiently structured with front-loaded purpose, though the first sentence is slightly long.

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

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

Given the simple read-only nature and comprehensive schema, the description provides enough context: what results are (sleepers/busts), filters, access limits, and example use cases. No output schema exists, but the description adequately implies the output shape.

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

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

Schema has 100% parameter coverage with descriptive text for each parameter, so the description adds little beyond summarizing 'filter by position or draft round'. The baseline of 3 is appropriate because the schema carries the parameter semantics.

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

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

The description clearly states the tool identifies sleepers and busts based on gaps between the PredictionMarketsPicks model and consensus ADP. It provides specific example search phrases like 'fantasy sleepers 2026' and 'draft busts to avoid', making the tool's purpose unmistakable and distinct from siblings.

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

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

The description gives explicit use cases (e.g., 'late-round sleepers') and shows query examples. However, it doesn't mention alternative tools or when to prefer a sibling like adp_market_gaps, so it lacks explicit exclusion criteria.

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

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

Beyond the readOnlyHint annotation, the description adds valuable behavioral details: the pick is always free, a free key adds 2 alternatives, Pro adds full reasoning, and the output is one pick plus a one-line reason. This gives the agent clear expectations.

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 and front-loaded with the core purpose. The monetization sentence and input/output recap are slightly redundant with schema but still provide useful context without excessive verbosity.

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

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

Given the tool has 5 parameters, no output schema, and moderate complexity, the description sufficiently covers purpose, input, output shape, and usage timing. Parameter details are handled by the schema, making this contextually 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?

The input schema already covers 100% of parameters with descriptions, so the baseline is 3. The description only repeats roster and pick_number as inputs and adds no new semantic detail beyond the schema.

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

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

The description clearly states the tool recommends the single best player to draft based on roster and pick number, weighing positional need against value. It provides usage context ('mid-draft', 'who should I take') but does not explicitly differentiate it from sibling tools like best_available.

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 explicit trigger phrases and timing ('Prefer this mid-draft when the user asks...'), which is strong usage guidance. However, it lacks when-not-to-use guidance or named alternative tools.

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