Prediction Markets Quant

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

Annotations already declare readOnly, non-destructive, closed-world, so the safety profile is covered. The description adds genuinely non-obvious traits: results are sorted widest-first, the call is free, and ADP gaps will not return until the 2027 offseason — a caveat that prevents the agent from mis-selecting this tool for an ADP request based on its name. Return format/pagination behavior is not described.

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

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

Two compact sentences with zero filler; the season/scope constraint is front-loaded before the ADP caveat. Every clause carries information an agent needs.

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 should carry the return-shape burden, and it partially does via ordering and scope. Parameters are fully covered by the schema, and the seasonality caveat closes the largest ambiguity. Missing only a note on what fields/columns a gap row contains.

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

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

Schema coverage is 100%: limit (default 15, clamped at 50) and position (with FLEX semantics) are fully documented in the schema. The description only echoes the position filter and adds "widest first" ordering, adding marginal value beyond structured fields. Baseline 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?

Names a concrete resource (Kalshi vs book-consensus gaps on this week's NFL props) and states ordering and filtering scope, so the agent knows exactly what comes back. It does not explicitly contrast itself with close siblings like nfl_prop_edge or scan_mispricings, leaving the agent to infer the distinction. The title/name mismatch (adp_market_gaps vs a props tool) is resolved only by the parenthetical caveat.

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 leading "In season:" implies a usage window, but no alternative tool is named and no explicit when-not condition is given beyond the ADP caveat. The agent can infer this is the current-season props gap tool, but routing against nfl_prop_edge/scan_mispricings is left to guesswork.

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, destructiveHint=false, and openWorldHint=false, so the safety profile is covered. The description adds value by disclosing the return payload — gap in percentage points, a signal, and sample-size quality — which matters since no output schema exists.

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

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

Two sentences, front-loaded with the triggering questions before the mechanics, with no filler. The nested quotation marks are slightly awkward but don't impede parsing.

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 compute tool with no output schema, the description adequately covers inputs, the identifier-or-value choice, and the shape of the result. It doesn't clarify what happens when marketPrice is omitted despite zero required parameters, a minor 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?

Schema description coverage is 100%, so the baseline is 3; the schema already documents baseRateId enums, marketPrice input formats, and baseRateValue ranges in more detail than the description. The only added meaning is the either/or relationship between baseRateId and baseRateValue.

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 and resource: 'Compares a market price with the historical base rate for a class of events,' and enumerates the outputs (gap in pp, signal, sample-size quality). That scope is clearly distinguishable from siblings like calculate_ev, kelly_size, or convert_probability, which handle different computations.

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?

Gives explicit user-phrasing triggers ('how does this price compare to history', 'is the market ignoring the base rate') that map a real question to this tool. It stops short of naming alternatives or stating when-not to use it, e.g. versus calculate_ev.

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, destructiveHint=false and a closed-world scope, so safety is covered. The description adds genuine behavioral context beyond that: evidence items are applied sequentially and the response contains the posterior plus the per-step chain, which matters because there is no 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?

Two sentences, front-loaded with the computation and its return value, followed by trigger phrasing. Every clause carries information; nothing is padding.

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 correctly names what comes back (posterior and per-step chain), and the input schema fully documents both parameters. It does not address error or edge behavior (e.g. contradictory evidence, 0/100 likelihoods), which keeps it from a 5.

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 is unusually rich, documenting accepted formats (55, "55%", "55¢", "$0.55", 0.55, American odds) and the 0–100 scale. The description only restates the evidence likelihood semantics, so it adds little beyond the schema and 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?

States a specific verb (update) and resource (prior probability) plus the method (Bayes theorem) and the output (posterior plus per-step chain). This is clearly distinguishable from siblings such as convert_probability or calculate_ev, which do different math on different inputs.

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...' clause supplies three concrete natural-language triggers that map cleanly onto this tool rather than its siblings. It gives no explicit exclusions or named alternatives (e.g. when to prefer base_rate_gap), 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, destructiveHint=false, openWorldHint=false, so the safety profile is covered. The description adds two useful non-schema facts: the tool is only meaningful 'in season' and it is 'free.' It says nothing about pagination behavior or how many rows come back by default, so the added value is modest.

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?

A single tight sentence with the seasonality caveat front-loaded and the 'Free' note trailing. Fragmented punctuation ('In season:' / 'Free.') but no wasted words and the core criterion is stated early.

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 more of the burden and it does convey the gist of the result set (price strikes where Kalshi and consensus diverge by 5¢+). It does not describe the row shape (columns, prices shown, ordering) which a 2-param analytical tool would benefit from. Adequate but with clear gaps.

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

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

Schema description coverage is 100% — both `limit` (with its 50-row clamp) and `roster` (user-team prioritization) are fully documented in the schema. The description adds no parameter meaning beyond that, so the baseline of 3 is correct.

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 (this week's NFL props) and a precise criterion (strikes where Kalshi and book consensus are 5¢+ apart), which tells the agent exactly what the tool surfaces. It is not verb-led and does not explicitly distinguish itself from close siblings like nfl_prop_edge, scan_mispricings, or nfl_prop_board, but the 'Kalshi vs book consensus' angle is distinctive enough to separate 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 'In season:' prefix gives a genuine applicability condition (NFL season only), which is more than most siblings offer. However, it never names an alternative tool or states when to prefer nfl_prop_edge / nfl_prop_board instead, so the routing decision is left 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, destructiveHint=false and openWorldHint=false, so the safe, side-effect-free nature is covered structurally. The description adds useful domain scope by tying the tool to Kalshi and Polymarket prices and previews the verdict output, but says nothing about rate limits, accuracy assumptions, or edge cases (e.g. price at 0/100).

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

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

Two tight sentences: the trigger/question framing is front-loaded, followed by the inputs and the returned outputs. No filler, no repetition of the 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?

With an output schema present the description need not explain the return payload, and with 100% schema coverage it need not document parameters. It covers purpose, trigger, and output shape. The remaining gap is cluster-level: no pointer to kelly_size for follow-on position sizing.

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 schema descriptions already enumerate every accepted input format (55, "55%", "55¢", "$0.55", 0.55, American odds). The description only paraphrases this as "in cents and your own probability", which is actually narrower than the schema. Baseline 3 is correct when the schema carries the semantics.

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

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

The description states a specific function: take a market price plus the user's own probability and return the % EV edge and a BUY/SELL/SKIP read. That is a clear verb+resource with an output preview. It does not distinguish itself from the related sibling kelly_size, which an agent might reasonably confuse it with.

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?

"Use for 'is this contract mispriced' and 'what is my edge'" gives an explicit when-to-use trigger in the user's own vocabulary. It offers no exclusions and never names the obvious downstream alternative (kelly_size for sizing once edge is known), so sibling routing is left 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/openWorldHint=false, so the bar is lower; the description still adds real behavior — automatic correlation of the joint, EV/verdict grading when offeredOdds is supplied, and the note that it's free. It doesn't disclose error behavior or leg-count limits beyond the schema, but the workflow outcomes are well conveyed.

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-loads the two trigger phrases and then the two invocation paths in three dense sentences with examples. Slightly packed but every clause carries routing or format information; 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 complex 10-parameter, zero-required, no-output-schema tool, the description covers both input modes, their mutual exclusivity, and the graded outputs (fair band, EV, verdict). It leaves the exact response shape and failure modes unstated, but that's a minor gap for an exploratory pricing tool.

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

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

With 100% schema coverage the baseline is 3, but the description adds genuine meaning: nflGame accepts 'NYG-LAR' or 'Giants vs Rams', legPrices is 'used only for the theoretical assemble ceiling', and both legPrices and trueWinProbability should be omitted when using nflGame+legIds. That sequencing context is not 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?

States a specific verb and resource ('price a same-game NFL combo') and immediately names the value proposition ('with the correlation done for you'). This cleanly separates it from generic siblings like calculate_ev or ladder_arb, which don't do correlation-aware same-game joint pricing.

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 routes two workflows: (a) pass nflGame to list legs, then legIds to price, or (b) pass legPrices + trueWinProbability for a fair band and add offeredOdds for EV. It stops short of naming sibling alternatives (e.g. when to prefer calculate_ev or nfl_prop_edge), but the conditional branches are clearly stated.

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

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

Annotations already establish readOnly/destructive=false and openWorld, so those add nothing here. The description goes beyond them by disclosing the Pro auth requirement (sign in with PredictionMarketsPicks or a Pro API key) and the not_covered fallback ('never a fabricated edge'), which are meaningful behavioral facts.

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 trigger phrasings and commodity list are front-loaded, and the auth caveat is placed last. It is slightly verbose in enumerating the ticket fields, but each clause carries 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?

With no output schema, the description carries the return-value burden and does so by listing the ticket fields (side, entry price, resolve criterion, probability, edge, tier, Kelly size). Auth and watchlist behavior are covered; only deeper edge/model detail is left out, which is acceptable.

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 both parameters are already fully documented in the schema, including the watchlist semantics and not_covered behavior. The description's restatement that commodity is 'needed for a real answer' adds little beyond what the schema provides, so the baseline 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 states a specific resource (the Kalshi gold/silver/WTI/bitcoin strike with the largest PMP model edge) and enumerates the returned ticket fields, so an agent knows what it retrieves. It does not, however, name or differentiate from siblings like calculate_ev or kelly_size, leaving that to inference.

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 supplies trigger phrasing ('gold edge today', 'oil or bitcoin trade signal') and notes tickers[] for a watchlist, giving implied usage context. But it offers no when-not guidance and never names an alternative sibling tool, so routing is left implicit.

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, destructiveHint=false and openWorldHint=false, so the safety profile is covered. The description adds genuinely useful behavioral context beyond that: it discloses the shape of the returned comparison (strikes, best price per side across venues, probability where published, ranked verdict), which matters because there is no output schema. It omits auth/rate-limit details, keeping it at 4.

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 output summary is front-loaded in a single dense sentence, followed by an immediately actionable 'Use for' set of examples. It is slightly long but every clause (outputs, then trigger phrases) 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 small 3-parameter, no-output-schema tool, the description supplies the return-value picture an agent would otherwise lack and covers the temporal scope. The scoring/platform parameters are left entirely to the schema, but that is acceptable given full description coverage there.

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 schema already documents players, scoring and platform. The description reinforces the 2–4 player bound and the 'this week' temporal scope but adds no syntax or format detail beyond the schema. Baseline 3 is correct when 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?

States a specific verb (compare), resource (2–4 NFL players this week) and enumerates exactly what the comparison returns: each Kalshi prop strike, best price per side across venues, model probability, and a ranked verdict. This is detailed enough that an agent can distinguish it from siblings like explain_prop or nfl_prop_edge without opening a schema.

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' clause supplies four concrete query patterns ('<A> or <B> this week', 'compare <A> and <B> props', 'who has the better prop...', '<A> vs <B> receiving yards') that clearly map user intent to this tool. It stops short of naming a competing sibling as the alternative or stating when-not to use it, so it lands at 4 rather than 5.

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

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

Annotations already declare readOnlyHint=true, openWorldHint=false and destructiveHint=false, so the bar is low. The description still adds real behavioral context beyond them: the output always contains all three representations, and American odds use the no-comma convention (+441 or -200). It does not restate return format in detail, but an output schema exists so that is not required.

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, front-loaded with purpose, then output convention, then trigger examples. No filler, and the critical formatting caveat is parenthetical rather than buried. The quoted example phrases are slightly redundant with the purpose sentence, keeping this just below a 5.

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?

A pure two-parameter, read-only converter with an output schema, full schema description coverage and safety annotations. The description covers what it does, what comes back, the input convention quirk, and when to reach for it — nothing an agent needs in order to call it correctly 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%, so the baseline would be 3. The description earns above baseline by explaining the no-comma American convention and illustrating accepted input strings ('+150', '62%', '2.5'), which clarifies the number-or-string typing in the schema. It does not, however, add anything not already implied about the range or enum semantics of `format`.

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

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

The description names a specific verb (Convert) and the exact resources (implied probability, American odds, decimal odds), and states the round-trip behavior (give one, get all three). An agent can immediately distinguish this from calculate_ev or kelly_size, which compute value or stake rather than reformat an odds figure.

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 trigger phrasings ('what is +150 as a probability', 'convert 62% to American odds', 'decimal to implied odds'), which is strong positive routing. It stops short of naming a sibling as the alternative or stating when-not to use it (e.g. if you want expected value, use calculate_ev), so it is clear context rather than full when/when-not 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 declare read-only, closed-world, non-destructive behavior, so the safety profile is covered. The description adds real context beyond that: cost ('Free'), seasonal availability ('In season'), and that the draft-board variant is unavailable until 2027 — all useful for deciding whether to call it.

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?

Compact and front-loaded: the rankings concept leads, with clarifying parentheticals for cost and draft-board availability. Dense but not wasteful, though the 'plus anytime-TD price' clause could sit in a cleaner position.

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 usefully sketches the returned content (median market prices for passing/rushing/receiving yards plus anytime-TD). It leaves the exact row/field shape unstated, but for a two-parameter read-only board that is a minor 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?

Schema description coverage is 100%, with both limit (default 15, clamped at 50) and position (enum including FLEX) fully documented in the schema. The description adds nothing about parameter syntax or defaults, which is acceptable at this coverage level but earns no extra credit.

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?

Names a concrete artifact (this week's QB/RB/WR/TE rankings) and the data source (median Kalshi prices for pass/rush/rec yds plus anytime-TD price). That is enough to distinguish it from prop-board and draft-oriented siblings like nfl_prop_board and who_do_i_draft, though it never explicitly contrasts itself with them.

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

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

The 'In season' framing and 'Free' note imply when the tool is usable, and the 2027 parenthetical rules out the draft-board use case for now. However, there is no explicit statement of when to pick this over the many other NFL/edge tools in the sibling list.

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/openWorld annotations, the description discloses tier-gated behavior (real time with Pro, free delayed 24h without the thesis), that the feed is identical and impersonal for every subscriber, that filters only select rather than personalize, and an informational-use disclaimer. These are exactly the behavioral traits annotations cannot carry.

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?

It is front-loaded with the usage trigger and packs payload, tiering, and disclaimers into a few compact sentences. The marketing-toned phrases ('any edge on Kalshi', 'One identical, impersonal feed') add some noise but are short.

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 enumerating the returned fields and explaining the real-time vs 24h-delayed access model and filter semantics. For a read-only feed with all four params documented in schema, nothing an agent needs to call it correctly 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 description coverage is 100%, so feed, limit, since, and min_tier are already fully documented in the schema. The description's list of 'feed, tier, side, price, model probability, edge and link' describes output fields, not parameter meaning, so it adds nothing to parameter interpretation. Baseline 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 names the resource (Kalshi model alerts) and enumerates the covered categories (weather, bitcoin/silver/gold/oil, mispricings) plus the returned fields, so the agent knows this is a unified alert feed rather than a single-market board. It stops short of explicitly distinguishing itself from near siblings like weather_board, commodity_edge, 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?

It opens with a direct usage trigger — 'Use for "any edge on Kalshi" and "weather trade signals"' — which gives the agent clear context for selection. However, it names no when-not conditions and does not route the agent to or away from the overlapping 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?

With no output schema, the description carries the full burden and discharges it: it names the returned elements (Kalshi price and market line, published win probability and its anchor, model line as a points lean, offense/defense/special-teams power rating split), discloses the QB gate states (PASS, ADJUSTED, FORK with both lines, HOLD), and explains the negative case — the published position or why none is published. Annotations already declare it read-only and closed-world, and nothing here contradicts them.

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

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

Front-loaded with the core deliverable and then the usage triggers; every clause maps to actual output content rather than filler. The opening sentence is dense and long, packing seven-plus return components into one clause chain, which costs a point on readability but not on 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?

For a tool with zero required params, no output schema, and no enum constraints, the description supplies the return-value semantics and the input format guidance an agent needs. It stops short of covering edge behavior — e.g. what happens with an ambiguous or unknown team, or a week with no game — which is the only remaining 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?

Schema description coverage is 100%, and both the game-format flexibility ("Bills vs Chiefs", "BUF@KC", "Buffalo at Kansas City", or one team) and the week default are already stated verbatim in the schema. The description's restatement adds example color but no semantics beyond the structured fields, so the baseline 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?

States a specific verb and resource (explain why the model prices one NFL game where it does) and enumerates the exact reasoning components returned. It is clearly distinguishable from the many sibling 'explain_*' tools (explain_ladder, explain_player, explain_prop) and from nfl_win_probability/nfl_power_ratings by naming the NFL game line as its subject.

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?

Gives concrete trigger phrases ("why do you price <team> vs <team> there", "explain the <team> game line", "what is driving the model on <team>'s game") plus the accepted game formats and the week default. It does not explicitly say when NOT to use this tool or name a sibling alternative (e.g. explain_prop for a single prop question), so routing to the nearest neighbor is left 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 cover the safety profile (readOnlyHint=true, openWorldHint=false, destructiveHint=false). The description adds real behavioral context beyond those: it enumerates what the output contains (curve lean, tighter/wider than Kalshi, crossing point, Kalshi's ladder centre, widest published gap, every listed strike) and discloses a coverage limitation (published number only at 30–70%). No auth or cost notes, so not a 5.

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-loads the purpose, which is good, but the middle sentence is a long dash-chained run that piles multiple output elements together and is hard to parse on a single read. It is information-dense rather than wasteful, but it is not tightly structured.

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

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

With no output schema, the description carries the return-value burden and does so thoroughly, and annotations handle safety. It also handles the all-optional parameter surface by explaining the defaults. Slightly short of 5 only because the family/stat/player interaction and multi-market fallbacks could be spelled out more explicitly.

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 stat, team, family, and player, including the family default (spread first) and the season_wins pairing. The description restates the market types (spread / season win total / player prop) but adds no syntax, format, or edge-case detail beyond the schema, so the baseline 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?

Names a specific verb (explain) and a specific resource/scope (one NFL strike ladder: a game spread, a season win total, or a player prop), and enumerates the read categories it produces (SHAPE, LOCATION, PRICED, MARKET READ, QB HOLD). It does not explicitly contrast itself with close siblings such as explain_prop, explain_player, or nfl_ladder, so the boundary is left to inference.

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 ("explain the Chiefs win total ladder", "why does the ladder lean Browns", "what does SHAPE mean on <player> receptions") and a clear constraint that it is one ladder per call. No explicit when-not or alternative-tool routing is given, 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 readOnly, non-destructive, and closed-world, so safety is covered. The description adds real behavioral context: the response content, the calibration constraint (number only appears in the measured-calibrated 30–70% band), and that it discloses what the model does NOT account for — useful for interpreting output.

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 with the core purpose followed by a dense but informative enumeration of outputs, then trigger examples. Every clause carries information, though the parenthetical breakdown is slightly heavy for a single sentence.

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 correctly compensates by enumerating the response components (projection, verdict, gap, caveats) and the calibration caveat. An agent has enough to call it and interpret results, though pagination or scope limits (single week) are only briefly implied.

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

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

Schema coverage is 100% with both parameters fully described in the schema, including an example value for 'stat'. The description adds no syntax or format detail beyond the schema, so the baseline of 3 applies.

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

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

States a specific verb (explain) and resource (why the model prices a player's Kalshi prop strikes where it does), and enumerates exactly what the explanation contains: projection, The Ladder verdict, model-vs-market gap, and known exclusions. This distinguishes it from siblings like explain_prop, explain_ladder, and explain_game.

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 trigger phrasing ('why do you price <player> there', 'explain <player>'s prop') that maps user intent directly to this tool. It lacks explicit negative routing or named alternatives (e.g., 'for game-level questions use explain_game'), 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, openWorldHint=false, destructiveHint=false, so the safety profile is covered. The description adds genuine behavioral context beyond that: it discloses the returned content (tier, calibrated odds, projection vs threshold, and WATCH-vs-published status including the reason) and explicitly notes what the model does not account for. It does not discuss latency, caching, or error behavior, so it stops short of a 5.

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 long enumerative sentence is dense but each item earns its place because no output schema exists to convey the response shape. Purpose and usage examples are present and the alternative-tool routing is at the end rather than the front, a minor structural weakness.

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 correctly compensates by enumerating the returned fields and the WATCH/held distinction. Combined with the sibling pointer to explain_player, an agent has enough to call and interpret the tool; only the player-name matching semantics (full vs partial) are left entirely to 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% and all three parameters carry their own examples and defaults, so the schema does the heavy lifting. The description only implies the line/stat selection via 'One contract per call' and adds no format or default guidance beyond the schema, which is the expected 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?

States a specific verb+resource: explaining why a published call exists on one NFL player prop, and enumerates exactly what the explanation contains (Kalshi contract, YES/NO side, price, tier, odds, projection, WATCH status). It explicitly distinguishes itself from the sibling explain_player ('For the full strike ladder use explain_player').

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

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

Provides concrete trigger utterances ('why do you like <player>'s over', 'explain the <player> prop') and names the alternative tool plus the condition (full strike ladder) that routes to it. Also scopes to 'one contract per call', which prevents misuse for multi-strike lookups.

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, destructiveHint=false and openWorldHint=false, so safety is covered. The description adds behavioral context beyond that: the data is live, the scope is remaining 2026 meetings, and it includes a cross-venue comparison against Polymarket and CME futures with a gap measured in pp. No auth, freshness, or staleness caveats are given.

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

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

Two sentences, zero filler: the usage trigger is front-loaded, followed by a dense enumeration of returned content. Every clause earns its place and nothing is repeated from structured fields.

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 an output schema present, the return shape needn't be explained, and the description correctly focuses on scope and coverage instead. It is nearly complete for a no-arg tool; the only minor gap is no indication of behavior when data is unavailable (e.g., between meetings or markets closed).

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 disambiguate beyond what the empty schema already conveys. The baseline of 4 applies; no additional parameter meaning is needed or missing.

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

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

States a specific verb and resource: it returns live Kalshi odds for each remaining 2026 FOMC meeting, with an explicit inventory of what it covers (strike breakdown, days-until, rate path, current fed funds rate, cross-venue check). This is precise enough that an agent can distinguish it from generic market tools like market_pulse or base_rate_gap without opening the schema.

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 opening clause gives concrete query intents that select this tool: "will the Fed cut, hold or hike" and "next FOMC meeting odds". That is clear when-to-use guidance, but it names no alternatives and gives no exclusions, so an agent must infer its boundary against sibling rate/market 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 establish readOnlyHint=true and destructiveHint=false, so the safety profile is covered; the description adds real behavioral scope beyond that — window status, close time, settlement index, the 96-window up rate, a Polymarket comparison, and a WATCH-mode rule. It does not mention freshness/latency, rate limits, or auth, which keeps it below a 5.

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 with usage examples, which is good, but the middle of the description is a single run-on sentence enumerating return fields that an output schema already covers. That list costs length without adding decision-relevant 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?

An output schema exists, so return values needn't be explained, and the description still covers scope, venue comparison and the special rule. Enough for an agent to call it correctly, though unexplained references like 'WATCH mode' and the 96-window up rate are left for the agent to interpret from the payload.

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 limit, series, open_only and asset_class, including examples ('eth', 'gold', 'euro'). The description's 'Pass series ("eth", "KXBTC15M") or asset_class' mostly restates the schema, though it usefully shows the ticker form; baseline 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?

States a precise resource — live Kalshi 15-minute up-or-down series across crypto, metals, energy and FX — with an implied read verb and clear scope. The '15-minute' qualifier plus cross-venue Polymarket detail cleanly separates it from siblings like perps_board and commodity_edge, which cover different instrument sets.

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?

Front-loads two concrete triggering questions ('what is the ETH 15-minute market doing', 'which Kalshi 15-minute markets are open') that map directly to the series/open_only params. It gives clear context for when to reach for it, but never names an alternative tool or states 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 cover the safety profile (readOnly, openWorld, non-destructive), and the description adds substantial behavior beyond them: the exact signal vocabulary (WATCH/ARB), the fields returned (gap in pp, cheaper venue, settlement_match), and a tier gate — free returns only the top 3 gaps while Pro returns the full board. That tiering and settlement-comparison context is exactly what an agent needs to interpret results.

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-loads the use case in the first sentence, then lists the returned quantities compactly, and closes with the free/Pro distinction. Slightly dense with quoted trigger phrases and jargon, but every clause carries information and nothing is redundant.

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

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

With no output schema, the description carries the return-value burden and does so: it enumerates the output fields and the free/Pro result-set sizes. For a one-optional-parameter read tool, an agent has everything needed to call it and interpret the response.

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

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

Schema coverage is 100% and minGap's accepted formats (number or "3pp"/"3%") and default/WATCH-threshold meaning are already documented in the schema. The description mentions the WATCH/ARB signal and "top 3 gaps" but adds no new syntax or filtering semantics beyond what the schema provides, so the baseline 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?

States a specific verb+resource — cross-venue arbitrage gaps on the same sports contract between Kalshi and Polymarket — and names the concrete deliverables (gap in pp, WATCH/ARB signal, cheaper venue, settlement_match). This is clearly separable from siblings like ladder_arb, combo_edge, or scan_mispricings, which cover different products or strategies.

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?

Gives explicit user-phrasing triggers ("where is the arbitrage", "Kalshi vs Polymarket price gaps") that map well to intent, plus a free-vs-Pro condition. It does not name an alternative tool or state when not to use it, so the routing guidance stops short of full 5-level specificity.

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, destructiveHint=false and openWorldHint=false, so the safety profile is covered. The description usefully adds that the tool is a pure computation returning a stake amount and a risk rating, which tells the agent there are no side effects. It doesn't discuss edge cases such as invalid probabilities or the meaning of the risk rating, keeping it short of a 5.

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 compact sentences, front-loaded with the core action and its inputs/outputs before the example triggers. Every sentence earns its place, though the trailing quoted-phrase list is slightly listy and could be trimmed.

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

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

An output schema exists, yet the description still concisely previews the return ('dollar stake and a risk rating'), and it names all four inputs with the optional bankroll implication clear via the schema. For a stateless calculator this is fully sufficient 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?

Schema description coverage is 100%, so the schema already documents each parameter in detail (bankroll optionality, accepted price/probability formats, fraction values). The description restates the same inputs — 'win probability, market price (which sets the payout), your bankroll, a Kelly fraction (full / half / quarter / eighth)' — adding only the note that market price sets the payout. Baseline 3 is appropriate when 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?

States a specific verb and resource ('Compute the optimal Kelly position size for a prediction-market contract') and goes on to name the exact inputs and outputs, so it is clearly separable from siblings like calculate_ev and convert_probability. An agent knows immediately what this tool returns (dollar stake + risk rating).

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 triggering phrases — "how much should I stake", "what is my position size", "Kelly sizing for this trade" — which give clear context for when to reach for this tool. It stops short of naming when NOT to use it or pointing to alternative siblings (e.g. calculate_ev for edge, not sizing).

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, destructiveHint=false and openWorldHint=true, so the safety profile is covered. The description adds useful output context — that results include both tickers and books, gross edge, volume and tier, and that a Pro tier also returns resting orders, net-of-fee edge and quarter-Kelly size — which is real value beyond the annotations, though it says nothing about auth needs, rate limits, or what 'Pro'/'tier' actually means.

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, front-loaded with the triggering user questions before the mechanics, with no filler. It is dense but every sentence contributes (usage, scope/outputs, Pro tier differentiation).

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 correctly compensates by describing the returned fields, and all five optional parameters are fully documented in the schema. The remaining gap is the unexplained 'Pro'/'tier' concept and no sense of result ordering or pagination, but for a read-only scan tool it is largely 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%: every parameter documents its default, accepted formats and clamping behavior. The description adds no parameter-level meaning beyond that (its 'net-of-fee edge' phrasing only loosely echoes min_edge, which the schema already defines), so the baseline 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 states a concrete verb and resource: scanning Kalshi college football and NFL spread/total strikes that are priced out of order for locked arbitrage, crossed-mid inversions and wide books. It is clearly more specific than a generic 'find arbitrage' tool, but it never names the siblings it is not (e.g. nfl_ladder or find_arbitrage), so an agent must infer the boundary.

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 questions — "is any CFB ladder mispriced" and "where can I make a market on Kalshi" — which map well to the tool's job. However, it offers no when-not guidance and does not route to alternative tools for the adjacent cases, so it stops short of full alternative-aware 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 cover the safety profile (readOnly, non-destructive, openWorld), and the description adds the crucial behavioral detail annotations cannot: tiered access gating — composite/regime/2 categories unauthenticated, 4 signed in, all six with Pro. That is exactly the auth/permission context an agent needs before calling.

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, each carrying distinct load: what it returns, what access tier yields what, and when to use it. Front-loaded with the resource and 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?

With no output schema, the description correctly spells out the return payload (composite, regime call, category scores) and qualifies it by tier. Nothing an agent needs to invoke or interpret the result 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?

Only one optional parameter, and schema coverage is 100% — the schema already documents that 'macro' is the sole topic. The description restates the composite concept but adds no syntax or format meaning beyond the schema, so the baseline 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?

States a specific resource (US macro-health composite, regime, six category scores) with a clear scope (0-100 composite, regime call). An agent can immediately tell this apart from the sibling odds/political tools, none of which touch macro data.

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

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

Provides explicit trigger phrases — "how is the US economy", "macro regime", "risk-on or risk-off" — so the agent knows the intent this tool serves. It names no alternative tools or when-not-to-use conditions, but the siblings are unrelated domains, so the gap is minor.

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 the safe read-only/open-world profile, so the description's job is to add context — and it does, enumerating exactly what comes back (opponent, kickoff, OUT and QB-gate flags, best price per side) plus the Pro-tier projection gate. It does not mention rate limits or data freshness, but the added payload detail is substantial.

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, trigger phrasings front-loaded, then inputs, then returned content. Slightly dense in the enumeration clause, but every clause describes real returned data rather than 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?

There is no output schema, so the description has to characterize the return shape — and it does so item by item, including the market-pricing and Pro-tier caveats. What remains thin is how multiple leagues are disambiguated and whether the username is strictly required, though the schema partially covers the latter.

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 parameters are already documented in the schema, including the 'when the user is in several' condition for league. The description restates that same condition for league and adds only that the username is required in practice, so it adds little beyond the structured fields. Baseline 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 literal user triggers ('show my fantasy team', 'what is Kalshi pricing my starters at') and then states the concrete resource: roster, starter matchups, and per-starter Kalshi strikes. This is distinguishable from siblings like player_outlook or start_sit, which do not mix roster display with market pricing.

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 clearly states when to reach for this tool via quoted user phrasings, and implies the input condition for the league parameter. It never names a competing sibling or an exclusion, so it stops short of a full routing statement.

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

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

Annotations already declare readOnlyHint=true, destructiveHint=false and openWorldHint=true, so safety is covered. The description adds genuinely useful behavioral context beyond that: pricing is 'market prices only, no model' and the Kalshi fee is included in the comparison. It omits pagination/return-shape details, 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?

Front-loaded with the usage trigger, followed by scope and a key caveat in two sentences. The example queries are slightly verbose but they earn their place by anchoring invocation phrasing.

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

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

With four optional params and no output schema, the description does the needed work of explaining what the result represents (the cheapest venue per side, fee included) and what it is not (model output). Coverage is adequate for a read-only board tool; only pagination/response-format specifics are unaddressed.

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% (game, team, limit with clamping note, market enum), so the schema carries parameter meaning. The description reinforces that moneyline/spread/total are the markets but adds no syntax or format detail beyond what the schema already 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?

States a specific resource and scope: Kalshi NBA moneyline/spread/total compared against a named list of sportsbooks at the same line, with the cheapest venue per side. An agent can distinguish this from player-prop siblings (nba_prop_board) and generic tools (best_available) without opening a schema.

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...' examples (Knicks moneyline on Kalshi vs the books, cheapest Celtics spread tonight) give concrete trigger phrasings that map directly to invocation. It stops short of naming explicit alternatives or when-not-to-use cases, so it is strong context but not 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 readOnly/openWorld annotations, the description discloses genuinely useful behavior: sample size on every row, a two-season lookback window, Kalshi prop prices shown alongside, questionable players forking into plays/sits branches, and the explicit 'no projection' caveat. This is rich context an agent could not infer from structured fields.

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 with the 'Use for...' trigger phrases and dense with information; nearly every clause earns its place. It is a long single paragraph rather than cleanly segmented, which keeps it from a 5.

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 return-value burden well: it explains that each absent star yields beneficiary rows with per-row sample sizes and side-by-side Kalshi prices, and notes the plays/sits branch behavior for questionable players. An agent knows what it will get back.

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 four parameters are already documented in the schema. The description echoes the stat concepts (minutes, points, rebounds, assists, usage) but adds no format or default guidance beyond what the schema provides, so the baseline 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?

States a specific verb+resource: NBA absences from the official injury report plus the teammates whose stats rose without the absent star. The example queries ('Embiid's out tonight — who benefits?') make the intent unmistakable and distinguish it from prop/game board 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 'Use for...' framing plus two concrete example questions give clear when-to-use context, and 'Historical splits only, no projection' sets a boundary. It never names a sibling alternative (e.g. nba_prop_board) explicitly, so it falls short of a 5.

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

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

Annotations already declare readOnlyHint=true, openWorldHint=true, destructiveHint=false, so safety is covered. The description adds genuinely useful behavior: prices are market-only (no model output) and the Kalshi fee is included in the cheapest-venue computation, which materially affects interpretation.

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 with the use-case trigger, then the return shape, in two tight sentences with no filler. The verbatim user-question framing is slightly informal for a spec but earns its place by anchoring intent.

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 describing returns, and it does: cheapest venue per side across named books with fees included. Combined with 100% schema coverage on inputs and read-only annotations, an agent has enough to invoke it correctly; only the exact response row shape is unspecified.

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 every parameter (game, team, limit clamping, player, statType with its four options) is already documented in the schema. The description's mention of points/rebounds/assists/threes only restates the statType enum, adding no syntax or format detail beyond the schema. Baseline 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?

Names a specific resource (every Kalshi NBA player-prop strike) and the exact output (the same strike priced beside DraftKings, FanDuel, BetRivers, Fanatics, ESPN, Novig, ProphetX, cheapest venue per side). Clearly distinct from siblings like nfl_prop_board, explain_prop, and best_available.

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

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

The opening quote — "where is LeBron's points line cheapest tonight" — gives a concrete trigger scenario that makes the intended use obvious. However, it states no when-not condition and does not explicitly route the agent to alternatives (e.g. nfl_prop_board for NFL props, explain_prop for explanations).

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, openWorldHint and destructiveHint=false, so safety is covered. The description adds genuinely non-structured context: a Pro auth requirement (sign in with PredictionMarketsPicks or a Pro API key) and the sourcing guarantee that unmodeled tickers return not_covered rather than fabricated edges.

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-loads the user-intent queries, then packs market scope, output fields, watchlist behavior and auth into a compact block. It is dense but not padded; the em-dash clause is slightly run-on but each phrase carries 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 tool with no output schema, the description discloses the returned fields (probability, price, edge, side), the auth gate and the tickers/not_covered behavior, which is enough to call it correctly. Minor gaps remain around pagination and the exact shape of game rows versus futures rows.

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 limit, market, minEdge (including its ignore-when-tickers rule) and tickers. The description only lightly reinforces the tickers watchlist use case without adding syntax or format detail beyond the schema, so the baseline 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?

States a specific verb+resource: an NFL model vs live Kalshi prices surfacing mispricings, with the concrete market coverage (game positions, win totals, MVP, championship) and output fields (model probability, price, edge, side). It is clearly distinguishable from siblings like nfl_prop_edge, nfl_power_ratings and nhl_edge without opening any schema.

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?

Opens with explicit when-to-use phrasing ("which NFL games are mispriced on Kalshi", "NFL win total, MVP or Super Bowl edges"), giving a clear invocation context. It does not name the alternatives an agent should prefer (nfl_prop_edge for props, scan_mispricings or nhl_edge), so there is context but no exclusions.

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

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

Annotations already declare readOnlyHint/openWorldHint/destructiveHint, so the safety profile is covered. The description adds genuine behavioral context beyond that: the model's number is only published between 30% and 70%, and outputs carry a SHAPE/LOCATION/PRICED/PARTIAL verdict — both are things an agent needs to interpret results.

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 with the 'Use for' cue and two sentences that each carry content — resource, contents, verdict taxonomy, and the publication constraint. The example queries are slightly verbose but earn their place by grounding the use case.

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?

An output schema exists, so return values need no explanation, and the description covers purpose, families, verdicts, and the 30-70% constraint. The remaining gap is the verdict term mismatch with the schema enum and lack of any note on default/clamp behavior referenced 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 coverage is 100%, so the schema already documents all five filters, and the baseline is 3. The description adds little, and worse it introduces a conflicting label: it lists the verdict as 'PRICED' while the `kind` enum uses 'agree', which could mislead an agent filtering on that value.

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

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

States a specific resource (NFL strike ladders — spreads, season win totals, player props) and specific content (Kalshi's price at each strike beside our distribution plus a verdict). The example queries ('where does the model disagree with Kalshi on the Rams spread') make the tool's function unambiguous and separable from generic edge tools like nfl_edge or ladder_arb.

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 ...' framing supplies two concrete triggering questions, giving clear context for when to reach for this tool. However, it names no alternatives or exclusions, leaving the agent to infer when explain_ladder or ladder_arb would be the better choice.

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, openWorldHint=false, destructiveHint=false, so safety is covered. The description adds meaningful behavioral context beyond that: the exact meaning of the returned number, and that rank and tier are bundled in. It stops short of noting empty-result or clamping behavior in prose (those live in the schema).

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

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

Front-loads the resource and metric definition, then the usage examples. The example-query list is slightly long but each phrase maps to a real lookup pattern, so nothing is truly 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?

With an output schema present the description needn't explain return values, annotations cover the safety profile, and all three parameters are documented. It supplies the metric definition an agent needs to interpret results; only minor gaps (empty-board behavior in prose) remain.

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 fully documents team, tier, and limit (including tier thresholds and the clamping rule). The description adds no parameter syntax or format detail beyond that, so the baseline 3 is correct.

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 resource (NFL power ratings / PWR for all 32 teams) and defines the metric precisely, including the PWR = Off PR + Def PR + ST PR formula and that rank and tier are included. It does not name or contrast a sibling tool, so it stops short of the sibling-differentiation bar for 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 ...' clause gives concrete triggering queries ('best NFL teams by power rating', 'is Baltimore overrated'), which is clear usage context. It offers no exclusions or explicit pointers to alternative siblings, so it is a solid 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 declare readOnlyHint=true and openWorldHint=true, so the safety and scope profile is covered. The description adds meaningful behavior the annotations cannot: Kalshi prices include fees, five specific books plus two exchanges are aggregated, and a Kalshi close is captured once a strike settles. No rate limits or refresh cadence are mentioned.

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?

Trigger queries are front-loaded, and the remaining single sentence packs the source list and return content without filler. Every clause earns its place given the tool's comparison scope.

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 an output schema present, return-value details need not be explained, and the description still previews the key outputs (best price per side, Kalshi's discount vs books, consensus gap, settled close). Inputs and intent are fully covered for a read-only board tool.

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

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

Schema description coverage is 100%, so all six filters (game, team, player, statType, limit, gapsOnly) are already documented with formats and defaults. The closing 'Filter by team, game, player or stat' only restates a subset of what the schema says and omits gapsOnly and limit, adding little beyond 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?

States a specific resource (best price on every NFL prop this week) and enumerates the exact sources it compares: Kalshi with fees, five named books, and the Novig/ProphetX exchanges. An agent immediately knows this is a cross-venue price board, though it never explicitly distinguishes itself from siblings like nfl_prop_edge or nba_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?

Opens with two concrete trigger queries — 'where is the best price on <player> receiving yards' and 'is Kalshi cheaper than the books' — which map the tool to a clear intent. It does not state when to prefer alternatives (e.g., nfl_prop_edge for single-strike edge math), so no exclusions are offered.

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 readOnly/openWorld/non-destructive, so the safety profile is covered. The description adds real behavioral context beyond that: the exact shape of returned rows (including 'WATCH rows labelled'), the temporal constraint ('Live in season'), and the auth requirement (Pro, sign in with PredictionMarketsPicks or a Pro API key).

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?

Compact and front-loaded: the usage trigger leads, then the return shape, then the availability and auth caveats. No sentence is filler, and the field enumeration packs useful detail into a short span.

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 enumerating the returned fields, and it covers auth and season availability, which are the real gating concerns for a live prop tool. For a zero-required, three-parameter tool with full schema coverage and annotations, 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%, so limit, minEdge, and propType are already fully documented in the schema. The description hints at prop-type filtering via 'receiving yards prop value' but adds no syntax, defaults, or clamping detail beyond what the schema provides, so the baseline 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?

States a specific verb+resource: it compares 'our projection vs the Kalshi

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?

Front-loads concrete trigger queries ('best NFL props today', 'receiving yards prop value'), giving clear context for when to reach for it. There is no explicit exclusion or routing to alternatives such as nfl_prop_board, so it falls short of a full when/when-not treatment.

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 readOnly/non-destructive/closed-world, so the bar is lower, and the description still adds real behavioral context: it is a QB-gated model, falls back to raw power ratings for unscheduled games, auto-derives the spread from PMP ratings, and gives neutral-site games no home edge. Those model-level traits go well beyond the annotation surface.

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 two sentences are front-loaded with the triggering example queries before the mechanics, and every clause (input combos, spread sign, return set, neutral-site rule) carries information. It is dense and heavily parenthetical, which costs a little readability, but nothing is 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?

An output schema exists so return values need not be described, yet the description still summarizes them and covers the key edge cases (unscheduled games, neutral sites, model_total vs supplied total). For a 5-param zero-required tool this is essentially complete, with only the absence of named-alternative routing keeping it from the top.

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 earns more by clarifying the spread sign convention (home favored negative) and the OR-combination logic across homeTeam+awayTeam / game / single team / spread that the schema does not state as a decision. It adds combination guidance rather than merely restating field docs.

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 verb+resource (NFL win probability), pairs it with two example user phrasings so intent-matching is trivial, and pins down the output family (win, cover, over/under probability, projected score). It implicitly separates itself from NFL power-rating siblings by calling this "our QB-gated model line," though it never names another tool 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 clear, actionable usage context: pass homeTeam+awayTeam, or game, or a single team, or a spread. The example queries ("who wins Chiefs vs 49ers", "what does a -7 spread mean") anchor when to reach for it. It stops short of any explicit when-not-to-use or named alternative, so it is strong context rather than 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 already declare readOnlyHint=true, destructiveHint=false and openWorldHint=true, so safety is covered; the description adds real context beyond them — data sources (Kalshi, Polymarket as an international book), the "starting goalies checked first" precondition, the 10,000-season sim backing futures, and the "Free" cost note. It stops short of describing latency, rate limits, or failure 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 front-loaded with the trigger phrases and then moves through scope, output shape and market modes in three dense sentences with little redundancy. The em-dash and middle-dot notation (Market · Model · Fair) is compact but adds a small parsing burden.

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-required-parameter, read-only tool with no output schema, the description supplies the essentials: what the rows represent, the two data sources, and the market modes. The output format summary compensates for the missing output schema, though it does not describe row granularity or error cases.

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 earns above that by explaining what each market value actually yields (goals = anytime and first-goal contracts; futures = Cup, conference and division markets), which goes beyond the schema's terser "player-goal contracts" and "Stanley Cup + season markets". It adds no detail on team or limit, but those are fully documented 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 (tonight's NHL games on Kalshi priced as Market · Model · Fair) and enumerates the market types, so an agent can tell it serves NHL betting-model comparisons. It does not use an explicit verb like "get" or "list", and sibling differentiation rests entirely on the word "NHL" rather than a named contrast with tools like nfl_edge.

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

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

"Use for 'NHL predictions tonight' and 'Stanley Cup odds'" gives concrete trigger queries that map directly to the tool, and the market=goals / market=futures clauses clarify which mode serves which need. No exclusions or named alternatives are given, so an agent must infer when not to reach for 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 declare readOnlyHint=true and destructiveHint=false, so the safety profile is covered. The description adds genuine context beyond that: this is an estimate with a stated error characteristic (Kalshi's app shows the exact value), it incorporates fees and expected funding, and it is free. That is useful disclosure, though return-level detail is left implicit.

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 trigger phrase and the core explanation are front-loaded and the whole thing reads as one efficient block. The 11-asset enumeration duplicates the schema enum, which is mild waste, but the example and the estimate caveat 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 carries the return-value burden and does so — it names the liquidation price, the percent move, fees, and expected funding. Combined with annotations covering safety and a 100%-documented input schema, an agent has everything needed 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 description coverage is 100%, so every parameter (side, asset, entry, margin, leverage, hold_days) is already documented with defaults and accepted formats. The description restates the asset list and frames leverage semantics in prose but adds no parameter syntax or format meaning 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 states a specific verb and resource — it estimates a Kalshi perp's liquidation price and the percent move to it — with a concrete example (5x BTC long ~8% away). It is unambiguous about what the tool does, but it never distinguishes itself from the closely related sibling perps_board, 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?

"Use for 'where does a 5x bitcoin long liquidate on Kalshi'" gives a clear, concrete triggering context so the agent knows when to reach for it. However, there are no when-not conditions and no explicit routing against alternatives like perps_board or kelly_size.

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, destructiveHint=false and openWorldHint=true, so the safety profile is covered. The description adds real value beyond that by disclosing the return payload's shape, including a derived metric (cumulative funding paid by a long since launch) and the fact that all perps are returned by default.

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, front-loaded with usage triggers before the field inventory, with no filler sentences. The field enumeration is long but each item earns its place by telling the agent what data comes back.

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 an output schema present, the return values need not be described, and the read-only/open-world annotations cover safety. The description still supplies enough context (default full-board behavior, asset narrowing, funding-cadence framing) that an agent can invoke it confidently; only an explicit sibling tie-breaker 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 description coverage is 100%, so both parameters are fully documented in the schema, including the limit clamp at 30. The description repeats the asset examples ("btc", "gold") but adds no syntax or format detail the schema lacks, making the baseline 3 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 resource and enumerates exactly what the board contains: price, 24h volume, open interest, max leverage long/short, funding cadence, and cumulative funding cost for longs. An agent can distinguish this from siblings like perp_liquidation (liquidation events) or calculate_ev without opening a schema.

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?

Opens with concrete user-phrasing triggers ("Kalshi perps funding rate", "how much leverage on Kalshi gold perps") and tells the agent how to narrow the result by passing an asset. It stops short of naming an alternative or stating when-not-to-use (e.g., versus perp_liquidation), so it is clear context without exclusions.

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

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

Annotations already declare readOnlyHint=true, destructiveHint=false, and openWorldHint=false, so safety is covered. The description adds useful context — it is free and aggregates prices across venues plus a model probability — but omits pagination, freshness, or failure 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?

Two short sentences, front-loaded with the core scope and what the response contains. Slightly informal phrasing but no wasted content.

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 return-value burden — and it does describe the payload (prop lines, best price across venues, probability at each strike). With 0 required params and full schema coverage, remaining gaps are 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 description coverage is 100%, so all three parameters (player, scoring, platform) are already documented in the schema. The description adds no parameter-level syntax or defaults beyond what the schema provides, so baseline 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?

States a specific verb+resource+scope: 'One NFL player this week — every Kalshi prop line, the best price across venues, and our probability at each strike.' An agent can distinguish this from siblings like compare_players or explain_player.

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

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

Provides example queries ('is <player> a good play this week', '<player> props') that imply usage context, but does not name alternatives or state when NOT to use this tool versus explain_player or compare_players.

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/openWorldHint/destructiveHint=false, so safety is covered. The description adds genuine context beyond them: live Kalshi data, 'prices are never estimated' (a data-freshness/trust guarantee), and an enumeration of what each leg 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?

Front-loaded with usage examples before the payload description. Efficient, though the trailing list of returned fields is long enough that it 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?

With no output schema, the description carries the burden of describing returns and does so explicitly (leg price, volume, link, seat holder and rating, forecaster bands, race page). For a single-parameter read tool, nothing needed to call it correctly 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 single 'race' parameter is already documented with accepted formats. The description restates those formats (state, code, slug, 'TX-34') without adding syntax or disambiguation rules beyond the schema, so baseline 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?

States a specific verb+resource: 'Live Kalshi odds for one 2026 Senate, governor or competitive House race.' The 'one race' scoping distinguishes it from senate_map (all races) and fed_rate_odds (a different market class), so an agent can differentiate 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?

Opens with concrete trigger phrasings ('who wins the Kansas Senate race', 'Michigan governor odds') that map directly to the intended call. It gives clear context for when to use it but names no exclusion or alternative tool for adjacent cases.

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

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

Goes well beyond the readOnly/openWorld annotations by disclosing that the scanner is being rebuilt and usually returns zero rows today, that the response reports the last run time, that results are sorted by absolute edge, and that Pro auth is required. An agent knows both the failure mode and the auth prerequisite before calling.

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 purpose and return shape lead, with the empty-result caveat and auth note following. Every sentence carries information, though the quoted trigger phrases add some length that could be trimmed.

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

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

With no output schema, the description compensates by describing the returned fields (market, direction, edge, Kelly sizing, sort order, last-run timestamp). Between that and the schema, an agent has everything needed to call and interpret this tool.

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

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

Schema coverage is 100%, so limit's default/clamp behavior and minEdge's accepted formats ('3', '3pp', '3%') are fully documented in the schema itself. The description adds nothing parameter-specific, which is the expected baseline when 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?

States a specific verb and resource — scanning Polymarket contracts for mispricings against the PMP probability-swarm model — and enumerates the output (direction, edge in pp, quarter-Kelly sizing). This is distinguishable from siblings like find_arbitrage or calculate_ev without opening any schema.

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?

Gives concrete invocation triggers ('where is the edge today', 'mispriced markets', 'what should I trade') and states the access gate (Pro sign-in or API key). It does not compare itself against alternatives such as find_arbitrage or edge_alerts, so it stops short of explicit when-not 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 declare readOnlyHint, openWorldHint and non-destructive behavior, so the safety profile is covered. The description adds real behavioral context beyond that: results are ordered closest race first, each seat carries a page URL, and prices are never estimated — an unpriced seat returns null. The null-vs-estimate guarantee is exactly the kind of disclosure that prevents an agent from misreading a missing value.

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

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

Two sentences, both front-loaded: the first is the retrieval trigger, the second is the payload. Every clause (holder, rating, forecaster bands, price, sort order, URL, null policy) earns its place with 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?

With no parameters, no output schema and full annotation coverage, the description's only remaining job is describing the returned data, which it does field by field, including sort order and the null-pricing edge case. Nothing needed to invoke or interpret the result 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?

The tool takes zero parameters, so the baseline of 4 applies: there is no parameter syntax for the description to clarify, and the schema is trivially complete. The description correctly spends no words on inputs.

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

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

States a specific resource (every 2026 Senate seat) and enumerates exactly what each entry contains: holder and role, structure rating, forecaster bands, live Kalshi price, page URL. The scope ('every seat') is unambiguous and the Senate focus distinguishes it from the broader siblings like race_odds.

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?

Gives explicit trigger phrasing: 'Use for "2026 Senate map" and "which Senate seats are toss-ups"', which tells the agent the question shapes this tool answers. It stops short of naming an alternative (e.g., race_odds) or a condition where this tool is the wrong choice, so it is clear context rather than full when/when-not 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 carry the safety profile (readOnly, non-destructive, closed-world), so the bar is lower. The description adds genuinely useful context beyond them: it is free, needs no key, and returns the complete (non-truncated) list, which affects how an agent should treat coverage.

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 with the core purpose, the differentiator, and access facts before the query list. The seven quoted trigger phrases are somewhat repetitive, but each sentence still 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 carries return-shape burden and does so reasonably: ranked list, underpriced/overpriced label, and the stat driving each call. Minor gaps (sort order, list size) remain but an agent can call it 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?

Only one optional parameter (position) and schema description coverage is 100%, so the schema fully documents it. The description adds nothing about the position filter, so the baseline 3 for high-coverage schemas 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?

States a specific verb+resource: every NFL player whose Kalshi prop price the PredictionMarketsPicks model disagrees with this week, ranked, marked underpriced/overpriced with the driving stat. It distinguishes itself from the paid alternative by scoping to the complete disagreement list rather than strike-level detail.

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

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

Explicit when-to-use with concrete query phrasings ("undervalued players this week", "who is the market overpricing", "busts to avoid") and an explicit when-not/alternative: strike, price and magnitude live in the Pro nfl_prop_edge tool. Routing is unambiguous.

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, destructiveHint=false and openWorldHint=true, so safety is covered. The description adds non-obvious context the annotations cannot convey: output is market prices only with no recommendation, and weekly projections are gated behind a Pro tier. It does not mention rate limits or data freshness, keeping it short of a 5.

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?

Roughly two sentences, front-loaded with the user questions that trigger the tool, followed by output scope and the pricing/projection caveat. Dense but essentially waste-free; the 'Pro adds our weekly projection' clause is the only mildly promotional bit.

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 the work of explaining the return shape — per-stat median strike-ladder prices plus anytime-TD price, compared on shared stats — and covers the 2–4 player constraint and the read-only, no-recommendation nature. Adequate for an agent to call it correctly, though error/edge behavior (unknown player names, fewer than 2) is unaddressed.

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 there is a single 'players' parameter already documented with accepted forms in the schema. The description reinforces the 2–4 player limit and names example players, but adds no format or syntax detail beyond what the schema provides, so baseline 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 states a concrete verb+resource: it returns the median Kalshi market price for each stat plus anytime-TD price for 2–4 named players, compared on shared stats. It differentiates itself from projection-based tools via 'Market prices only — the call stays yours', though it never names the closest sibling, compare_players, so the boundary with that tool is left to inference.

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 a clear triggering context with quoted user questions ('should I start Nacua or Adams', 'who does the market like more this week') and a cardinality constraint (2–4 players). It does not state any exclusion or explicitly route the agent to a named alternative such as compare_players, 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, destructiveHint=false and openWorldHint=true, so the safety profile is covered. The description adds a genuinely useful interpretive note that WATCH calls are reported separately, but says nothing about data freshness, grading lag, or how the 'current model era' is bounded.

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

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

Two sentences, trigger phrases front-loaded ahead of the content inventory, no filler. The second sentence is dense with enumerated metrics but each item is a distinct return field, so the length is earned rather than 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?

No output schema exists, so the description carries the return-value burden and does so reasonably: it names the metrics (W-L, net P/L, 95% range, model era, backtest) and the separate WATCH reporting. It could still clarify ordering, per-engine grouping, or grading recency for full 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% and the lane parameter's allowed values are fully listed in the schema, so the schema already does the heavy lifting. The description's engine list (bitcoin, gold, silver, oil, weather, NHL, POTD, NFL) merely mirrors the schema's lane values, adding no new semantics such as default behavior or slug format.

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

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

States a specific verb/resource combination — every graded signal per engine plus the daily editorial call — and enumerates exactly what metrics come back (W-L, net P/L, 95% win-rate range, model era, NFL backtest). No sibling covers accuracy/track-record reporting, so an agent can route here unambiguously.

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

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

Opens with explicit trigger phrasings ('how accurate is your model', 'what's your track record'), which is clear when-to-use guidance. It does not name an alternative or an exclusion case, so it stops short of the top tier.

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, destructiveHint=false and openWorldHint=true, so safety and external-data behavior are covered. The description adds the 24-hour trending window, the Sleeper source and Kalshi price pairing, and the "Market data only" caveat, but says nothing about rate limits, auth needs, or failure modes.

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?

One tightly packed sentence: use-case phrasing first, then data sources, then the parameter-conditioned filtering behavior, then a scoping caveat. Nothing is redundant with the title, and every clause carries 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 4-parameter read tool with no output schema or nesting, the description covers the data source, freshness, enrichment (market prices), and the effect of optional filters. Return shape is only implied (players plus prices), which is the main remaining 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?

Schema description coverage is 100%, so every parameter (including the limit clamp at 25) is already documented. The description restates the filtered-availability semantics of sleeper_username plus league, but adds little beyond what the schema text already conveys; baseline 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?

States a specific verb/resource combination: Sleeper's most-added players over the last 24 hours paired with Kalshi market prices. "Market data only" frames the scope as pricing rather than league actions, which helps separate it from siblings like my_league or best_available, though no sibling is named directly.

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?

Opens with quoted user intents ("who is everyone adding off waivers", "trending waiver adds this week") that give concrete trigger conditions, and explains that adding position/username/league narrows to still-available players. No explicit when-not or named alternative, 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 readOnly/openWorld/destructive=false, so the safety profile is covered. The description adds real context beyond that: the strict-comparison settlement rule, the settlement station and source, and the close time — meaningful for interpreting the odds. No access requirements or throttling mentioned.

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 tight sentences: trigger phrase first, payload contents second, parameter hint and scope guard last. No redundant restatement of the title, and the "Market data only" fragment earns its place as a routing guard.

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 an output schema present and both parameters fully documented, the remaining burden is scope and semantics — both covered (13 cities, settlement rule, market-data-only). An agent has everything needed to decide and 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?

Schema coverage is 100%, so both parameters (day, city) are already fully documented with examples and defaults. The description repeats the same city examples without adding syntax, format, or fallback behavior beyond what the schema provides, so baseline 3 is correct.

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 clear resource (Kalshi daily-high temperature markets across 13 cities) and enumerates exactly what each row contains: YES price, settlement station/source, strict-comparison rule, close time, and NWS forecast high. No sibling tool touches weather markets, so the agent can identify this as the weather-market board without ambiguity.

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?

"Use for 'Kalshi NYC high temperature odds'" gives a direct trigger, and "Market data only" implicitly routes EV/edge/arbitrage needs to siblings like calculate_ev or find_arbitrage. It stops short of naming an alternative explicitly, so it lands just below the top band.

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, destructiveHint=false, and openWorldHint=false. The description adds genuinely non-structured traits: that the call is 'Free' (cost behavior) and only valid 'In season' (availability constraint). It does not explain behavior out of season, but the annotations plus these two facts give solid coverage.

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?

Very short and front-loaded: season condition, output, cost, and call format. The telegraphic fragments ('Free.') are efficient, though the style is slightly clipped and the example could be trimmed without loss.

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 single-optional-parameter, read-only tool with no output schema, the description covers what is returned (props with best price per strike) and gives an invocation example. Only the out-of-season behavior and the meaning of 'best price per strike' tie-breaking remain unspecified.

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 'roster' parameter and its 2–4 name constraint are already documented. The description adds a literal call example ('Pass roster: ["Player A", "Player B"]'), which is marginally useful, so the baseline 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 states a concrete return: Kalshi props on 2–4 named players, with the best price per strike. It differs from the tool name ('who_do_i_draft' suggests draft advice) but clarifies the actual behavior, though it never names a sibling tool to differentiate itself among the many prop/edge 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?

'In season:' implies a usage window and 'Free' signals no cost, which is mild context. However, no alternatives are named (e.g., nfl_prop_board, nfl_prop_edge) and there is no explicit when-not guidance, leaving routing to inference.

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