Prediction Markets Quant

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

Annotations already mark it readOnly and closed-world. The description adds valuable operational context beyond that: all 154 gaps are free with no key or email, and the Pro tier adds judgment per row. It also gives a concrete example of what a gap looks like. It doesn't cover every detail, but it exceeds the minimum for a read-only lookup tool.

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

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

Four sentences with the core behavior first, followed by a concrete example, access notes, and query phrases. It is efficient and front-loaded. A bit of repetition exists between the platform list and the 'who falls on ESPN vs Sleeper' example, but no sentence is wasted.

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

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

For a read-only, optional-parameter lookup tool, the description is complete: it defines the data, the platform scope, the use cases, access requirements, and the filtering option. With all three params documented in the schema and no output schema needed for invocation, nothing essential is missing for an agent to select and call the tool correctly.

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

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

Input schema covers 100% of parameters with descriptions for limit, scoring, and position, so the baseline is 3. The description's 'Filter by position' line just restates the schema. The free/154-gap note does not add parameter-specific meaning.

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

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

Description opens with a specific verb and resource: 'Find the 2026 fantasy players whose Average Draft Position swings most between platforms.' It clearly identifies the unique data source (consensus vs ESPN, Sleeper, Yahoo, Underdog) and the core concept of platform-specific ADP gaps. It does not explicitly name or exclude sibling tools, but the focus on cross-platform ADP arbitrage is enough to set it apart.

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 for' intents: 'ADP differences by platform', 'where is a player cheapest', 'ADP arbitrage', and 'who falls on ESPN vs Sleeper'. This tells an agent when to choose the tool. It does not discuss alternatives or when not to use it, so it stops short of a 5.

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

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

Annotations already declare readOnlyHint=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?

The description goes beyond the readOnlyHint annotation by explaining that it returns the posterior probability and a per-step chain, and that it can process multiple evidence items. The word 'update' refers to a mathematical calculation rather than a persistent state change, so there is no contradiction with the readOnly 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?

Three sentences cover the main operation, input/output mechanics, and usage triggers without redundancy. The description is front-loaded with the core Bayesian update purpose and each subsequent sentence adds a distinct, useful layer.

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 stateless calculator with a readOnlyHint and fully documented schema, the description gives enough to invoke correctly: what to pass, how evidence is modeled, and what comes back. It could detail the structure of the per-step chain, but that is secondary to calling the tool successfully.

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 input schema already fully documents prior formats, evidence structure, and likelihood semantics. The description repeats the evidence model at a high level but adds no parameter-level meaning beyond what the schema provides, so the baseline of 3 is appropriate.

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

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

States a specific action ('update a prior probability') with a precise mathematical method (Bayes theorem) and clearly describes the input/output relationship. The 'Use for' phrases ('posterior probability', 'how does this news change the odds') make it easy to distinguish from the conversion and EV tools in the sibling list.

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

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

Explicitly provides user-intent triggers such as 'update my estimate with new information' and 'posterior probability', which helps an agent decide when to select this tool. It does not name specific sibling alternatives or state when not to use it, but the context is clear enough.

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

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

The annotations declare readOnlyHint=true, and the description implicitly matches that by framing the operation as returning information. It adds useful context about the free vs. Pro data tiers (bonus boom/bust odds and positional tier breaks), which helps set expectations about result richness. It doesn't go into edge cases like invalid player names or partial pool updates, but given the read-only annotation, this is an acceptable level.

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

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

The main behavior is front-loaded in the first sentence, followed by brief notes on free/pro output, usage guidance, and input clarification. Each sentence has a purpose, though the 'Input: pick_number, drafted (names already gone)' line is largely redundant with the schema and could be trimmed. Overall it is compact and scannable.

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

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

With no output schema, the description adequately describes the return contents: projection, ADP, value flag, and biggest model value, plus optional Pro extras. It also covers the required input context (pick number, drafted players) and the season/format scope ('2026, any scoring format'). Given the tool's moderate complexity and read-only nature, this is sufficient for an agent to invoke and interpret results.

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

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

Schema description coverage is 100%, so the schema already documents all six parameters, including pick_number, drafted list, scoring, platform, roster, and teams. The description only reiterates pick_number and drafted ('Input: pick_number, drafted (names already gone)'), adding no new semantic detail beyond the schema. Baseline 3 is appropriate.

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

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

The description starts with a specific verb and resource: 'given the current pick number and the players already drafted, return the best players still on the board.' It also lists concrete output contents (projection, ADP, value flag, biggest model value), making the tool's function unmistakable and distinct from generic drafting tools. The title and phrase 'Prefer this mid-draft...' further reinforce the specific use case.

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 prefer this tool: 'Prefer this mid-draft when the user asks "who is the best available", "who should I take next", "best player left".' This gives clear context for invocation. It does not explicitly mention when not to use it or name alternative sibling tools, but the guidance is strong enough for most routing decisions.

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?

Beyond the readOnlyHint=true annotation, the description discloses rich behavioral detail: optional offeredOdds changes the output, without it no verdict is returned, and the tool emits EV %, a negative-correlation-trap flag, and a 7-tier verdict list. It also warns against grading EV off the product of leg prices, which is valuable non-obvious behavior.

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

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

The description is dense but well-organized, front-loading the core purpose before optional-input behavior and use cases. Every major sentence adds information, though the track-record provenance sentence is slightly tangential to correct 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 still explains what the tool returns in both invocation modes: fair-value + band alone, or EV %, flag, and verdict when offeredOdds is provided. It covers inputs, optional behavior, common misuse, and use-case triggers, making it complete enough for an agent to invoke correctly.

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

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

Schema description coverage is 100%, and the schema already documents legPrices, offeredOdds, and trueWinProbability clearly. The description mostly restates those meanings, adding only the warning about not using the product of leg prices as EV. Since the schema carries the parameter documentation, a baseline of 3 is appropriate.

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

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

The description opens with a specific verb and resource: 'Grade a same-game combo ... on a prediction market against its fair value.' It clearly distinguishes this tool from generic edge/EV tools by focusing on multi-leg combo positions, fair-value odds bands, and a 7-tier verdict. The scope is unambiguous.

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

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

The description gives explicit use cases: 'is this combo worth it', 'grade my parlay quote', and 'same-game combo value'. It also explains when to pass offeredOdds and what happens when omitted. However, it does not name sibling tools or state when a different tool should be used instead, leaving some alternative-routing to inference.

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

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

Annotations already declare readOnlyHint: true and openWorldHint: true, so the description need not re-state that this is a read-only market lookup. The description adds useful behavioral context: the 'Pro key required' requirement, the behavior that only modeled strikes return a signal, the explicit 'never a fabricated edge' promise for unmodeled tickers, and the return-value composition as a trade ticket. It does not disclose rate limits, latency, or what happens if no edge exists today, but those are secondary gaps. Bar is lower given annotations, so a 3 is fair.

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 dense paragraph but front-loads the core capability in the first clause and packs each subsequent phrase with actionable information: output ticket fields, pro requirement, query phrases, and ticker filtering semantics. It is somewhat long, but every clause earns its place; there is no filler. The only minor issue is the mid-description parenthetical about screening and the ''is there a commodity edge'' phrase could perhaps be tightened, but the density is justified.

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

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

Given that there is no output schema, the description compensates well by enumerating the trade ticket fields (entry side/price, resolve criterion, model probability, edge, confidence tier, quarter-Kelly sizing). It also covers the pro-key requirement and error behavior for unmodeled tickers. It does not specify what happens when there is no edge for the chosen commodity, whether both commodities can be queried in one call, or how the 'quarter-Kelly sizing' should be interpreted without a bankroll input; these are modest gaps for a read-only signal tool with openWorldHint.

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 description adds even more semantic value beyond the schema. For the tickers parameter it explains that full market or 3-segment event tickers both work, that up to 25 are accepted, that unmodeled tickers return not_covered rather than invented data, and gives the concrete use-case of pasting a Kalshi Pro screener watchlist. For commodity it enumerates the two valid values and associates them with the underlying Kalshi markets (KXSILVERW and KXBTCD). This exceeds the schema's 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 clearly names the tool as returning the highest-conviction silver or bitcoin trade signal from the PMP edge model, with a specific list of output fields: entry side and price, resolve criterion, model probability, edge, confidence tier, and quarter-Kelly sizing. It also disambiguates from sibling tools by focusing on commodity/silver/bitcoin signals, which none of the listed siblings (which are mostly NFL/fantasy/player-focused) cover. The inclusion of natural-language trigger phrases like 'silver edge today', 'bitcoin trade signal', and 'is there a commodity edge' makes it immediately clear what the tool does and how to invoke it.

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: for silver or bitcoin edge queries, and provides example phrasings. It also explains a specific use case for the optional tickers parameter: paste a Kalshi Pro screener watchlist to check specific markets, and clarifies that the signal is only returned if it matches the strike PMP is modeling. It does not name an alternative tool, but the sibling list contains no other commodity edge tool, so the when-to-use guidance is sufficient for selection and there is no misleading alternative.

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, and the description adds useful context: it is free/no-key, supports standard/half-PPR/full-PPR, and returns a recommendation plus market-value assessment. No hidden destructive behavior, authentication requirement, or rate-limit concern is left undisclosed.

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 efficient: the main purpose and outputs come first, followed by the access note and concrete example phrasings. The long dash-separated clause packs many output concepts together, but it remains scannable and contains no filler.

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

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

For a read-only comparison tool with three well-documented parameters and no output schema, the description provides enough context: player count, scoring formats, result type, and sample user queries. It could be stronger by explicitly explaining how it relates to overlapping siblings such as best_available or who_do_i_draft.

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 players, scoring, and platform are already fully documented with defaults and enum values. The description does not meaningfully expand on parameter-level semantics, but it does not need to because the schema carries that weight.

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 ('Compare') and resource ('2–4 players') and clearly frames the fantasy draft context, while listing concrete outputs like projection, ADP, floor/ceiling, recommendation, and value flag. It does not explicitly differentiate itself from sibling tools like player_outlook or who_do_i_draft, so it misses the top score.

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 query patterns such as 'who should I draft, A or B' and 'compare A and B', giving an agent clear trigger conditions for selecting this tool. It does not include when-not-to-use guidance or point to a specific alternative tool when the query is off-target.

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?

Annotations already mark the tool as read-only, and the description adds access context: the full ~330 player board is free with no key, email, or signup. It also clarifies that boom/bust week odds and tier breaks are 'Pro' additions, setting expectations about what the baseline output contains.

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 function is front-loaded, and each subsequent sentence adds value: scoring formats, output fields, position filter, free access, and example queries. The all-caps promotional phrase is slightly heavy but not excessive for a tool that doubles as a product page.

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 compensates by naming the returned fields (projected points, ADP, draft round, sleeper/bust flag). It also covers access and intended queries; it is less explicit about exact response shape, but the parameter schema covers limit and default behavior.

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

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

Schema description coverage is 100%, so the baseline is 3. The description reinforces the scoring, position, and limit concepts, but for teams and platform the schema already carries the full meaning; the description adds little beyond what the schema documents.

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

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

The description clearly identifies a fantasy football draft board resource with ranked players, projection/ADP blend, output fields, and position filtering. It is specific enough to distinguish from generic ranking tools, though it does not explicitly differentiate it from siblings like best_available or sleepers_and_busts.

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

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

The closing 'Use for' list gives concrete example queries such as 'fantasy football rankings 2026' and 'best available by position', making intended use clear. 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?

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?

Annotations already provide readOnlyHint=true, but the description adds valuable behavioral context: it is free and requires no key, it details the contents of the explanation (factor by factor), and explicitly states what the projection does NOT model (injuries, camp news, schedule). This goes well 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 well-structured and front-loaded with the core purpose. The detail on factors, explicit examples, non-modeled items, and the sibling alternative is dense but every sentence serves a purpose. The length is justified by the tool's complexity.

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 must convey what the agent can expect. It enumerates the output components (projection, floor/ceiling band, boom/bust week shape, three ranks, model-market edge), states exclusions, cost/auth, and example queries. An agent has sufficient 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?

Schema description coverage is 100% and both scoring and platform have clear enum-based descriptions. The tool description does not add parameter-level meaning beyond the schema, but it does reinforce the context (e.g., platform presets, overrides). Baseline 3 is appropriate when schema carries the parameter documentation.

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

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

The description opens with a specific verb+resource: 'Explain WHY the 2026 draft board ranks a player where it does, factor by factor.' It enumerates the exact factors and the three distinct ranks, which clearly distinguishes it from related tools like player_outlook or draft_board. No ambiguity about what this tool does.

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

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

The description provides explicit trigger phrases ('why do you have <player> there', 'explain <player> ranking') and names the alternative (player_outlook) for when the user wants a plain outlook or verdict rather than reasoning. This gives an agent clear routing logic.

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?

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?

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?

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 flag read-only, and the description adds value by disclosing the model source, stating 'Free, no key' (no auth needed), and explaining the two mutually exclusive input paths. It doesn't mention rate limits or conflict behavior when both input modes are supplied, but the essential behavioral context beyond the readOnlyHint 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 tight and front-loaded. The first sentence states the core transformation, the second covers input modes, and the final fragment gives the auth note and concrete use cases. No sentence is wasted.

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

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

For a stateless calculator with no output schema, the description covers model, inputs (including name variants for teams), output types, and auth requirements. It does not specify output units or behavior when both input branches are provided, but the core information needed for correct invocation is 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?

Since schema description coverage is 100%, the schema already documents each parameter. Still, the description adds semantic value by making the OR relationship between spread/total and homeTeam/awayTeam explicit, reinforcing the home-favored negative sign convention with the -6.5 example, and noting that total is optional.

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 concrete verb ('Turn') tied to a specific resource (NFL point spread and game total) and enumerates the exact outputs: win probability, projected score, cover probability, and over/under probability. It also distinguishes the tool from sibling NFL tools by naming the PredictionMarketsPicks scoring-margin model and the two alternate input modes.

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

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

The description provides clear example queries ('what does a -7 spread mean', 'who wins Chiefs vs 49ers', 'NFL score prediction') that signal exactly when an agent should reach for this tool. It does not, however, name sibling tools or explicitly state when not to use it, so it stops short of full alternative/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 mark this as read-only, and the description adds useful context by stating it is 'Free, no key', which informs the agent that no authentication setup is needed. It also clarifies that sleeper/bust labels come from 'the model', setting expectations about automated judgment. There is no contradiction with the readOnlyHint 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 front-loaded with the core purpose and a detailed list of outputs, followed by a concise usage clause. It is somewhat long, but every sentence contributes meaningful information, especially given there is no output schema. The structure is logical and easy to parse.

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

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

For a tool with no output schema, the description compensates well by enumerating the fields returned: projections, floor/ceiling, boom/bust odds, ADP, positional rank, and thesis. Parameter details are covered by the schema. Minor gaps like error behavior for unknown players or ambiguous names are not addressed, but the core calling context is sufficiently 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 parameters are already well documented. The description mentions scoring formats and player names but adds little beyond the schema. A baseline score of 3 is appropriate because the schema carries the semantic weight.

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 a single player's 2026 fantasy outlook and enumerates specific outputs such as projected points, floor/ceiling, ADP, and sleeper/bust tags. It avoids being a tautology and gives a strong sense of what the tool returns. However, it lacks an explicit action verb like 'returns' or 'gets', and sibling differentiation is only implicit through the 'single player' phrasing.

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 such as 'is <player> a sleeper' and '<player> fantasy outlook 2026', which tells an agent when this tool is appropriate. It does not explicitly mention alternatives or when not to use it, so it falls short of full exclusionary guidance. Still, the usage context is 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?

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?

Annotations already mark readOnlyHint=true. The description adds valuable behavioral context: the complete list is free with 'no key, no email,' the list is based on 2026 standard/half-PPR/full-PPR, and it covers both sleepers and busts. It does not mention pagination, response size, or that openWorldHint=false, but for a read-only list tool the added context is meaningful.

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

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

The description is compact and front-loaded with the key value proposition: model-vs-ADP gaps. The search-query examples at the end are slightly repetitive but serve as useful usage triggers. Overall it earns its sentences without bloat.

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

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

For a read-only list tool with 100% schema coverage and no output schema, the description covers the core scenario: what the tool returns, what filtering exists, and what the data model is (2026, model vs ADP). It could mention that results are for 12-team default or how scoring/platform defaults interact, but those details are already partly in the schema. The absence of output schema is mitigated by the clear description of the list contents.

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

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

Schema description coverage is 100%, so all five parameters are already documented in the schema. The description adds framing around the parameters ('draft round', 'position') and connects them to the tool's core purpose, plus clarifies formats like half-PPR/PPR. It compensates slightly beyond schema, but mostly relies on the schema's already-rich per-parameter descriptions.

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

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

The description uses a specific verb ('Filter' is the action; the tool returns lists of sleepers/busts), names the exact resource ('PredictionMarketsPicks model vs consensus ADP for 2026'), and clearly distinguishes itself from siblings by emphasizing a complete free list of model-vs-ADP gaps. It also gives concrete search-query examples that make the purpose immediately recognizable.

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

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

The description says what the tool is for ('fantasy sleepers 2026', 'draft busts to avoid', 'undervalued players') and states the filtering options ('Filter by position or draft round'). It does not explicitly say when not to use it or name a sibling alternative, but the query examples effectively position it against other fantasy tools. Lacks an explicit exclusion like 'for ADP itself, use adp_market_gaps instead.'

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

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

The description adds meaningful behavior beyond the readOnlyHint annotation: the tool is free with no key or email, Pro adds reasoning, the board is estimated from ADP when 'drafted' is omitted, and the return is one pick plus a one-line reason. These disclosures help an agent set user expectations and choose invocation strategy. 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 information-dense but well organized: main purpose first, then pricing/pro model, then usage triggers, then input summary, then output summary. Every sentence contributes something needed for correct invocation or expectation setting.

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

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

Given the tool has no output schema, the description correctly covers what is returned. It also covers the core input semantics, the optionality of 'drafted', estimation behavior, usage timing, and free/pro behavior. The schema handles parameter validation details, so no critical guidance is missing for an agent to call this correctly.

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

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

Schema coverage is 100%, so the baseline is 3. The description adds semantic value by explaining 'roster (names on their team)', 'pick_number', and the optional 'drafted' parameter's fallback behavior. It doesn't restate teams/scoring/platform details, but the schema already documents those thoroughly.

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 and resource: 'Recommend the single best player to draft right now' using roster, pick number, and positional need versus value. This clearly sets it apart from sibling tools like draft_board or compare_players, which focus on broader lists or player-to-player 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?

It gives explicit invocation context: 'Prefer this mid-draft when the user asks "who should I take", "who do I draft", "what do I need"'. It does not name specific alternative tools or say when not to use it, but the trigger language is clear and actionable.

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