voxodds

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

Adds substantial context beyond annotations: it explains that a write happens (append-only audited receipt) only when your_probability is passed, that it refuses unresolvable events, that verdicts are arithmetic rather than model output, and that it is research rather than financial advice. This explains why readOnlyHint=false and idempotentHint=false.

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 action, but the middle is dense with interleaved parentheticals and asides (odds examples, receipt logging, disclaimers) that make it heavier than necessary.

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

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

An output schema exists so return structure needn't be explained, yet the description usefully previews the references and EV verdict fields. Combined with the write-behavior disclosure, an agent has everything needed to 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?

Schema coverage is 100% so the baseline is 3, but the description adds real meaning: accepted odds formats (decimal/american/fractional), the 0-1 range and dependency of your_probability on forecaster_id. This exceeds what the schema alone conveys.

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

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

States a specific action (pre-bet EV check) on a specific resource (a bet on any bookmaker) and names its inputs. It is clearly distinguishable from siblings like get_market_odds, find_best_price, and submit_forecast.

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 timing guidance ('run this BEFORE the user places any bet, on any bookmaker') and states the precondition that logging your estimate requires forecaster_id. It does not, however, name alternative sibling tools or when-not-to-use conditions, 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?

readOnlyHint and openWorldHint are already declared, so safety is covered. The description adds genuine behavioral context by enumerating what the response omits (Kalshi prices, fees, depth, venue ranking, savings), which steers the agent away from assuming it gets a full cost comparison. This negative disclosure is more valuable than repeating the annotation.

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

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

Three short sentences, front-loaded with the action. Each sentence carries weight: the first states the output, the second bounds it, the third points to where full comparison lives. No filler, though the negative list is slightly dense.

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-shape explanation is unnecessary, and the read-only/open-world annotations cover the safety profile. The description adds the crucial scope caveat that this is not a full cross-venue comparison, leaving the definition sufficiently complete for an agent to 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?

Schema description coverage is 100% with all four params documented (side, amount_usd, kalshi_ticker, polymarket_id). The description adds no syntax or format detail beyond the schema, so the baseline 3 for schema-covered parameters 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 ('Return') and resource ('the Polymarket quote for one pair'), plus the secondary returns (Kalshi ticker and notice). The negative scoping ('No Kalshi prices, fees, depth, venue ranking or savings') effectively distinguishes it from richer comparison siblings like compare_platforms or find_best_price, though no sibling is named.

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

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

Usage is implied rather than stated: by declaring what is NOT exposed and that comparisons live only on the external web page, the agent can infer this tool is a narrow quote-fetcher and that richer comparison tools exist. There is no explicit when-to-use or named alternative, leaving the agent to infer routing.

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

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

Annotations already declare readOnlyHint and openWorldHint, so the safety profile is covered. The description adds genuine value beyond that by disclosing a hard data-availability limitation (no Kalshi prices or derived spreads) and pointing to an external human-readable comparison page. It does not discuss pagination or freshness of the odds.

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

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

Four short sentences, front-loaded with the return value, then the limitation, then the URL, then the alternative. Every sentence carries distinct information, though the link sentence lightly restates the 'link to human venue comparisons' already promised in sentence one.

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 annotations, full schema coverage, and an output schema in place, the description fills the remaining gaps: data scope, what is unavailable, and where to go for the adjacent need. Nothing an agent needs to select or call this tool 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?

Both parameters are fully documented in the schema (100% coverage), so the schema carries the load. The description adds nothing about limit or query semantics, so the baseline of 3 for high schema coverage 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 returns independent Polymarket odds plus a link to human venue comparisons. It also pre-empts the mismatch implied by the name 'compare_platforms' by clarifying that no Kalshi-side comparison data is returned. It stops short of a clean one-line scope statement, but an agent can still tell what it gets.

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

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

It explicitly states what this tool does not cover ('Kalshi prices and derived spreads are not available via API or MCP') and routes the agent to a named alternative for a related need ('For Polymarket order-book quotes use list_executable_opportunities'). It does not distinguish itself from other odds-adjacent siblings like get_market_odds or find_best_price, so it is strong but not complete.

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

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

Beyond readOnlyHint/openWorldHint, the description discloses a material data-availability caveat ('registry is a directory, not live coverage'), the return shape (best-first table with decimal/american odds, implied probability, average vig, marginal profit), and an integrity guarantee ('ranked strictly by price — never by whether they pay VoxOdds a commission'). These are traits the annotations cannot express.

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 guiding constraints (feed requirement, ranking rule, sibling alternative) are front-loaded and every sentence carries information. It runs a few sentences long and re-enumerates return fields that an existing output schema already covers, which is mild redundancy.

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

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

For a 3-parameter read-only lookup with an output schema, nothing an agent needs is missing: the usage trigger, the alternative, the data-coverage caveat, and the ranking integrity rule are all present. Return values are fully covered by the output schema and helpfully summarized anyway.

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 (event, side, sport) are documented in the schema, so the baseline is 3. The description adds only the framing that this targets 'one specific bet', no syntax or format detail beyond the schema.

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

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

The first sentence names a specific verb (find), a specific resource (which bookmaker pays the most for one bet), and a precondition (VoxOdds has a configured live sportsbook feed). It also distinguishes itself from the sibling check_bet by contrast, so an agent can route between them without opening either 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?

Explicit trigger conditions are given ('when the user has already decided WHAT to bet', 'where should I bet this') plus a named alternative and the condition that selects it ('Use check_bet instead when the user still needs to know whether the bet is worth making at all'). This is textbook when/when-not/alternative 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 and openWorldHint, so the safety profile is covered; the description adds value by framing output as automated ranked flags (not authored analysis), noting the research-not-advice stance, and stating each signal includes what to verify before acting. It doesn't discuss freshness, coverage breadth, or why signals appear/disappear, which would push it to 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 the verb+resource sentence, then routing, then framing — a sensible order with minimal waste. Slight bloat from the all-caps 'LOOK' and the compound signal enumeration, but every sentence 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?

With an output schema present, return values need not be explained; the description covers purpose, triggers, the sibling alternative, and the nature of the output. For a zero-required-parameter read tool, 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?

There is a single optional 'limit' parameter with 100% schema description coverage, so the schema already fully documents it. The description adds no semantics about the limit (e.g., whether rankings are truncated or what the default yields), 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 and resource ('Get VoxOdds' ranked market signals') and enumerates the three signal types (wide spreads, closing-soon watches, integrity flags), so an agent knows exactly what comes back. It also distinguishes itself from get_research_theses, the nearest sibling.

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 conditions ('when the user asks what looks mispriced, what's worth researching, or where the action is') and names the alternative with the condition that selects it ('for written theses with entry and invalidation criteria use get_research_theses'). This is a clean when-to-use/when-not 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 cover safety (readOnlyHint, openWorldHint), and the description adds real behavioral context beyond them: the quote is independent, it includes estimated taker fees and depth, and Kalshi returns degraded identifier-only results. That last point materially changes what an agent should expect from a valid call.

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 core capability first, then the platform-specific exception. Every clause carries information; the documentation URL is the only mildly expendable element.

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-shape explanation is unnecessary, and the caveat about Kalshi's reduced output is exactly the kind of pre-call expectation an agent needs. Missing only explicit guidance on when to prefer the multi-venue comparison sibling.

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 side, platform, market_id, and amount_usd with defaults. The description adds nothing about parameter formats or constraints, 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 ("Get an independent Polymarket all-in order-book quote") and scopes it to a single venue, which implicitly contrasts with the sibling compare_executable_quotes. It does not name that sibling outright, so an agent must infer the multi-venue alternative.

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 Kalshi caveat ("requests return only identifiers and a notice") implies Polymarket is the useful path for real quotes, and "one venue" implies compare_executable_quotes is the multi-venue option. However, there is no explicit when-to-use/when-not statement or named alternative, 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.

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

Annotations already declare readOnlyHint=true and openWorldHint=true, so the safety profile is covered. The description adds that the record is 'public' and characterizes the pending-vs-scored split, which is modest extra context; with an output schema present, the return-content detail largely duplicates structured data.

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 purpose, followed by content description and usage. Every sentence carries information; no filler or repetition.

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

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

For a one-parameter read tool with full schema coverage and an output schema (so return values need not be explained), this covers purpose, content, and invocation timing adequately. The only notable gap is not clarifying its relationship to get_track_record.

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 forecaster_id is fully documented in the schema. The description reinforces it ('Same forecaster_id you submit with'), tying it to submit_forecast's naming, but adds no format or validation detail beyond that. Baseline 3 applies 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 ('Get YOUR audited forecast record on VoxOdds') and spells out the two content classes returned (pending receipts and scored Brier results). It references the counterpart write tool submit_forecast, but does not distinguish itself from the similarly named sibling get_track_record, so an agent could still confuse the two.

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 timing guidance: 'Call this after submit_forecast to confirm your receipts, or any time to check your public track record.' That is clear context for when to invoke it, though it names no exclusion or alternative (e.g., get_track_record) when one of those would be preferred.

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

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

Annotations already declare readOnlyHint and openWorldHint, so safety and network reach are covered. The description adds genuinely useful behavior beyond them: the returned market is 'conservatively matched', warning that the match may be approximate, and that source links accompany the result. It does not mention freshness/latency or rate limits, which keeps 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?

The core action and its return shape lead the description, followed by the disambiguation sentences. Four short sentences with almost no filler, though the trailing voxodds.com URL is closer to product promotion than call-critical 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 need not be spelled out, and the single required parameter is fully documented in the schema. The description supplies the one thing structure cannot: that matching is conservative and that executable pricing requires a different tool. Nothing needed to call this 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?

There is a single parameter with 100% schema description coverage and an inline example ('Will the Fed cut rates in December?'), so the schema carries the semantics. The description only reinforces that the question is natural-language and about a future event, adding no format, length, or ambiguity guidance (e.g., how to phrase multi-outcome questions). 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?

States a specific verb and resource ('Get current Polymarket probabilities') plus the input shape ('natural-language event question'), so the agent knows exactly what is produced. It distinguishes itself from the executable-quote siblings (list_executable_opportunities, get_executable_quote) and from the Kalshi comparison surface, which no other sibling provides.

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 the agent: use this for indicative Polymarket probabilities, and switch to list_executable_opportunities or get_executable_quote when an executable quote is needed. It also flags where the Kalshi comparison lives, giving a when-not boundary rather than leaving the agent to guess among 17 siblings.

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

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

Annotations already declare readOnlyHint=true and openWorldHint=true, so safety is covered. The description adds real value beyond that: the research-framing disclaimer ('not financial advice') and the fact that outputs are written theses with invalidation criteria, which tells the agent the nature and authority level of the content. It doesn't discuss refresh cadence or staleness of live prices, 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?

Three tight sentences: definition and payload first, usage triggers second, sibling disambiguation and disclaimer last. Every sentence carries distinct information and the most important routing cue (the sibling alternative) is stated explicitly rather than buried.

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, an output schema present, and annotations covering the safety profile, the description supplies exactly the remaining context an agent needs: what the content is, when to select it, and which sibling to prefer instead. Nothing material 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 schema has nothing to document and the description correctly adds no parameter detail. Baseline 4 applies for a parameterless tool.

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 (get research desk theses) and enumerates the payload contents: mispriced markets, thesis, entry logic, invalidation criteria, live price tracking. It is immediately distinguishable from get_edge_signals by framing (written theses vs automated ranked flags).

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 conditions (user asks where the value is, what to research, or for trade ideas) and names the sibling alternative with the condition that selects it ('for automated ranked flags across all markets use get_edge_signals'). Nothing 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 and openWorldHint, and the description adds genuinely non-structured context: append-only same-timestamp receipts, deterministic scoring at resolution, Brier scores for AI and market, and the fact that losses are published. This is real behavioral/methodological disclosure beyond the annotations, though it doesn't discuss freshness or pagination.

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 the use-triggers are front-loaded, and the closing sentence on auditable losses reinforces (rather than repeats) the value proposition. It is slightly longer than strictly necessary but every sentence 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?

With no parameters and an output schema that covers return structure, the description supplies exactly the missing context: what the record contains, how it is scored, and that it is uncurated. Nothing needed to call or interpret the tool is absent.

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 schema has nothing to document and the baseline is 4. The description correctly implies a parameterless, aggregate look-up rather than a per-entity query.

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

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

States a specific verb ('Get') plus a precisely scoped resource ('VoxOdds' audited AI-vs-market forecast track record'), which is distinguishable from the sibling get_forecaster_record. An agent can tell what data is returned 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?

Gives explicit trigger conditions ('when the user asks whether AI forecasts beat prediction markets, how reliable VoxOdds' AI is, or for citable forecasting-performance data'), which is strong when-to-use guidance. It does not name a sibling alternative or an exclusion (e.g., vs get_forecaster_record), 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?

The archived status and the fact that it now 'returns an archive notice' is critical behavioral information that annotations (readOnlyHint, openWorldHint) do not convey at all. It also discloses the output composition, going well beyond the 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-loads the most important fact (ARCHIVED + end date) before the marketing pitch, which is good structure. The content list is slightly long but each item is informative for an agent deciding whether to call it.

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-param read tool with an output schema, the description covers the necessary behavioral state (archived), intended use, and content scope; nothing needed to invoke 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?

The tool takes zero parameters, so the schema_description_coverage baseline of 4 applies; there is no parameter semantics to add or omit.

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 ('Get a citeable World Cup 2026 prediction-market briefing') and enumerates the concrete contents (winner board, next match odds, theses, markdown). It also distinguishes itself from siblings by contrasting with 'raw odds' tools like get_world_cup_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?

'Prefer this when the user wants a narrative update or shareable explanation, not just raw odds' gives an explicit selection condition plus a named exclusion, letting an agent route between this and the odds/matchday siblings without 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 establish readOnlyHint and openWorldHint, and the description adds the critical behavioral fact that the tool no longer produces live data but returns an archive notice. It also discloses the fallback behavior when the date is omitted. It stops short of describing freshness/pagination 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 ARCHIVED status is front-loaded, which is the most important information. The middle enumeration of returned artifacts is longer than strictly necessary and partly duplicates what the output schema already covers, but every sentence is still informative.

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 the return-shape listing is redundant but harmless. The archive status, date semantics, and format are all present, leaving nothing an agent needs in order to avoid misusing this tool or to 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?

Schema coverage is 100% for the single date parameter, so the baseline would be 3. The description goes beyond the schema by explaining the omitted-date semantics ('today's slate or the next available matchday') and the YYYY-MM-DD format, adding real invocation 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 verb+resource ('Get the daily World Cup 2026 matchday market slate') and enumerates the contents returned (closest match market, strongest favorite, draw-risk watch, winner board, share-card SVG, JSON/markdown links). The ARCHIVED prefix immediately separates it from live-market siblings like get_world_cup_odds and get_world_cup_brief.

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 date-omission rule is explicit ('omit it for today's slate or the next available matchday'), and the ARCHIVED notice implicitly signals this is not for live data. However, it never names a sibling to use instead for current matchday data, so the when-not-to-use guidance is only implied.

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 (readOnlyHint, openWorldHint), and the description adds real operational context beyond them: a 10-minute refresh cadence, the prediction-market source, and $1.8B+ traded as a liquidity signal. It also discloses the archived state and that the response is just an archive notice. No rate limits or auth requirements are mentioned, but the added value 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?

Front-loading the archive notice is good structure, but the long enumeration of live odds categories is largely obsolete once the tool self-declares that it returns only an archive notice, and it actively pulls the agent toward calling a dead tool. The content is dense but internally at odds with its own opening clause.

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 shape need not be explained, and the description supplies the critical lifecycle context (ended 2026-07-19, archive-notice response) plus coverage and freshness details. The gap is that it never redirects to a live alternative, leaving an agent uncertain what to do with World Cup questions after the archive date.

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 clarify; the baseline for a no-param tool is 4. The enumerated return categories relate to output rather than inputs, which the existing output schema already covers.

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 ('Get live World Cup 2026 odds') and enumerates the exact content it covers (winner probabilities, group winners, props, specials, 1/X/2 prices). It also leads with its archived status, which is the single most important distinguishing fact. It does not explicitly name the sibling tools it overlaps with (get_world_cup_brief, get_world_cup_matchday, get_market_odds), so differentiation relies on 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?

'Call this for any question about World Cup 2026 favorites, teams, groups, or matches' gives an intended scope, but it is immediately undermined by the leading archival notice saying the tool only returns an archive notice. No alternative tool is named for live World Cup questions, so an agent has to guess whether the sibling get_world_cup_brief or get_market_odds supersedes 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 cover safety (readOnlyHint) and world scope (openWorldHint), so the bar is lower. The description adds valuable negative scope — cross-venue candidates, profits and Kalshi data are unavailable via MCP — which tells the agent what to expect from 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?

Three short sentences, front-loaded with what is returned followed by exclusions and alternatives. The URL earns its place as the only route to human comparisons; 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?

An output schema exists, so return values need not be explained, and annotations carry the safety profile. The description covers scope, exclusions and an alternative path, leaving little an agent needs 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 (family, max_capital_usd) are already documented in the schema; baseline 3 applies. The description adds no additional semantics for either parameter.

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 ('Return independent Polymarket quotes and the website notice only') and explicitly separates itself from siblings by naming list_executable_opportunities. It is clear about actual behavior, though the mismatch with its own name ('arbitrage_candidates') adds some friction an agent must reconcile.

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 routing ('Use list_executable_opportunities for Polymarket quotes') and an external human-comparison link. Guidance is present and actionable, but the redirection toward another tool for the same 'Polymarket quotes' purpose is mildly confusing rather than a clean when/when-not split.

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

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

Annotations already cover the safety profile (readOnlyHint, openWorldHint), and the description adds meaningful behavior the annotations do not: the source is a static pair directory rather than live data, results are ordered by market-id, and filters apply specifically to that directory. That data-staleness and ordering context is exactly the kind of disclosure that helps an agent calibrate trust in the 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?

Three tight sentences, front-loaded with what the tool returns and how it is ordered, then filters, then exclusions. No filler, and the most decision-relevant facts come first.

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 detail can be omitted, and the description still covers source, ordering, filter scope, and the Kalshi/cross-venue gap. The only shortfall is the absence of sibling routing, which leaves the agent to infer where this sits among the many comparison tools.

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

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

Schema coverage is 100%, so the schema already documents side, family, and amount_usd. The description only confirms that side and family filter the pair directory and is silent on amount_usd (the budget/taker-fee parameter), so it adds little beyond structured data. 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 ('List independent Polymarket quotes from the static pair directory') plus an ordering guarantee, which is concrete. It doesn't name the closest siblings (compare_executable_quotes, get_executable_quote, list_arbitrage_candidates), so an agent must still infer the boundary between 'list quotes' and 'compare executable quotes', but the object of the tool is unambiguous.

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

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

The description tells the agent what is NOT included (Kalshi prices, cross-venue rankings) and redirects to an external URL for human comparison, which is useful exclusion guidance. However, it never says when to prefer this over the many sibling listing/quote tools, so the when-to-use decision is left implied.

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 and openWorldHint, yet the description adds real behavioral context: profit is not locked unless every listed bet is accepted, odds/stake limits/settlement rules can differ, and a missing feed key yields an explicit disabled result rather than invented prices. It stops short of auth or rate-limit detail, but the disclosed caveats are meaningful.

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

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

Front-loaded with the purpose, then the algorithm, then caveats and the failure mode. Four dense sentences with no filler, though the statistical rule and the fallback behavior could be tightened slightly.

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, two-parameter tool with an output schema and covering annotations, the description supplies method, result shape (stakes, worst payout), caveats and the disabled-feed behavior. Only the sibling-routing guidance is absent, which is a minor omission given the output schema carries return detail.

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% (sport_key, capital_usd both documented with defaults), so the baseline is 3. The description reiterates that capital is split across outcomes and returns cent-rounded stakes, but adds no format or constraint detail beyond the schema.

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

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

States a specific verb and resource (find unfilled sportsbook surebet candidates) plus the exact selection rule (best decimal price per exhaustive h2h outcome, Σ(1/odds) < 1). This is precise enough to distinguish it from siblings like list_arbitrage_candidates and list_executable_opportunities without opening their 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?

Usage context is implied through 'unfilled ... across the configured live books' and the disabled-feed caveat, so an agent knows the precondition. However, it never states when to prefer this over adjacent siblings such as list_arbitrage_candidates or compare_executable_quotes, leaving the routing decision to inference.

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

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

Annotations already declare readOnlyHint=true and openWorldHint=true, so safety and world-access are covered by structured data. The description adds real behavioral context beyond that: results are ordered by 24h volume and are limited to live markets, which shapes how an agent interprets the output. It stops short of describing pagination or result count 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?

Four tight sentences with zero filler; the primary purpose and ordering are front-loaded, then filters, then the sibling routing. Every sentence earns its place.

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

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

For a read-only browsing tool with an output schema already defining return values and annotations covering safety, the description supplies everything else an agent needs: ordering, filter semantics, and the alternative tool. No meaningful gap remains.

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

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

Schema description coverage is 100%, so limit, search and category are already documented in the schema. The description restates the category enum values and clarifies that search matches the market question, which is useful but largely duplicates structured data. Baseline 3 applies 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 (List), resource (live prediction markets) and ordering (by 24h volume), which immediately separates it from get_market_odds and the quote-fetching siblings. An agent can tell this is a browsing/list tool 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?

Gives two explicit use cases ('browse what the market is pricing right now' or 'find a specific market') and names the alternative with its selecting condition: 'to answer a specific question about one event use get_market_odds.' Nothing 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?

Goes well beyond the annotations: append-only storage, same-instant price capture, Brier scoring on resolution, public scoreboard exposure, no edits or deletions, and free of charge. These are exactly the mutation consequences an agent needs before writing.

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 what the tool does and the scoring model, then parameter constraints. Two dense sentences plus a constraint sentence; slightly heavy but every clause carries information (immutability, public exposure, id source).

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?

Output schema exists so return values need not be explained. Combined with annotations and schema, the description covers lifecycle (append-only, no delete/revise), format constraints, and the market_id acquisition path, leaving no gap for correct invocation.

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

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

Schema coverage is 100%, so baseline is 3, but the description adds meaning beyond the schema: 'outcome must match one of the market's outcomes' and the public-record role of forecaster_id. The 0.01-0.99 range repeats the schema but reinforces the constraint.

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 ('submit YOUR probability forecast on a live prediction market') plus the resulting artifact (public audited track record). It is clearly distinguishable from read-only siblings like get_forecaster_record and get_market_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?

Explicitly routes the agent to list_trending_markets for a market_id and states the operation is free and irreversible. It gives clear context for when to call it, though it does not name an alternative submission path or a when-not-to-use condition.

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