Prediction Market Rule Check MCP

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

With no annotations, the description carries the full behavioral burden and does well: it states the data is free, informative only, not betting advice, 18+, includes losses, excludes unsettled picks, and reports stats such as win rate and profit. It does not explicitly declare read-only behavior or mention rate/auth constraints, but for a public informational feed the disclosure is strong.

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 key distinction ('FREE. Sports doubles feed... full SETTLED record') and keeps the relevant details together. It has some redundancy, especially repeating 'info only' and '18+', but the repetition is minor compliance boilerplate rather than disorganized 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?

Given the absence of an output schema, the description thoroughly explains what the tool returns: settled picks including losses, legs, odds at tip time, results, won/lost/void counts, win rate, average combined odds, and running flat-stake profit. It also makes the key exclusion clear, so an agent has enough information to call and interpret the tool.

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

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

Schema coverage is 100%, and the single limit parameter is already well documented in the schema, including default and range behavior plus the note that stats cover the full record. The description does not add parameter-specific meaning beyond what the schema already provides, so the baseline 3 is appropriate.

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

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

The description clearly identifies this as a settled sports doubles record tool, not a generic doubles feed. It explicitly distinguishes itself from unsettled/today-style tools by stating 'full SETTLED record' and 'Never shows unsettled picks,' which is enough to separate it from the sibling doubles_today tool.

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 usage context: retrieve the full settled record for historical results and stats, and it explicitly excludes unsettled picks. However, it does not name doubles_today or otherwise explicitly route users to the sibling tool for today's unsettled picks.

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 annotations, the description carries the full disclosure burden and does add real value: the per-call price and payment rail (x402 USDC on Base), the subscription/bundle alternative, and the info-only/18+ disclaimers. It is silent, though, on what happens with a missing or invalid access_token, whether an unpaid call returns an error or a preview, and any rate limits or refusal 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 price and payment rail are correctly front-loaded, but the tail is padded: "information only, not betting advice" restates the earlier "info only," and "18+" appears twice. The compliance text is defensible but crowds out content that would actually help invocation.

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

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

For a single-optional-parameter, read-only feed with no output schema, the description covers what the feed returns and the access model well. The remaining gap is error/no-token behavior, which matters more than usual given the paid access model.

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 only one optional parameter and the schema description covers it 100%, citing the /success source and the Authorization: Bearer alternative. The description adds nothing parameter-specific, but with full schema coverage the baseline of 4 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 and contents: today's stats-led doubles with legs, UK kick-off times, odds at tip time, combined odds, confidence and rationale. It does not differentiate itself from the sibling doubles_record, so an agent must infer the split between 'today's feed' and 'record' on its own.

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 only implied by the phrase "today's stats-led doubles," which hints at a live/current feed versus a historical sibling, but there is no explicit when-to-use, when-not, or named alternative. The paid-access note explains cost but not the conditions under which an agent should prefer another tool.

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

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

No annotations are provided, so the description carries the full disclosure burden and falls short: it never states whether this is a read-only operation, whether a subscription is required (the 'PRO' hint and access_token parameter imply a paywall but this is never confirmed), or what 'risk-score' actually yields. The only behavioral hint is the parenthetical naming which rule fields feed the scoring.

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 compact sentence with the operation and the scoping data front-loaded; nothing is padded. The unexplained 'PRO.' fragment is the one piece of noise that doesn't earn its place.

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

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

For a tool with no annotations, no output schema, and no explanation of what a risk score looks like or which sibling it supersedes, the definition leaves too much unknown. An agent cannot predict the response shape or confirm the paid-access prerequisite before invoking it.

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

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

Schema description coverage is 50% — only access_token is documented, and that documentation ('Subscriber token from /success') lives in the schema, not the description. The description adds 'by ticker' but says nothing about ticker format, case sensitivity, or what happens on an unknown ticker, so it does not compensate for the undocumented required 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 names a specific verb ('Risk-score') and a specific resource ('a Kalshi market's rules'), plus the identifier used ('by ticker') and the fields analyzed (rules_primary + rules_secondary). It does not, however, differentiate itself from closely related siblings such as rule_check, rule_check_full, or scan_risky, nor does it explain the 'PRO' prefix.

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?

There is no statement of when to use this tool versus rule_check, rule_check_full, or scan_risky, all of which appear to operate on the same rule data. The only usage signal is the 'PRO' tag, which is never explained as a subscription or access condition.

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 annotations, the description must carry behavioral burden. It signals cost ('FREE'), implies read-only via 'List', and discloses the return fields, which is useful given no output schema. But the remaining sentences ('Information only, not betting advice. Historical settlements do not predict future results. 18+. BeGambleAware.org') are compliance boilerplate that adds no operational context — nothing about pagination beyond the schema's limit, coverage of cities, or rate limits.

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 settlements handoff are correctly front-loaded in the first two sentences. However, roughly a third of the text is a trailing gambling disclaimer that an agent gains nothing from and which dilutes an otherwise tight definition.

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 listing tool with no output schema, the description covers what the tool is for, what it returns, and what to do with the result. What's missing is minor: whether results are global or fixed to a set of cities, and behavior when city/kind are omitted (all three params are optional).

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 67%, and the description compensates where the schema is silent: it explains 'by city or keyword' for the city param and enumerates the four kinds (high/low/rain/snow) whose enum has no schema description. It adds nothing for limit, but the schema already covers that with 'default 25, max 100'.

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 Kalshi weather series (daily high/low temperature, rain, snow)' — with the filtering axis (city or keyword) and the fields returned (ticker, frequency, settlement source). It also positions itself against the complementary sibling kalshi_weather_settlements, so an agent can tell the two apart 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?

'Use the ticker with kalshi_weather_settlements' gives an explicit downstream handoff, which is genuine routing guidance. It does not state any when-not-to-use condition or name a competing discovery tool (market_lookup, search_markets), so it stops short of full when/when-not coverage.

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 annotations, the description carries the burden well: it discloses the paid x402/subscription model with a concrete price, the auth path (token from /success or Bearer), the fact that values can be null when Kalshi provides none, and the exact fields returned. It does not explicitly say the operation is read-only or discuss rate limits beyond pricing, 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?

It is front-loaded with pricing and the core purpose, but the body is one very long run-on sentence that enumerates many output fields, making it dense and hard to scan. The legal boilerplate (18+, BeGambleAware) is likely required but consumes space without helping tool selection.

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 7-parameter tool with no output schema and no annotations, the description compensates well by enumerating the returned fields (ticker, close times, settlement time, gaps, strike, payout, observed value, source) and covering auth and pricing. It is nearly complete, missing only an explicit note on read-only behavior or return ordering/pagination.

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 every parameter is already documented in the schema, including the series-vs-city alternative and the kind enum. The description reinforces the series/city duality and optional date range but adds no format, default, or constraint detail beyond what the schema states. 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 clearly states the tool returns settled Kalshi weather markets for a series or city, naming concrete examples (KXHIGHNY). It is distinguishable from a live-markets tool by the word 'settled', but it never explicitly contrasts itself with the sibling kalshi_weather_series, leaving that differentiation 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 implies usage ('settled', 'historical settlements') and says the date range is optional, so an agent can infer this is the historical lookup. However, it never states when to prefer this over kalshi_weather_series or live_markets, nor any exclusions or prerequisites beyond the access_token mention.

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 annotations, the description carries the full burden and does disclose two non-obvious behaviors: the x402 paid model ($0.02/call or subscription) and the exact result ordering (24h volume within each venue, interleaved). It does not cover what happens on missing/failed payment or whether results are paginated beyond limit.

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 with zero filler. Minor deduction: the cost/payment notice is front-loaded ahead of the actual purpose, which delays the agent's identification of what the tool does.

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?

Sources, ordering, filters, and payment model are all covered for a 4-param read tool with no output schema. The remaining gap is that no return fields are described and there is no output schema to compensate, so an agent cannot anticipate the response shape.

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

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

Schema description coverage is 100%, so limit, venue, contains, and access_token are all documented in the schema itself. The description only restates the filtering capability, 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?

States a specific resource (live open markets) with both named sources (Polymarket, Kalshi) and a defined ordering rule (24h volume per venue, interleaved). This distinguishes it from siblings like search_markets or market_lookup, though no sibling is named explicitly.

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

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

The description implies usage via 'Filter by venue or text' and the volume-ranked live listing, but never says when to choose this over search_markets, market_lookup, or top_movers. With 11 siblings, an explicit routing hint would materially help.

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?

No annotations exist, so the description carries the full behavioral burden. It usefully discloses that the call is FREE and that it returns live (not historical) data plus the specific fields, but says nothing about rate limits, error behavior for an invalid slug/ticker, or coverage of closed/settled markets.

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, with the high-value 'FREE' signal and the single-market scope front-loaded. Nothing is wasted.

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

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

For a one-parameter lookup with no output schema, the description names the returned fields (price, volume, close time) and the schema-format used, which is enough for an agent to call it correctly. Minor gaps remain around failure cases and data freshness guarantees.

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 parameter is documented with two concrete format examples (slug and ticker). The description's instruction to supply a slug or ticker largely restates the schema, so it adds 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 retrieval verb and the exact resource: live price, volume and close time for a single market in a normalised Polymarket+Kalshi schema. The 'ONE prediction market' framing distinguishes it from siblings like live_markets and search_markets that clearly operate on multiple markets.

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?

'Give a Polymarket slug or a Kalshi ticker' tells the agent the precondition for calling it, and 'ONE' implies bulk listings belong elsewhere. It stops short of explicitly naming live_markets or search_markets as the alternatives for multi-market queries, so it is context-rich but not 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?

No annotations are present, so the description carries the full burden. It usefully discloses the scoring dimensions and the 'Top 2 markets' cap, but says nothing about whether it is read-only, how it handles zero or many matches, rate/cost mechanics beyond 'FREE', or what the output looks like beyond flags.

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, zero waste, and the cost signal leads. Each clause adds information: cost, action, criteria, and result cap.

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 annotations and no output schema, the description should fully explain behavior and returns. It signals output concepts (risk score plus flags) but leaves the result shape and the relationship to rule_check_full unclear, so a caller still has open questions.

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?

One parameter with 100% schema coverage, so the baseline is 3. The description's 'slug or search words' merely restates the schema text and adds no format, example, or disambiguation guidance.

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

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

Specific verb and resource: risk-scores the settlement rules of a Polymarket market, with concrete criteria named (discretion, vague sources, cancellation, deadline traps). It doesn't name or distinguish itself from the sibling rule_check_full, so the agent must infer the free/limited-vs-full split from the word 'FREE' and 'Top 2 markets'.

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 only implied: 'FREE' plus 'Top 2 markets' hints this is a limited preview and that rule_check_full covers more, but no alternative is named and no exclusion is stated. An agent must guess when to escalate to the full version.

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?

No annotations are provided, so the description carries the full burden. It does disclose one useful behavioral fact — results are capped at 10 markets — but says nothing about auth requirements (only implied by the schema's access_token), whether 'flags' means risk warnings, rate limits, or what happens when a slug matches nothing.

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 sentence, front-loaded with the highest-value information (full rule text + resolution source) and ending with the matching scope and batch limit. The 'PRO.' prefix is slightly cryptic but short enough not to waste space.

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 and no annotations, the description does reasonably well by enumerating the returned fields (rule text, resolution source, flags) and the 10-market cap. It still leaves auth failure behavior and the meaning of 'flags' unexplained, which matters for a tool that requires a subscriber token.

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 50%: access_token is documented in the schema, while market is undocumented there. The description partially compensates by explaining that market can be a slug or a search string, which is genuinely new information, but it gives no matching/precedence 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 names a specific verb and resource: returns full rule text, resolution source and all flags for Polymarket markets matched by slug or search. It clearly differs from the sibling rule_check by promising 'full' detail, though it never explicitly contrasts the two, so the differentiation is inferred rather than stated.

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 only implied: the 'PRO' prefix hints at a paid tier and the 'full' framing hints at deeper output than rule_check. There is no explicit statement of when to pick this over rule_check or search_markets, and no prerequisites beyond the token parameter.

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?

No annotations are provided, so the description carries the full behavioral burden. It discloses that the scan is limited to top live markets by volume and focuses on settlement wording, but it omits the authentication requirement implied by access_token, return format, rate limits, and how risk is scored.

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

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

The description is a single efficient sentence and front-loads the action. The leading 'PRO.' is minor noise, but the core statement is compact and clear.

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 annotations, no output schema, and incomplete parameter documentation, the description should do more. It does not explain authentication, return shape, scoring, or parameter behavior, leaving an agent without enough context to invoke it confidently.

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

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

There are three parameters and only access_token has schema description coverage (33%). The description does not explain limit, min_score, or access_token semantics, so it does not compensate for the low schema coverage.

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

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

The description gives a specific verb and resource: scan top live Polymarket markets by volume and list those with risky settlement wording. It distinguishes the output intent from generic market listing, but does not explicitly differentiate itself from siblings like live_markets, search_markets, or rule_check.

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 implies the tool is for finding markets with risky settlement wording, but gives no explicit when-to-use guidance, exclusions, or alternatives. An agent is left to infer whether to use this instead of rule_check, live_markets, or search_markets.

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 annotations, the description carries the full disclosure burden, and it does surface two non-obvious traits: a per-call price ($0.02 via x402) and an alternate subscription path, plus that prices and volumes come back normalised. It still omits rate limits, pagination behaviour, failure modes, and how the two auth paths interact, so the behavioral picture is incomplete.

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 padding, and the cost note is placed first so an agent sees the paid precondition before deciding to call. Slightly at odds with front-loading the core purpose, but defensible for a metered tool.

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 four-parameter search tool with no output schema and no annotations, the description covers purpose, cost, source venues, and the shape of returned data. It leaves gaps around result ordering, pagination past the limit, and error/empty-result behaviour that an agent would want before relying on it.

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

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

Schema coverage is 75%, so limit and venue are already documented, and access_token explains its own source. The description's example keywords ('fed rate', 'bitcoin', 'election') add real meaning about what query accepts — free-text topic terms rather than market IDs or slugs — which the bare string schema does not convey.

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 gives a specific verb and resource ('Keyword search across live Polymarket and Kalshi markets') plus concrete example queries, so an agent knows exactly what the tool returns conceptually. It does not name or distinguish itself from close siblings such as market_lookup or live_markets, which keeps it 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?

Usage is implied by 'keyword search' plus example keywords, and the payment line signals a cost prerequisite an agent should consider before calling. There is no explicit guidance on when to prefer market_lookup or live_markets instead, and no stated 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?

With no annotations, the description carries the full burden. It usefully discloses that the tool is paid ($0.02/call or subscription via x402) and that it normalizes across two venues into one schema, but it does not describe return ordering, freshness, rate limits, or whether results are cached/snapshot-based.

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 no wasted wording. Pricing is front-loaded, which is arguably less important than the core purpose, but the purpose follows immediately and is clear.

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, parameter-light read tool, the description covers pricing, venue coverage, and cross-venue schema unification. It still leaves gaps around return ordering, result freshness, and whether top movers are computed over fixed or rolling 24h windows.

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

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

Schema description coverage is 100%, so the parameters are already well documented. The description does not add meaning beyond the schema, such as how sorting interacts with limit or how venue=all orders results across venues.

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

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

The description clearly states what the tool returns: live markets with the biggest 24h price moves across Polymarket and Kalshi, unified in one schema. It is specific about resource and scope, though it does not explicitly position itself against siblings such as live_markets or doubles_today.

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 by 'biggest 24h price moves', suggesting discovery of top movers. However, there is no explicit guidance on when to choose this over live_markets or other sibling tools, and no exclusions are stated.

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