Prediction Markets Quant

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

Annotations already declare readOnlyHint=true, and the description adds useful behavioral context: the tool returns 154 fixed gaps, requires no key or email, has a Pro layer, and focuses on platform-specific ADP discrepancies. It does not describe the output shape in detail, but for a zero-parameter read-only tool this is a reasonable level of 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 core purpose is front-loaded in the first sentence, and the example and use-case list earn their place. It is slightly wordy with the 'Pro adds the judgment layer' and 'FREE' access details, but overall every section contributes actionable context and the description remains compact.

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 conveys the data source, use cases, access requirements, and row count, which is strong for a zero-parameter read-only tool. However, there is no output schema and the description never specifies the exact fields returned beyond an illustrative rank example, and the unsupported filter claim leaves a gap in invocation correctness.

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 properties, so the baseline would normally be 4. However, the description advertises 'Filter by position (QB/RB/WR/TE/FLEX)' even though no filter parameter exists in the schema. This is misleading: an agent may attempt to pass an unsupported position argument and fail schema validation.

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 opens with a specific verb and resource: 'Find the 2026 fantasy players whose Average Draft Position swings most between platforms.' It names the exact platforms and gives a concrete example, making the tool's unique ADP-arbitrage purpose unmistakable and clearly distinct from sibling tools like compare_players or scan_mispricings.

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 ('Use for ADP differences by platform', 'ADP arbitrage', 'who falls on ESPN vs Sleeper') and context about access ('All 154 gaps are FREE — no key, no email'). It does not state when not to use it or name alternatives, but the context is clear enough for an agent to select it in the intended scenarios.

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=false, so the safety profile is covered. The description adds meaningful behavioral context by specifying the return components: gap, signal, and sample-size quality. It does not detail edge cases like what happens if both baseRateId and baseRateValue are supplied, but that is a minor gap.

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

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

The first sentence is front-loaded with the core action and output. The enum list is somewhat redundant with the schema but still useful for discoverability, and the use-case sentence earns its place. Overall it is organized and not padded.

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

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

Given no output schema, the description compensates by naming the result fields (gap, signal, sample-size quality). Inputs are well covered by the schema, and the description clarifies the either/or relationship between baseRateId and baseRateValue. Minor ambiguity remains about conflict or omission behavior, but the tool is simple enough that the description is essentially 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 the enum list and the baseRateValue alternative but does not add new semantic meaning beyond the schema. No extra parameter guidance is provided, so it does not rise above baseline.

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

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

The description states a specific verb-resource pair ('Compare a market price against the historical base rate') and enumerates the outputs (gap in percentage points, signal, sample-size quality). It clearly differentiates this tool from siblings like calculate_ev or convert_probability by focusing on historical base-rate comparison.

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-case phrasing ('how does this price compare to history', 'is the market ignoring the base rate', 'historical frequency vs market') and explains the two input paths (baseRateId or baseRateValue). It does not name alternatives or exclusion conditions, but the context is clear enough for an agent to select it appropriately.

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 MATERIAL, so the safety profile is covered. The description adds the expected output ('posterior probability and the per-step chain') and the Bayes theorem basis, but it does not go into edge behavior such as rounding, numerical precision, or what happens if evidence is omitted. Given that annotations carry the safety burden, this is adequate but not rich.

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

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

The description is tight: one action sentence, one input/output sentence, and one usage-intent sentence. There is no tangental detail, and the key operation is front-loaded. 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?

With only two parameters holistically documented by the schema and read-only annotations, the description covers the core call context well. It names the return value and the chain, though there is no output schema and the exact shape of the 'per-step chain' is not specified. This is a minor gap rather than a missing critical signal.

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

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

Schema description coverage is 100%, so the schema already documents prior, likelihoodIfTrue, likelihoodIfFalse, and label thoroughly. The description only lightly re-states the evidence structure without adding new semantic detail beyond the schema. This matches the baseline for full-coverage schemas.

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 action—'Update a prior probability with one or more pieces of evidence using Bayes theorem'—and immediately distinguishes the operation from sibling calculators by focusing on posterior updating and per-step chains. It also provides concrete user-intent phrases like 'posterior probability' and 'how does this news change the odds,' which makes the tool unambiguous to 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?

The 'Use for...' line gives clear natural-language triggers that signal when this tool is appropriate, which is strong usage guidance. It does not explicitly state when not to use it or name alternatives like convert_probability, but the context and examples are sufficient to steer an agent toward correct selection.

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

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

Annotations already declare readOnlyHint=true, and the description adds that no key/email is needed and that Pro unlocks boom/bust odds and positional tier breaks, which is useful context about access and feature gating. It does not contradict 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 core behavior is front-loaded, followed by pricing/access notes and usage triggers. It is reasonably concise, though the 'FREE — no key, no email' and 'Pro adds...' sentences are somewhat promotional and not strictly required for invocation.

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 supplies the return content (projection, ADP, value flag, biggest model value), the intended input, the draft/season context, and when to use it. This is complete enough for an agent to call and interpret the tool.

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

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

The input schema declares no parameters, so the description carries the full burden. It clearly specifies the two inputs, pick_number and drafted, and explains what they mean ('current pick number', 'names already gone'), giving an agent enough to invoke the tool correctly despite the empty schema.

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

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

The description uses a specific action ('return the best players still on the board') and resource, and it defines the domain (2026, any scoring format) and output fields. It is clear, but it does not explicitly differentiate itself from sibling tools such as who_do_i_draft or draft_board, so the purpose is clear but not distinguished.

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 explicit trigger phrases ('who is the best available', 'who should I take next', 'best player left') and a time context ('mid-draft'), which tells an agent when to prefer it. It does not list exclusions or alternate tools, so it falls just short of full alternative-routing 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?

The readOnlyHint annotation already establishes that this is a safe, non-mutating calculation. The description adds useful output behavior—'% edge and a BUY / SELL / SKIP signal with a plain-English read'—but does not disclose internal assumptions or edge thresholds. This is adequate but not rich.

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

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

The description is three sentences: function and outputs, use cases, and provenance/track-record context. It is front-loaded and every sentence earns its place, though the final track-record sentence is slightly promotional.

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 two-parameter read-only calculator, the definition is complete enough: it names the domain, inputs, outputs, and intended use cases. There is no output schema, but the description gives a reasonable picture of the return value. A bit more detail about how the BUY/SELL/SKIP thresholds are derived would be helpful but not necessary for correct invocation.

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

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

Schema description coverage is 100%, and both marketPrice and yourProbability already have detailed descriptions including accepted formats (percentages, decimals, American odds). The description adds no parameter semantics beyond what the schema already provides, so the baseline of 3 applies.

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

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

The description opens with a specific verb and resource: 'Calculate the expected-value edge on a Kalshi or Polymarket prediction-market contract.' It names the inputs and the exact outputs (% edge and BUY/SELL/SKIP signal), making the function unambiguous and clearly distinct from siblings like convert_probability or kelly_size.

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

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

The description explicitly states when to use the tool: 'Use for "is this contract mispriced", "what is my edge", "should I take this position".' This gives clear context, though it does not name sibling 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.

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

Annotations already indicate readOnlyHint=true, and the description adds rich behavioral context beyond that: output conditionality on offeredOdds, the edge formula (fair − market), how props are priced conditional on game script, the correlation-aware joint handling, and the legIds round-trip workflow. There is no contradiction with the read-only 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 long but justifiably so for a two-mode tool with six parameters. It front-loads the core function and output vocabulary before diving into the nflGame path. The only nonessential element is the marketing-style track-record sentence at the end, which slightly keeps it from a perfect conciseness score.

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

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

Given no output schema and only minimal annotations, the description carries the full burden of explaining call patterns, return behavior, and model assumptions. It covers both invocation paths, exact tier names, the fair-value band, what is returned when offeredOdds is omitted, and how legIds are obtained from nflGame. An agent has enough context to invoke the tool correctly in either mode.

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

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

Schema coverage is 100%, so the baseline is 3, but the description adds meaningful inter-parameter guidance: legPrices are 'used only for the theoretical assemble ceiling,' trueWinProbability and legPrices should be omitted when using nflGame + legIds, and offeredOdds takes precedence over offeredAmerican. These details help an agent choose the correct parameter combination, going beyond the schema.

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

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

The description opens with a specific verb+resource: 'Grade a same-game combo ... against its fair value,' and immediately names concrete outputs (fair-value odds band, EV%, negative-correlation-trap flag, 7-tier verdict). It also distinguishes itself from naive pricing by explicitly warning 'never grade EV off the product of the leg prices, which no venue pays,' which separates it from general EV/parlay calculators.

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 for both invocation modes: with offeredOdds for EV+verdict, without it for fair value only, and with nflGame for automatic leg retrieval and joint probability computation. It also provides explicit use-case phrases like 'is this combo worth it' and 'grade my parlay quote.' It stops short of explicitly naming sibling alternatives or stating when not to use this tool, so it misses the top bar.

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 only declare readOnlyHint=true and openWorldHint=true. The description adds substantial behavioral context: the exact trade-ticket fields returned, the Pro key requirement, and the honesty guarantee that unmodeled tickers return not_covered rather than a fabricated edge. 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?

Dense and front-loaded with the core action and ticket contents, followed by natural-language examples and tickers usage. Almost every sentence earns its place, though 'highest-conviction' and 'largest model edge' are slightly redundant and the paragraph could be tightened.

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 full schema coverage and no output schema, the description covers the returned ticket fields, authentication, example queries, and edge-case honesty for tickers. The only notable gap is an explicit statement of the fallback when no edge exists for a bare commodity request without tickers.

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 both parameters already have meaningful in-schema descriptions. The description still adds value beyond the schema by explaining how to use tickers[] (paste watchlist, full vs 3-segment tickers, not_covered behavior), which justifies a score above 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?

States a specific verb ('Get') and resource (highest-conviction PMP edge-model trade signal for gold, silver, WTI oil, or bitcoin), and enumerates exact Kalshi contracts (KXGOLDD, KXSILVERD, KXWTI, KXBTCD). The commodity focus clearly separates it from siblings like combo_edge, nfl_edge, and 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?

Provides explicit 'Use for' query mappings and a precise condition for passing tickers[] (to check specific Kalshi markets, e.g. a Pro screener watchlist). It does not name alternative tools or say when not to use this tool, which would raise it to 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?

Beyond the readOnlyHint annotation, the description discloses that the tool is 'Free, no key' and describes the output components it will produce: projection, floor/ceiling, ADP, draft round, value flag, pick recommendation, and market value. This gives an agent a good behavioral picture without revealing hidden side effects.

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

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

The description is tight and information-dense: the first sentence covers scope and outputs, and the second sentence gives memorable invocation examples. No filler or redundant restatement exists.

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

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

For a zero-parameter tool with no output schema, the description is complete: it explains what the tool does, what output to expect, the supported scoring formats, and how to phrase the request. An agent has enough context to decide and 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?

The tool has no structured input parameters, so the schema cannot document them. The description compensates by showing the expected input style through example phrases, making clear that player names and comparison intent are supplied in natural language.

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, specifies the context (2026 fantasy draft with PPR variants), and lists the comparison dimensions. The example query patterns make the intended use immediately recognizable and distinguish it from siblings like who_do_i_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 'Use for' and gives concrete natural-language examples such as 'who should I draft, <A> or <B>'. It provides clear context for when to invoke the tool, though it does not explicitly state when not to use it or name alternative sibling tools.

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

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

Annotations already communicate readOnlyHint=true, so no side-effect warning is needed. The description adds useful behavioral context beyond annotations: it returns all three representations at once and specifies that American odds carry no commas (e.g., +441 or -200). This helps the agent set expectations about output formatting.

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: one purpose sentence, one outcome sentence, and a short list of use-case examples. Every sentence earns its place, the main behavior is front-loaded, and there is no redundant restating of the tool name or schema.

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

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

For a simple two-parameter conversion tool with full schema coverage and a read-only annotation, the description is largely complete. It states inputs, output behavior, and formatting conventions. The only minor gap is that it does not specify the exact response structure or key names, but 'get all three back' is sufficient for most agent workflows.

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 value beyond the schema with concrete examples like '+150', '62%', and '2.5', and clarifies the American odds formatting constraint. This helps an agent understand accepted value forms without relying on enum hints 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 opens with a specific verb and resource: 'Convert between implied probability, American odds, and decimal odds.' It also states the exact outcome—'get all three back'—and gives concrete user-phrase examples that remove ambiguity. No sibling tool overlaps with this conversion purpose, so it is clearly distinguishable.

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 usage contexts: 'Use for "what is +150 as a probability"', 'convert 62% to American odds', and 'decimal to implied odds.' These examples tell an agent when to invoke the tool. It does not explicitly state when not to use it or name alternatives, but the sibling list contains no competing conversion tool.

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

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

The annotations already declare readOnlyHint=true and openWorldHint=false, and the description does not contradict them. It adds useful behavioral context: the board is free, requires no key/email/signup, covers all ~330 players, and is filterable. It does not describe the response format, but annotations already cover the safety profile.

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

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

The description is longer than minimal but information-dense; each sentence contributes something: board contents, access requirements, pro-only features, and sample queries. It is front-loaded with the core definition, though the pro-upsell sentence could be trimmed without losing essential invocation 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?

With zero parameters, read-only annotations, and no output schema, the description covers what an agent needs: board contents, filtering options, access constraints, and example user intents. It does not specify the exact output structure, but the listed fields largely substitute for that in this simple 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?

The tool has zero parameters and the schema reflects that, so there is no parameter ambiguity (baseline 4). The description still adds conceptual filtering context (position, PPR format) that is useful even though no formal parameters exist.

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 a concrete resource (the fantasy football draft board) and spells out its contents: rankings, projected points, ADP, draft round, and sleeper/bust flags, plus position filtering. It does not use an explicit action verb like 'get' or 'show,' and it does not directly name sibling tools, so it narrowly misses a 5.

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

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

The 'Use for' section provides concrete query examples and contexts (rankings, top RBs, draft board, best available by position), giving an agent strong cues for when to invoke it. It does not explicitly contrast it with nearby siblings like best_available or sleepers_and_busts, which prevents 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?

Beyond the readOnlyHint/openWorldHint annotations, the description discloses significant behavioral traits: the Pro vs. delayed 24-hour feed, thesis stripping without a key, the identical impersonal nature of the feed, and that filters only affect selection, never signal content. It even adds a disclaimer that it is not investment advice.

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 information-dense and front-loaded with the main purpose, followed by return fields, access behavior, filter semantics, and use cases. It is slightly long and includes boilerplate like 'Trade responsibly,' but each 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?

With no output schema, the description compensates by listing the fields each alert carries: feed, tier, side, price in cents, model probability, edge in percentage points, and a Kalshi market link. It also covers access tiers, delay, and filter semantics. Minor gaps remain around exact probability units and the sports_arb/nfl feeds mentioned only in the schema.

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

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

Schema description coverage is 100%, so the schema already documents all four parameters. The description adds value by explaining that filters (feed, min_tier, since) only select which alerts are shown and never alter the underlying signal content, and it names several feed categories in the first sentence.

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 opens with a specific verb and resource: 'Read the edge alerts our models generate on Kalshi' and enumerates the covered feeds (weather, commodities, mispricings). It also clarifies that this is a live feed of pre-generated signals, which distinguishes it from calculation-oriented sibling tools like calculate_ev or scan_mispricings.

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-case phrases: 'Use for "any edge on Kalshi", "weather trade signals", "latest mispricings".' It also explains the filter behavior and access-key implications. However, it does not explicitly state when to prefer a sibling tool or when not to use this feed, so it falls short of full alternative routing.

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

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

Beyond the readOnlyHint annotation, the description discloses that the tool is 'Free, no key' and explicitly states what the projection does NOT model (injuries, camp news, schedule). These behavioral limitations add meaningful context an agent could not infer from the annotations or schema.

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

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

The description is dense but each part earns its place: purpose, factors, limitations, key/access info, example phrases, and alternative tool. It is somewhat long, but front-loads the primary purpose and keeps the alternative guidance near the end, making it useful without excessive digression.

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

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

For a zero-parameter, no-output-schema tool, the description covers its purpose, output contents, limitations, and alternative tools thoroughly. The only minor gap is that it doesn't explicitly state how the target player is identified when calling the tool, but the examples imply the player is present in the user query or conversation 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?

The tool has zero parameters and an empty schema, so the baseline for this dimension is 4. The description doesn't need to explain schema parameters and instead clarifies that the caller refers to a player in natural-language terms, which is sufficient for the no-parameter situation.

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 ('Explain WHY...') and a specific resource (the 2026 draft board ranking), enumerating the exact factors that are produced. It also differentiates from the sibling player_outlook by saying this is about reasoning, not a plain outlook or verdict.

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 explicit when-to-use patterns ('why do you have <player> there', 'explain <player> ranking', 'why is <player> a sleeper/bust') and an explicit when-not-to-use pointer ('For a plain outlook or a verdict rather than reasoning, use player_outlook'). This leaves no ambiguity about how the agent should route requests.

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 context about live Kalshi data, free/no-key access, and the cross-venue comparison, but does not disclose refresh frequency or data lag.

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 densely informative: core functionality, return contents, and example use cases are all present. The phrase 'Free, no key' is repeated twice, which is minor redundancy but does not undermine 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?

With no output schema, the description carries the burden of explaining return values. It enumerates all key outputs: next meeting with days-until, strike breakdown, remaining rate path, current fed funds rate, and the Kalshi/Polymarket/CME comparison. This is complete for a no-parameter read-only 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 tool has zero parameters and an empty schema, so the baseline is 4. The description appropriately notes that no key is required, making it clear that invocation requires no setup or input.

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

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

States clearly that the tool returns live market-implied Fed rate odds for remaining 2026 FOMC meetings, including next-meeting details and a cross-venue comparison. The Fed/FOMC scope is explicit and distinguishes it from the sports-focused 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?

Provides concrete natural-language use cases such as 'will the Fed cut rates' and 'next FOMC meeting odds'. It does not name exclusions, but the sibling list contains no close alternative, so the guidance is sufficient.

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?

Building on annotations readOnlyHint=true and openWorldHint=true, the description adds useful behavioral context: 'Free, no key', 'live', and the fact that pre-launch S&P 500, Nasdaq 100, and Treasury-yield series are also included. It does not contradict the annotations and adds value beyond what the structured fields alone convey.

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 follows with output details, parameter hints, and example queries. It is longer than strictly necessary, mostly due to an extensive parenthetical list of series, but each section earns its place and the structure is logical.

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

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

With no output schema, the description carries the burden of explaining return content, and it does so thoroughly: open-window status, two-sided mid YES price, close time, target price, settlement condition, and settled-up share over the last 96 windows. Combined with full parameter schema coverage and read-only annotations, an agent has enough context to invoke the tool correctly.

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

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

Schema description coverage is 100%, so the baseline is 3. The description goes slightly beyond the schema by providing concrete alias examples ('eth', 'KXETH15M', 'natural gas') and by clarifying that 'series' selects one market while 'asset_class' filters. This helps an agent map user intent to parameters more reliably.

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 concrete resource (Kalshi 15-minute up-or-down markets) and a clear action: list or filter them live. It enumerates the data returned (open window, YES price, close time, target price, settlement basis, settled-up share), and mentions pre-launch series. This is specific enough to distinguish it from any sibling tool without opening schemas.

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 usage context with example user queries ('what is the ETH 15 minute market doing', 'which Kalshi 15-minute markets are open', 'KXBTC15M price now') and tells the agent to pass 'series' for one market or 'asset_class' to filter. It does not explicitly name alternatives or exclusions, but the intended use cases are clear and actionable.

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 readOnlyHint and openWorldHint annotations already establish that this is a safe, free-access operation. The description adds valuable behavioral context by qualifying the free tier: without a key, only the single largest gap is returned, while email/Pro unlocks more. This prevents an agent from assuming open access means full board access.

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 first several sentences are dense and front-loaded with functional information. However, the final sentence about the public track record is promotional rather than operational and does not help an agent select or invoke the tool, so not every sentence earns its place.

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

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

For a tool with one optional parameter, read-only annotations, and no output schema, the description is largely complete: it states what is returned, the access-tier limits, and the intended query phrasing. It does not define WATCH versus ARB signals in detail, but the essentials needed to call the tool are present.

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

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

The only parameter, minGap, is already fully documented in the input schema, including accepted formats and the default WATCH threshold. The description does not add additional parameter-level meaning, so the baseline score 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 uses a specific verb ('Scan for') and a specific resource ('cross-platform price gaps between Kalshi and Polymarket on the same sports contract'). It lists the exact sports covered and the exact returned fields, making the tool's scope unmistakable and implicitly distinguishing it from generic siblings like scan_mispricings.

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 query phrases that should trigger this tool: 'where is the arbitrage', 'cross-platform price gaps', and 'Kalshi vs Polymarket mispricing'. It does not explicitly state when not to use it or name an alternative tool, but the intended use cases are clear enough for an agent to route correctly.

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

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

The annotations declare readOnlyHint=true, so the safe, non-mutating nature is already covered. The description adds that the result is a dollar stake and a risk rating, but it does not disclose edge cases such as what happens when winProbability is below or equal to the market price, nor what the risk rating values actually mean. This leaves some behavioral ambiguity.

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

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

The description is two sentences with no filler. It front-loads the core computation, then lists inputs and outputs, and ends with concrete query examples. Every sentence earns its place and the structure makes the tool easy to scan.

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

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

For a calculation tool with no output schema, the description does state the outputs ('dollar stake and a risk rating') and all inputs. However, it leaves the 'risk rating' undefined and does not explain behavior when no Kelly bet is warranted, which an agent would benefit from knowing before invoking the tool.

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

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

Schema description coverage is 100%, and the schema already documents each parameter, including accepted formats, defaults, and optionality. The description restates the key parameters but does not add significant new semantic meaning beyond what the schema already provides, so the baseline score 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 opens with a specific verb and resource: 'Compute the optimal Kelly position size for a prediction-market contract.' It clearly lists the inputs (win probability, market price, bankroll, Kelly fraction) and outputs (dollar stake and risk rating), making the tool's function unmistakable even among many 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 explicitly provides user-intent triggers: 'Use for "how much should I stake", "what is my position size", "Kelly sizing for this trade".' This gives clear context on when to invoke the tool. However, it does not mention when not to use it or name any alternative tool, so it falls just short of full exclusion 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 cover the safety profile (readOnlyHint, openWorldHint), yet the description adds real context: free board, no key required, what the three signal classes mean, what each row contains, and that fleet/size detail is gated behind Pro. It omits rate limits, pagination behavior and data freshness beyond a single dated measurement.

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

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

Front-loaded purpose followed by return contents, pricing/measurement context, and trigger phrases, all in a compact block. The Sept 2026 stat and the Pro upsell are slightly promotional but still informative; the trailing keyword list earns its place for retrieval.

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

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

No output schema exists, so the description carries the burden and does describe the return shape (both tickers, both books, gross edge in cents, volume, kickoff, tier). What it leaves unstated is freshness/latency of the scan and result ordering/truncation behavior for the limit parameter.

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

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

Schema description coverage is 100%, so limit/sport/signal/min_edge/min_volume are already documented in the schema. The description hints at 'net-of-fee edge' and row substance but adds no syntax or default guidance beyond what the schema supplies — 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?

Specific verb + resource + mechanism: 'Scan Kalshi college football and NFL spread/total ladders for internal price inconsistencies.' It even defines the signal condition (strikes priced out of order on the same side of the same game), which separates it from generic siblings like find_arbitrage or nfl_ladder.

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 concrete trigger phrasings ('is any CFB ladder mispriced', 'where can I make a market on Kalshi today') and states when it applies, but never names an alternative sibling (find_arbitrage, nfl_ladder, scan_mispricings) or states when NOT to use it, so routing between the several arb/edge tools is left partly to inference.

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

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

Beyond the readOnly and openWorld annotations, the description discloses meaningful access-tier behavior: composite and regime are always free, but category score availability depends on the caller's key level. It does not describe the exact response structure or regime labels, but the access behavior is unusually 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 description is compact, front-loaded with the core output, and each sentence earns its place: what the tool returns, access behavior, and when to use it. There is no fluff or redundancy beyond the intentional sibling clarification.

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 one optional enum parameter, no output schema, and read-only/open-world annotations, the description covers the output content, access limitations, and intended use cases. Nothing essential is missing for an agent to decide whether and how to invoke it.

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

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

Schema description coverage is 100% and the single topic parameter already carries a clear description and enum. The tool description reinforces that NFL is handled elsewhere, but adds little semantic 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 description clearly identifies the tool's output: a US macro-health composite (0–100), a regime call, and six category scores. It also distinguishes itself from the nfl_edge sibling by explicitly stating that NFL edges were moved there.

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 concrete example queries ('how is the US economy', 'macro regime', 'risk-on or risk-off') and explicitly routes NFL-related requests to the dedicated nfl_edge tool, making when-to-use and when-not-to-use clear.

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

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

Beyond the readOnlyHint/openWorldHint annotations, the description discloses the exact return fields (model probability, Kalshi price, edge in percentage points, side), sort order (biggest edges first), the Pro key requirement, and the not_covered behavior for unmodeled tickers with an explicit promise never to fabricate an edge. This is strong behavioral 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 front-loaded with the core value proposition, then each sentence adds a distinct fact: return format, auth requirement, usage triggers, and ticker behavior. The natural-language query list is slightly redundant with the market enum but still earns its place by making the tool's invocation more discoverable.

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

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

For a read-only tool with four optional parameters and no output schema, the description covers outputs, sorting, authentication, market types, ticker-specific behavior, and failure semantics. No critical operational detail appears missing.

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

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

Schema description coverage is 100%, so the baseline is 3. The description adds value by explaining the tickers[] use case — pasting a Kalshi Pro screener watchlist — and noting that it applies to futures/mvp/championship markets. It also preempts a failure mode by stating that unmodeled tickers return not_covered, which is more than the schema provides.

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 defines the tool as surfacing disagreements between the PMP NFL model and live Kalshi prices, listing concrete market categories: game moneylines, season win-total futures, MVP, and championship odds. This scope distinguishes it from broader siblings like scan_mispricings and prop-specific tools like nfl_prop_edge, even without naming them 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?

It gives explicit natural-language usage triggers ('which NFL games are mispriced on Kalshi', 'NFL win total edges', 'NFL MVP value') and a clear tickers[] workflow for checking specific Kalshi markets. It does not name sibling alternatives or state when not to use this tool in favor of another, so it stops short of a 5.

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

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

Even though annotations already mark this as read-only, the description adds meaningful behavioral detail: the model number is only published between 30% and 70% where calibrated, other rungs return the market only, and verdicts like PRICED and PARTIAL are defined. It also states 'Free, no key', giving the agent clear expectations about access and output semantics.

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 dense single paragraph but every sentence adds useful context, from the core resource to calibration caveats to example queries. It is longer than strictly necessary and could be broken into bullets, but it remains focused and front-loaded with the most important scope 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?

With no output schema, the description communicates what the agent will receive (Kalshi prices, distribution, verdict, ranking) but doesn't spell out the exact response shape. It also covers all important operational details for a read-only query tool, so it is reasonably complete for an agent ready to invoke it.

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

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

Schema coverage is 100%, so the baseline is 3, but the description adds real semantic value beyond the schema. It defines the meaning of the 'kind' values (SHAPE, LOCATION, PRICED, PARTIAL) in natural language and maps user intents to parameter combinations via the example queries. This goes beyond the simple enum descriptions in the schema.

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

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

The description names a specific resource (NFL strike ladders on Kalshi) and a specific action (compare Kalshi prices to a probability distribution, producing a verdict). It explicitly lists the covered families (spreads, season wins, player props) and distinguishes itself via the ladder/verdict concept, which sets it apart from sibling tools like nfl_edge or nfl_prop_board.

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

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

The description provides concrete example queries ('where does the model disagree with Kalshi on the Rams spread', 'which win-total rung is mispriced') that clearly signal the intended use case. It stops short of explicitly contrasting itself with sibling tools or stating when not to use it, so it doesn't earn a 5.

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

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

Annotations already establish readOnlyHint=true, and the description adds useful behavioral context: it explains the PWR formula, says the result includes rank and tier, and explicitly says 'Free, no key', which informs auth expectations. It does not detail every output field, but for a simple read-only rating lookup the key behavioral facts are present.

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-loads the core concept, then gives the formula and example queries. The use-case examples earn their place by helping intent matching. It is slightly dense but every sentence contributes 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 read-only, zero-required-parameter lookup tool, the description sufficiently explains what the data means, what is included, and which natural-language intents map to it. It does not have an output schema, but describing rank and tier plus the optional team/tier/limit parameters from the schema gives the agent enough to invoke and interpret results correctly.

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

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

Schema description coverage is 100%, so the parameters are already well documented with types, defaults, and constraints. The description reinforces usage patterns like team-based queries but does not add meaning beyond the schema. A 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 identifies the tool as providing NFL power ratings (PWR) for all 32 teams and defines the metric with a formula. It goes well beyond the tool name by explaining that PWR measures points per game above an average team on a neutral field, and notes that rank and tier are included. It does not explicitly compare itself to sibling tools, but the power-ratings focus is distinct enough among the listed 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 concrete query phrasings that should route to this tool, such as 'best NFL teams by power rating', 'is Baltimore overrated', and 'how good is Kansas City'. This gives an agent clear contextual triggers. It does not state when not to use it or name alternative tools, so it stops short of full routing 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 declare readOnlyHint=true and openWorldHint=true, so the safety profile is already covered. The description adds meaningful behavioral context beyond those: it specifies the temporal scope ('this week'), the requirement of a 'real two-sided book', that the consensus is read 'at that exact strike', that best-price is expressed 'cents per $1 of payout', and that Kalshi prices are 'net of fee'. It also discloses that it is 'Free, no key'. No contradiction with annotations is present.

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 long but information-dense: it front-loads the core value proposition, enumerates the exact output fields, then gives filter options and concrete use cases. Every sentence contributes something meaningful, and the example queries earn their place by showing an agent how to phrase intents. It could be slightly tighter by separating the field list from usage examples, but it remains effective.

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?

Because there is no output schema, the description responsibly enumerates what the tool returns: strikes, book consensus, sportsbook lines, exchange quotes, gap in cents, and best price. It also covers filters, free access, and the key comparison intent. Minor gaps remain: it does not explain how rows are ordered, how filters combine, or what happens when no venues match a strike, but the absence of an output schema is substantially compensated by the detailed field description.

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

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

Schema description coverage is 100%, and every parameter has its own descriptive text, so the schema already carries the full burden for parameter meaning. The description merely paraphrases the filters ('Filter by team, game, player or stat') and adds no parameter-level semantics beyond what the schema provides. This matches the baseline of 3 for high schema 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 identifies the tool as a weekly NFL player-prop price board comparing Kalshi, book consensus, DraftKings/FanDuel/BetRivers, Novig, and ProphetX. It states the specific information returned (strikes, gaps, best price per side), which distinguishes it from most sibling tools by focusing on cross-venue price comparison rather than modeling or player-level analysis. However, it lacks an explicit action verb like 'list' or 'compare', and does not directly contrast with the sibling nfl_prop_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 includes explicit 'Use for' guidance with concrete query examples like 'where is the best price on Puka Nacua receiving yards' and 'is Kalshi cheaper than the books'. This tells an agent when the tool is appropriate. It does not, however, state when not to use it or name alternative sibling tools for edge calculations or player outlooks, leaving some routing to inference.

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

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

Beyond the read-only annotation, the description discloses important behavioral context: the tool is live in-season and opens NFL Week 1, a pro key is required, and every Kalshi prop is an 'X or more' contract. It also explains the call semantics (YES/NO) and what each returned row contains, which is especially valuable without an output schema.

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

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

The description is information-dense with no filler: each sentence adds a distinct fact, the core purpose is front-loaded, and the return payload, lifecycle, auth requirement, and example queries all earn their place.

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

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

With no output schema, the description compensates by explicitly listing the fields returned per row: contract, call, odds, Kalshi price, model projection, edge, and raw over/under inputs. It also covers availability timing, auth requirements, and example queries, making the tool fully usable from the description alone.

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

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

Schema description coverage is 100%, so the schema already documents all three parameters well. The description adds market context and enumerates prop categories, but it does not add meaning to the limit, minEdge, or propType parameters beyond what is already in the schema. Baseline 3 is appropriate.

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

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

The description clearly identifies the resource as NFL player-prop edges comparing the PredictionMarketsPicks projection against Kalshi lines, and enumerates the exact prop types covered. It distinguishes itself from sibling tools by specifying the Kalshi comparison and the row-level output fields, so an agent can select it confidently.

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-case queries such as 'NFL player prop edges', 'best NFL props today', and 'passing yards over under', which tells the agent when this tool is appropriate. It does not name alternative siblings or state when not to use it, so it misses the explicit exclusion part of a 5.

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

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

Annotations already mark it read-only, and the description adds meaningful behavioral details: the spread sign convention, that total is the tested line rather than the projection, that model_total is returned in teams mode, no home-field advantage on nine international neutral-site games, and that no API key is required. This exceeds the annotation baseline.

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 front-loaded: core purpose first, then input modes, then special behaviors and use cases. It is longer than strictly necessary, but every sentence adds either parameter semantics, output context, or invocation 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 read-only calculator with no output schema, the description covers all needed inputs, the outputs an agent can expect (win probability, cover probability, over/under, model_total, model_over_pct, basis), edge cases like neutral-site games, and example queries. Nothing essential is missing.

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

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

Schema coverage is 100%, and the description goes beyond it: it clarifies spread sign from home perspective, explains the total parameter is the line to test rather than the model projection, notes the league-baseline default, and lists accepted team name formats. This materially improves correct 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 opens with a specific verb and resource: turning an NFL point spread and game total into win probability, projected score, cover probability, and over/under probability. It names the underlying model and clearly distinguishes the tool from siblings like nfl_power_ratings by focusing on game-level 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?

It gives concrete input modes (spread+total OR two team abbreviations) and a 'Use for' list with natural-language queries, so an agent knows when to invoke it. It does not explicitly contrast it with sibling tools or state when not to use it, but the use cases provide clear 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?

Annotations already include readOnlyHint=true, and the description adds substantial behavioral context: it is an estimate based on Kalshi’s published risk parameters, not the app’s exact figure; it mentions leverage caps and that the estimate reports when the cap was applied; it discloses 'Free, no key' (no auth). These details go beyond the structured hints and materially set expectations for the tool's output and constraints.

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 then layers supporting context (estimate nature, asset list, usage examples). It is longer than the minimal two-sentence ideal but every sentence contributes: the maintenance-margin nuance prevents misinterpretation, the asset list avoids schema lookups, and the examples act as routing cues. It could be trimmed slightly, but it is not bloated.

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 6 parameters and no output schema, so the description must convey what to expect. It states the outputs (liquidation price, % move, fees, funding), notes the estimate caveat, and explains the leverage cap behavior — all essential for correct invocation and interpretation. It does not specify exact output structure or error handling, but given the absence of an output schema, this is a reasonable level of 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?

Schema coverage is 100% — every parameter (asset, side, leverage, entry, margin, hold_days) has a description in the input schema. The description does not add parameter-level detail beyond the schema; it only provides domain background (maintenance margin vs 100/leverage) that is not tied to a specific parameter. Baseline 3 is appropriate since 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 opens with 'Estimate where a Kalshi perp position liquidates', specifying a clear verb and resource. It enumerates the exact outputs (liquidation price, % move, round-trip fees, expected funding) and explicitly contrasts itself with Kalshi's app (exact figure), which distinguishes it from any sibling tool. The asset list and example queries further anchor its scope.

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

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

The description provides three concrete usage examples ('where does a 5x bitcoin long liquidate on Kalshi', etc.), which tell an agent exactly when to invoke the tool. It does not explicitly name alternative tools or state exclusion criteria, but the examples cover the typical user intent and the estimate caveat implies caution about treating results as exact. This is clear enough for routing, though not exhaustive.

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 that it is 'Free, no key' and 'live', which are useful operational details. It does not mention rate limits or pagination, but given the read-only nature, the added context is sufficient. 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 a single sentence that front-loads the core purpose and lists the data fields, followed by a sentence about the optional parameter and a final sentence with example queries. It is longer than some, but every clause adds information (fields, usage, cost). The structure is logical: what → optionality → when to use. Slightly verbose 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?

There is no output schema, so the description must convey what the tool returns. It lists the exact data fields (price, 24h volume, open interest, max leverage, funding cadence, funding cost since launch) and explains the annualized metric. It also covers the asset filter and the free/no-key access. For a list-style tool with two optional parameters, this is complete. It doesn't describe pagination or default limit behavior beyond the schema, but that's minor.

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

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

Schema coverage is 100% for both parameters, so the baseline is 3. The description adds value by giving concrete examples for asset ('btc', 'gold', 'silver', 'ETH') and clarifying that it accepts 'symbol or name'. It also implies the optionality of asset by saying 'Pass asset for one perp', which clarifies the default behavior (all perps). This goes beyond the schema's minimal 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 the tool returns every Kalshi perpetual future with specific data fields (price, volume, open interest, leverage, funding). It distinguishes itself by explicitly naming the scope and the optional asset parameter, making it clear this is a board for perps, not a single-item tool. The verb is implicit but the resource and function are unambiguous.

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

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

The description provides explicit example queries ('Kalshi perps funding rate', 'how much leverage on Kalshi gold perps', etc.) that directly tell an agent when to invoke this tool. It also notes it's free and requires no key, which clarifies access conditions. While it doesn't name alternatives, the examples and scope make the intended use cases very 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 mark the tool as read-only, and the description adds useful behavioral context: it is free, requires no API key, returns projections in multiple PPR formats, and includes a one-line thesis. It does not explain how the target player is identified given zero parameters, which is a notable omission, but the disclosed content and access model go beyond 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 a dense but purposeful list of distinct output elements followed by concrete example queries. Every clause earns its place, though the colon-delimited enumeration is heavier than strictly necessary. It is front-loaded with the core result and ends with usage examples.

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

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

With no output schema, the description does a good job enumerating return fields and use cases. However, it never clarifies how the agent supplies the player in a zero-parameter call, and it does not address edge cases like invalid or ambiguous player names. For a tool with no structured inputs, this is a meaningful gap.

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

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

There are no parameters, so the schema provides no selection mechanism; the description compensates by making clear the tool is about a single player and by giving query templates with <player> placeholders. Baseline for 0 parameters is 4, and this description adds enough meaning about the implied subject.

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 produces a single player's 2026 fantasy outlook with a clear list of outputs such as projected points, floor/ceiling, ADP, and sleeper/bust status. It is distinguishable from siblings like compare_players and draft_board by its 'single player' framing, though it never explicitly names those alternatives.

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

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

The description gives explicit use cases like 'is <player> a sleeper' and '<player> fantasy outlook 2026', which tells an agent when to invoke it. It does not state exclusions or explicitly contrast with sibling tools, but the example queries are specific enough to route most relevant requests.

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 only readOnlyHint and openWorldHint annotations, the description carries the burden of behavioral disclosure and meets it fully. It explains tie-breaking between Senate and governor races, that prices are never estimated, that all Kalshi contract legs are returned, and notes limitations with 'where provable' and 'where we track them'. This goes well 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 dense but front-loaded, opening with the core purpose and accepted input formats before enumerating return contents and usage examples. Very little is wasted, though the single long list-style sentence is slightly less scannable than a more structured presentation would 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?

For a one-parameter read-only tool with no output schema, the description is operationally complete: accepted inputs, returned data fields, tie-breaking behavior, pricing policy, authentication requirements, and example queries are all covered. An agent has everything needed to select and invoke this 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 schema already provides 100% coverage for the single 'race' parameter, so the baseline is 3. The description adds concrete examples of accepted formats — state name ('Kansas'), code ('KS'), slug ('michigan-governor'), and district ('TX-34') — plus the disambiguation rule for states with multiple races, making parameter semantics clearer than the 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 states a specific verb and resource: 'Live Kalshi odds for one 2026 midterm race' and enumerates Senate, governor, and House races. It also emphasizes 'one race,' distinguishing it from sibling tools like senate_map that cover many races at once.

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 for' examples such as 'who wins the Kansas Senate race' and 'Michigan governor odds', making invocation triggers explicit. It does not name alternatives or state when not to use it, but the examples are sufficient for a single-race lookup tool.

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

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

Annotations already declare readOnlyHint and openWorldHint, so the description's additional disclosure of the Pro key requirement, sorting by absolute edge, and quarter-Kelly sizing adds useful behavioral context. There is no contradiction with the annotations.

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

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

Three short sentences front-load the purpose and output, then cover auth and use cases. There is no filler; every clause contributes 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 simple list-style read tool with two optional, fully documented parameters, the description sufficiently covers return values, ordering, auth requirements, and target use cases. No output schema exists, but the return shape is described clearly enough.

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 reinforces that edges are in percentage points and that results are sorted by absolute edge, but it does not add substantial meaning beyond what the schema already documents for limit and minEdge.

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 opens with a specific verb ('Scan') and resource ('Polymarket contracts'), names the model ('PMP'), and enumerates the output (direction, edge, quarter-Kelly sizing, sorted by absolute edge). It doesn't explicitly contrast with siblings like edge_alerts or base_rate_gap, so it stops short of a 5.

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

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

The description gives concrete query phrasings ('where is the edge today', 'mispriced markets', 'what should I trade') and a hard prerequisite ('Pro key required'). It does not state when-not-to-use or mention alternative tools, so it earns a 4 rather than 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?

Beyond readOnlyHint and openWorldHint, the description discloses key behaviors: results are sorted closest race first, prices are never estimated, unpriced seats return null, and the call requires no key. It also clarifies the price semantics (Democrat-win implied probability where provable, otherwise favorite contract in cents), which is exactly the kind of ambiguity that could otherwise cause mis-inference.

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 information-carrying, leading with the map scope and moving through fields, ordering, and edge-case behavior before closing with query examples. It is slightly long, but nearly every clause adds distinct data an agent needs; there is no filler or tautology.

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 input schema and no output schema, the description carries the full burden, and it covers return fields (holder, role, rating, forecaster bands, price, URL, hub), ordering (closest race first), and null behavior. The examples and no-key note make the tool callable without further documentation.

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

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

The tool takes zero parameters, so there is nothing for the description to map to schema fields; the baseline for no-parameter tools is appropriate. The phrases 'in one call' and 'Free, no key' usefully signal that no arguments or authentication are 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 names a specific deliverable ('2026 U.S. Senate map in one call') and enumerates its contents: each seat holder, role, structure rating, forecaster bands, Kalshi price, and per-seat URL. It is distinguishable from siblings like race_odds by being explicitly the whole-map aggregate rather than a single race or generic odds scan.

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 'Use for' section lists concrete triggers such as '2026 Senate map', 'which Senate seats are toss-ups', and 'what does the market say about Senate control race by race', giving an agent clear guidance on when to call this tool. It does not name sibling tools as alternatives or state when not to use this tool, so it stops short of a full when/when-not guide.

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 that the complete list is free, requires no key or email, and covers standard, half-PPR, and full-PPR formats. This gives useful access and scope context, although it does not mention rate limits or output formatting.

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 main function and key differentiators are front-loaded, with the free-access note and example searches following logically. The list of five example queries is slightly repetitive but each example adds value for intent matching, so the overall structure is 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?

For a zero-parameter, read-only list tool with no output schema, the description covers the model context, scoring formats, filter concept, access requirements, and example user intents. It is missing explicit details about the returned fields, but this is a minor gap given 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 has zero properties, so the baseline is 4, but the description claims 'Filter by position or draft round' without any corresponding parameters. This is misleading: an agent following the schema cannot pass these filters, creating a contradiction between the described capability and 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 identifies the biggest gaps between the PredictionMarketsPicks model and consensus ADP for 2026, differentiating sleepers and busts. It is specific about the resource and output, and the context of fantasy football and draft cost distinguishes it from sibling tools like adp_market_gaps or compare_players.

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

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

The description provides explicit example search intents—'fantasy sleepers 2026', 'draft busts to avoid', 'undervalued players'—which tells an agent when to use this tool. It does not list exclusions or name alternatives, but the use cases are clear enough for routing.

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

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

Annotations already provide readOnlyHint=true and openWorldHint=false, and the description adds meaningful behavior beyond them: the pick/alternatives are free with no key or email, the Pro tier adds reasoning, and the board is estimated from pick_number when drafted is omitted. This sets expectations about cost, tiering, and fallback logic, which the annotations do not cover.

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 front-loads the purpose and usage, then gives input and output details in a compact, readable format. The line about the pick/alternatives being free is useful pricing/access context, though slightly promotional. One or two sentences could be tightened, but there is no material waste.

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

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

The description covers what the tool does, the for the expected use case, the input parameters, the output shape, and the fallback when drafted is omitted. It lacks precise output schema details such as reason wording or team names, but for a simple read-only recommender it is complete enough for an agent to call correctly.

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

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

The input schema has no documented properties, so the description becomes the only semantic source for parameters. It names three inputs (roster, pick_number, drafted), explains the type of each, and describes the default behavior when drafted is omitted. This fully compensates for the schema gap and exceeds the baseline for zero-parameter schemas.

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 main action: it recommends the single best player to draft given roster and pick number, reasoning value versus positional need. It is specific and actionable, but does not explicitly differentiate from sibling tools such as best_available or draft_board, so it earns a 4 rather than a 5.

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

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

The description provides explicit trigger phrases and situational guidance, saying this should be preferred mid-draft when the user asks questions like 'who should I take' or 'who do I draft.' It lacks a clear when-not-to-use or explicit alternative mapping, but the context is sufficiently clear for selecting this tool over ambiguity.

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