Oddsradarwire — Live & Prematch Betradar Odds with No-Vig Probabilities

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

Annotations only declare readOnlyHint, so the description adds useful behavioral context: the call is cheap, reflects the product's own board, and does not include prices. It also discloses the 'last catalog walk' timestamp as part of the response semantics, going beyond the structured annotation.

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

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

The description is three tight sentences with no filler. The most important information is front-loaded, followed by usage guidance and then clarifying exclusions, each earning 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 zero-parameter, read-only coverage check with no output schema, the description covers what it returns, why you would call it, and what it does not include. The guidance about resolving sport filters adds practical context that makes the tool self-sufficient.

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 zero parameters, so the baseline is 4. The description does not need to explain parameter meaning, and none is missing.

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

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

The description states exactly what the tool reports: live and pre-game fixture counts per sport plus the last catalog walk time. It explicitly distinguishes itself from an upsell meter and price-bearing tools, which differentiates it from siblings like get_live_odds and get_prematch_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?

The description gives clear when-to-use guidance: call it first to decide whether a full board fetch is worth it, and to resolve a sport filter to a sport with fixtures. It also tells what it is not for ('not an upsell meter and carries no prices'), though it does not name alternative sibling tools explicitly.

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

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

Annotations only declare readOnlyHint=true, so the description carries the behavioral burden. It adds valuable context: only OPEN markets are returned by default, RESULTED selections never carry a price under any query, and a finished fixture can 404 as normal market lifecycle rather than an outage. These details go well beyond what the annotations reveal.

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 dense sentences, each earning its place: purpose is front-loaded, usage guidance follows, and behavioral caveats close out the description. No filler or repetition of schema boilerplate.

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

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

With no output schema, the description adequately names the return contents and covers the key edge cases (closed/suspended/resulted filtering, missing prices, 404 on finished fixtures). An agent has enough context to invoke the tool correctly and interpret unexpected results.

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

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

Schema description coverage is 100%, so the baseline is 3. The description reinforces the include parameter's default behavior and the resulted-price caveat, but it does not meaningfully add parameter syntax or type information beyond what the schema already documents.

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

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

States a specific verb and resource: 'One fixture in full by id' and enumerates exactly what is returned (normalized markets with canonical key, tier, structure, status, decimal price, no-vig probability). It also distinguishes itself from the odds-listing siblings by specifying it is the follow-up call when a single match needs its whole market list.

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

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

Explicitly says when to use it: after get_live_odds or get_prematch_odds returns an id, when one match needs its entire market list. This names the alternatives and the condition that selects this tool, leaving no ambiguity about the intended call sequence.

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

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

Annotations already declare readOnlyHint=true, so the safety profile is covered. The description adds valuable behavioral context: it does not count against the rate limit, and it clarifies that generated_at is response time, not the age of a source price tick. It also enumerates the fields returned. This exceeds what annotations provide, though it doesn't discuss error behavior or edge cases.

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 concise, with no filler. It front-loads the main purpose, then provides usage guidance and a clarification about generated_at. Every sentence earns its place, and the structure flows logically from purpose to usage to a subtle caveat.

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

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

For a zero-parameter health check tool with no output schema, the description is complete. It explains what the tool reports, when to use it, and a key nuance about timestamps. An agent has all necessary information to call it correctly and interpret results.

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

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

The tool has zero parameters, so there is nothing to document beyond the schema. The baseline for 0 parameters is 4, and the description does not need to compensate for any missing parameter information. It correctly omits any parameter details because there are none.

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 it reports feed liveness and freshness, listing specific fields (upstream connection, seconds since last price frame, board size, market coverage, walk errors). It is distinct from sibling tools like get_coverage or get_live_odds, which focus on data content rather than health. The verb 'get' and resource 'health' are specific and unambiguous.

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

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

The description provides explicit guidance on when to call: before describing any data as current/fresh and after a 503 error. It also notes that the tool does not count against the rate limit, which is an important usage consideration. This goes beyond just describing what it does and gives clear invocation context.

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

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

Beyond the readOnlyHint annotation, the description discloses substantial behavioral detail: no-vig probabilities are passed through unmodified, the overround is ~8.4%, only 'exclusive' markets partition the outcome space, and decided live matches close their moneyline rather than returning missing data. These caveats prevent serious misuse and add real value beyond 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?

The description is longer than average, but every sentence earns its place: core definition, use cases, data semantics, market-structure warning, and explicit non-uses. It is front-loaded with the essential purpose, and the caveats appear in logical order without 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 read-only odds tool with no output schema, the description is remarkably complete. It explains what is returned (open markets, decimal prices, no-vig probabilities), how to interpret them, current-only freshness, and key edge cases like closed moneylines and non-exclusive markets. An agent has enough context to call this tool correctly and interpret results safely.

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

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

Schema description coverage is 100%, so the baseline applies: the input schema already fully documents tier, limit, and sport. The description itself adds little parameter-specific meaning, though it reinforces context like limit trimming and sport vocabulary through other parts of the definition. No deduction is warranted because the schema is already strong.

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

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

The description opens with a specific verb and resource: 'Current live (in-play) odds for this product's board: every fixture with its OPEN markets, decimal prices and the no-vig probability on each selection.' It also distinguishes itself from multi-book scanning, historical archives, and bet placement, making its scope unmistakable and clearly separate from siblings like get_prematch_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?

The description explicitly lists intended use cases ('live odds displays, arbitrage or middles checks against another book, in-play models and feature engineering, no-vig fair value, and agent workflows that need current prices') and gives explicit exclusions ('Not a multi-book scanner', 'Not a historical archive', 'Not a bet-placement tool'). It also points to list_sports and get_coverage as alternatives for sport vocabulary, giving an agent clear routing guidance.

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

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

Annotations include readOnlyHint=true, but the description adds critical behavioral context: it costs no API quota, the demo bucket is shared across callers so usage can be affected by others, and it provides usage so far today. These details are not captured by the annotation and are essential for correct interpretation of 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?

The description is compact, with two sentences, but the first sentence is telegraphic and slightly awkward ('This key: plan...'). Still, it is front-loaded with the core purpose and contains no wasted words. It could be more elegantly phrased, but it is efficiently structured.

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

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

Given no parameters, no output schema, and a single readOnly annotation, the description provides comprehensive context: what it returns, when to use it, behavioral caveats (shared demo bucket), and what it is not. An agent can fully understand the tool's purpose and limitations without additional information.

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

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

The tool has zero parameters, so there is nothing for the description to explain. Per the rubric, the baseline is 4 for 0 parameters. The description adds no param-related details, which is appropriate since there are none.

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 exactly what the tool returns: plan, per-second/per-minute/per-day limits, SSE entitlement, and usage so far today. This is a specific resource (plan limits) and distinguishes it from sibling tools like get_live_odds or list_sports which deal with odds and sports data. The mention of 'Costs no API quota' further clarifies its nature.

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

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

The description explicitly says when to use it: to explain 429 or 401 errors to the user and to tell them which limits they are on. It also provides a negative use case ('Not a billing or payment-history endpoint'), giving clear exclusions. This goes beyond implied usage and provides actionable guidance.

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

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

The description adds behavioral context beyond the readOnlyHint annotation: the tool returns a snapshot, has no line history, and requires the caller to snapshot responses themselves for historical tracking. It also clarifies that it is not an archive, which is non-obvious and valuable for correct use.

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

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

The description is dense but front-loaded: the core definition comes first, followed by use cases, then shape comparison, then explicit exclusions. Every sentence contributes useful selection or invocation information, with no filler.

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

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

For a read-only tool with no required parameters, fully documented schema, and no output schema, the description provides enough context: exact semantic scope, a shape reference to get_live_odds, and limitations on historical data. An agent can select and invoke it correctly without additional clarification.

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

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

Schema description coverage is 100%, so all three parameters are already documented with defaults, bounds, and meaning. The description does not add parameter-level semantics beyond what the schema provides, so the baseline of 3 is appropriate.

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

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

The description states a specific verb and resource: it returns current pre-game odds for the product's board, including open markets, decimal prices, and no-vig probability. It also distinguishes itself from the sibling get_live_odds by saying it is the same shape but for prematch odds, so an agent can tell them apart.

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

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

Explicit use cases are given: pre-game prices, closing-line-value work, pre-match modelling, and no-vig fair value. It also provides clear exclusions — not an opening/closing archive, not a multi-book scanner, and not a bet-placement tool — so an agent knows when not to select 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?

readOnlyHint=true already covers the read-only trait; the description adds substantial context beyond it: 'Costs no API quota' (cost behavior), 'A listed sport may have no fixtures today' (availability caveat), and 'each product serves only its own provider' (scoping constraint). No contradiction with 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?

Four sentences, each earning its place: purpose, quota cost, data caveat, and sibling routing. The core purpose is front-loaded in the first sentence, and the closing 'which sport ids exist, not what is live' reinforces the scope without 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 zero-parameter, read-only enumeration with no output schema, the description covers everything needed: what is returned (sport ids), how the output is used (sport= filter), cost behavior, provider scoping, and the correct sibling for live data. 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?

With zero parameters the baseline is 4, and the description earns it by explaining the downstream use of the returned values — 'so a sport= filter is never a guess' — which tells the agent how the output is consumed. Trivial 100% schema coverage for an empty schema adds nothing, so the filter-usage hint is the only semantic value, and it is genuinely useful.

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 the resource and result — every sport id the wire understands — and closes with an explicit contrast: 'Answers "which sport ids exist", not "what is live"'. It names and differentiates the sibling get_coverage directly. The only minor opacity is the unexplained domain term 'wire', which does not obscure the core purpose.

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 routing: 'use get_coverage for what is actually on the board' and warns each product serves only its own provider. It also clarifies when not to use this tool — it answers existence, not live status. No inference is required to choose between this and alternatives.

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