TheRundown Data MCP

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

Annotations already cover the read-only/idempotent/non-destructive safety profile, and the description adds substantial context beyond them: an auth gate requirement, a no-wager guarantee, hard capture bounds (5 seconds, 50 messages, 256 KiB), and an explicit caveat of no guaranteed opportunities or continuous coverage. This is exactly the kind of behavioral disclosure the annotations don't carry.

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

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

It is front-loaded with the core action and stays dense – each sentence contributes a distinct fact (access, no-wager, limits, caveats). Slightly thick for the payload but nothing is redundant 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 the behavioral limits are well covered. The real gap is a fully undocumented nested parameter set that the description does nothing to clarify, leaving an agent under-informed on how to actually construct the capture request.

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 0% and the schema contains a nested filters object with six sub-fields (sources, event_ids, min_percent, include_live, affiliate_ids, include_links) plus max_frames and duration_ms. The description only loosely gestures at 'selected events and books' and never explains any parameter's meaning, so it fails to compensate for the coverage gap.

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: 'Read actual frames from the dedicated V2 hedge WebSocket for selected events and books.' The word 'V2 hedge' distinguishes it from the nearby capture_v1_stream/capture_live_stream/capture_market_stream siblings, but the description never names those alternatives explicitly, so the differentiation is implicit 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?

It notes the access precondition ('Requires HedgeAccess or an eligible pass; this dedicated route has its own gate') and clarifies that it places no wagers, which frames usage somewhat. However, it gives no explicit when-to-use-vs-alternatives guidance against the three sibling capture_* tools, so the agent must infer which stream to pick.

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: hard limits (three subscriptions, five seconds, 50 messages, 256 KiB), socket closure, no continuous feed or auto-reconnect, durable resume only for plays, and the instruction to report incomplete snapshot/replay and gaps. These are exactly the operational traits an agent needs and that readOnlyHint/idempotentHint cannot convey.

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 is read, then constraints. Information-dense with no filler, though the middle sentences are long and run-on, which slightly hurts scannability. Every sentence carries load-bearing 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?

For a complex streaming capture tool with an output schema available, the description covers the capability, entitlements, hard limits, termination behavior, and failure reporting. Return-value explanation is rightly omitted because an output schema exists. Only deep per-field subscription semantics remain thin, which is a minor gap.

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

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

Schema description coverage is 0%, so the description must carry parameter meaning. It partially does: it maps subscriptions, the action verbs (snapshot, resync, usage, unsubscribe), resume-for-plays, and the limits that correspond to max_frames (50) and duration_ms (5000). However, the many nested subscription filter fields (event_ids, market_ids, participant_ids, sequences, etc.) get no explanation, leaving a substantial gap.

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

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

States a clear verb (Read) and resource (multiplexed WebSocket markets, scores, plays, stats, live game state, futures, hedge frames), enumerating the channel surface. This distinguishes it from siblings like capture_market_stream and capture_hedge_stream, though it never explicitly names those alternatives to sharpen the boundary.

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

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

Gives concrete preconditions for use: per-channel entitlement, and for priced channels all periods, live/player-prop access and no delay. It also points to an alternative path ('Restricted custom plans can use REST') and notes stats needs a REST baseline. It stops short of naming a specific sibling tool to use instead.

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

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

Annotations cover the safety profile (readOnly, idempotent, openWorld, non-destructive), and the description goes well beyond them: it discloses the socket lifecycle budget (5 seconds / 50 messages / 256 KiB then close) and warns that an empty capture is not proof of no changes or no coverage. That is exactly the operational context annotations cannot convey.

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 dense sentences ordered purpose → prerequisites → runtime budget → caveat, with no filler. Slightly information-dense but 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 streaming capture tool with an existing output schema, the description supplies prerequisites, lifetime limits and interpretation caveats; return-value explanation is correctly delegated to the output schema. Nothing an agent needs to invoke it correctly is missing.

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

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

Schema description coverage is 0% with 3 params and a nested filter object holding 5 sub-keys. The description names the event/sport/market/affiliate filter dimensions and echoes the frame/duration ceilings, but leaves main_line and the exact syntax of each filter array unaddressed, so it only partially compensates for the coverage gap.

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+protocol: 'Read actual V2 market-price WebSocket frames', scoped by explicit filters. This clearly separates it from sibling capture_hedge_stream, capture_live_stream and capture_v1_stream, which cover other streams.

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 a clear eligibility gate ('Requires eligible WebSocket access with all periods, live/player-prop access and no delay') and a when-not condition ('restricted custom plans must use REST'). It stops short of naming the specific sibling capture_* tool or REST endpoint an ineligible agent should switch to.

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?

Adds substantial behavior beyond the annotations: bounded execution (one socket, closes after at most 5 seconds, 50 messages or 256 KiB) and no ongoing background delivery, which tells the agent this is a one-shot sample rather than a subscription. Auth/entitlement requirements are also disclosed. The annotations already carry the read-only/idempotent safety profile, so this is strong but not exhaustive (no error/failure-mode detail).

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, zero filler, with the routing constraint and access prerequisites front-loaded ahead of the execution-bound details. Every clause carries information an agent needs.

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

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

An output schema exists and the annotations cover safety, so the description's job is mostly routing, auth, and lifetime semantics — all of which are present and precise. The remaining gap is the unexplained filters object, which for a capture tool is the main selection surface.

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 0% and the tool has a nested filters object with date, event_ids, sport_ids and affiliate_ids, none of which the description explains (formats, cardinality caps, mutual constraints). The '50 messages' and 'five seconds' language loosely maps to max_frames and duration_ms, but the primary required parameter is left entirely opaque.

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 (read) and resource (actual frames from the V1 WebSocket), scoped to selected events and books. It explicitly distinguishes itself from the V2 market tools and the other capture_* siblings by naming the legacy line contract it serves.

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 an explicit when-not ('use only for legacy line contracts; prefer V2 market tools') and a hard prerequisite (eligible WebSocket access with all periods, live/player-prop access, no delay), plus the fallback for restricted plans (REST). An agent can route correctly without opening any schema.

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 (readOnly, idempotent, non-destructive), and the description adds genuinely new context: retrieved_at is not price freshness, and each local page is metered (a cost/rate constraint not visible in annotations). The 'preserves participant identity, line value and price updated_at' sentence overlaps the output schema, so it is slightly redundant rather than additive.

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, then the gating precondition, then caveats and cost note. Every sentence carries operational weight except the 'preserves ...' line, which restates output-schema content and could be dropped.

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, yet the description does so anyway (mild redundancy). For a metered, ID-gated read tool with five parameters, the description covers invocation preconditions, cost, and market selection well; only page/limit behavior is left entirely to the schema.

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

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

Schema coverage is 60%, and the description reinforces the key semantic gap: market_ids defaults to prematch 1/2/3, so live data requires explicitly requesting 41/42/43, and event_id must come from list_events rather than a URL. It adds operational meaning over the schema, though it says nothing about page/limit tuning.

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 (Fetch) and resource (open per-affiliate main lines) plus the exact scope (one event_id). An agent can immediately tell this apart from the list_* discovery siblings, which enumerate rather than retrieve lines for a known event.

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 precondition: 'Do not call until list_events returned that exact ID' names the alternative tool and the condition that gates this one. It also gives an override instruction for live markets (41/42/43), so the agent knows how to change behavior rather than relying on the prematch default.

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, idempotentHint, destructiveHint=false, openWorldHint), so the description only needs to add what they don't say. It does: the result set is limited to currently published affiliates with retired entries filtered out, and it warns that a catalog row does not imply plan access or an open offer — meaningful semantic context beyond the annotations. It stops short of noting ordering, freshness, or result size.

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, no filler. The concrete behavior (what is listed, what is excluded) is front-loaded, and the cautionary note follows only after the core purpose is established.

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 zero parameters, an output schema present, and annotations covering safety and idempotency, the description carries little remaining burden — and it meets it by defining scope and the correct interpretation of results. Minor omissions (ordering, pagination, or volume of affiliates) are the only reason this isn't a 5.

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

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

The tool takes zero parameters, so the baseline is 4 by rule; there are no parameter semantics for the description to clarify. Nothing in the description misrepresents the (empty) input contract, and it helpfully clarifies the implicit output scope instead.

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') and resource ('affiliate IDs and names') with an explicit scope qualifier: currently published, retired ones excluded. An agent can separate this from sibling catalog tools like list_sports or list_markets without opening any schema, and it even discloses which fields are returned.

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 an interpretation caveat ('Do not use a catalog row as proof of plan access or an open offer'), which is useful guidance about the meaning of results. However, it never says when to prefer this tool over the sibling list_* tools, nor does it name any alternative or exclusion condition for tool selection. Usage is therefore implied rather than directed.

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

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

Annotations already declare readOnly, idempotent and openWorld, so the safety profile is covered. The description adds real behavioral context beyond them: default market/affiliate selections and the important note that each page refetch hits a metered snapshot, which implies request cost. It stops short of stating rate limits or pagination semantics.

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 tightly packed sentences with no filler, ordered from purpose to exclusions to defaults/behavior. The critical routing constraint is front-loaded ahead of the defaults.

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 format need not be explained, and annotations cover safety. The description supplies the routing and cost context an agent needs for a 7-parameter tool, though a few unmentioned parameters (page/limit/offset) are left solely to the schema.

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

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

Schema coverage is 57%, above the baseline threshold, and the schema documents date, offset, market_ids and affiliate_ids in detail. The description restates default values (1/2/3 and 19/23) already present in the schema and says nothing about page, limit, offset or sport_id, so it adds little beyond the structured fields.

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 event IDs and summaries') plus its scope ('for one sport and date'), which is exactly the identity an agent needs. It also distinguishes itself from siblings by naming get_main_lines as the downstream consumer of the returned IDs.

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 exclusions ('Do not use this tool for futures or as a price quote') and names the correct alternative pattern ('use the returned exact event ID with get_main_lines'). This is a clear when-to-use / when-not-to-use / what-else 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 readOnly/idempotent/non-destructive/openWorld, but the description adds real behavioral context beyond them: a plan-tier eligibility gate (Ultra or higher), opaque cursor pagination, and a warning that a partial page must not be treated as a full listing. These are non-obvious operational traits.

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, all front-loaded: scope first, then exclusions, then plan/pagination constraints. No filler, every sentence carries a distinct constraint.

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, and the description covers scope, exclusions, plan gating, and pagination. The remaining gap is per-parameter semantics for the four undocumented parameters, which is minor but not fully closed.

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

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

Schema description coverage is only 33%; only market_ids and affiliate_ids carry inline descriptions. The description mentions cursor pagination but adds no meaning for sport_id, limit, include_settled, or the semantics of cursor values, so it fails to compensate for the coverage gap.

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+resource ('read one sport's scoped futures competition page'), which is concrete and distinguishes the tool's domain from generic listing. It implicitly separates itself from dated-event tools by calling out 'dated event discovery', though it doesn't name the sibling (list_events) directly.

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

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

Explicitly states when NOT to use it ('Do not use this for dated event discovery') and adds two further caveats: partial pages are not complete listings, and futures require an eligible Ultra plan. This is concrete when/when-not guidance not derivable from the schema.

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

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

Annotations already declare readOnly/idempotent/openWorld safety, so the bar is lower, and the description adds two genuine behavioral constraints: definitions are not price quotes, and live cannot be combined with date-based discovery. It omits pagination behavior and response shape, and the closing 'catalog metadata' sentence is jargon that resists interpretation.

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

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

Three compact sentences with the core capability front-loaded and constraints following. No wasted filler, but the final sentence is dense jargon-heavy shorthand that would benefit from one clarifying 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 values need not be explained. However, with 0 required params, 17% schema coverage, and no enum for sport_id or explanation of the pagination-vs-time-offset distinction, the description leaves an agent guessing about valid inputs and mutual exclusivity of live/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?

Schema description coverage is only 17% across 6 params, so the description must compensate. It implies date, sport_id, and live are mutually constrained (one sport, one date, live vs. date-based), but it says nothing about page/limit/offset semantics — and 'offset' here is a minutes-based date boundary, not pagination, an ambiguity the description does not resolve.

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 ('Discover') and resource (market definitions / available markets) and distinguishes two modes: definitions vs. sport/date-scoped availability. It does not name or contrast itself against any sibling tool such as list_sports or list_events, so it stops short of a 5.

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

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

Provides real when-not guidance: do not use definitions as price quotes, and do not combine live with date-based discovery. It also points to catalog metadata for sport/live filters. It never names an alternative tool to use instead, so it falls short of a 5.

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

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

Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the safety profile is covered by structured data. The description adds that the returned IDs/names are static catalog metadata not tied to live events/prices, which is genuinely useful context beyond annotations but limited in depth.

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 with zero waste; the primary purpose is front-loaded and the caveat follows efficiently.

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 available, the description needn't explain return values. Combined with annotations and full schema coverage, it is complete enough for an agent to call this zero-arg list tool, though it could more explicitly position itself against sibling listing 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?

The tool takes zero parameters, so the baseline is 4. The description correctly implies no filtering arguments are needed.

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') and resource ('current canonical sport IDs and names'), making the scope and output explicit. It is clearly distinguishable from siblings like list_events or list_markets, which cover different resources.

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

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

Provides a caution ('Do not use a catalog row as evidence of current events, prices, or plan access') that governs downstream usage, but gives no when-to-use guidance relative to alternatives such as list_events or get_main_lines.

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 (readOnly, idempotent, openWorld, non-destructive), yet the description adds genuinely non-obvious behavior: Affiliate 27 is excluded, empty results don't imply missing coverage, and there is no polling/retry or account/wager mutation. These are real operational caveats an agent could not derive from the schema or annotations.

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

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

It is compact with no obvious filler, but it is a run-on cluster of clipped fragments with a missing sentence boundary after the opening clause ("...sportsbooks/affiliates Read-only Product data..."). Content is efficient; structure is poor and hurts front-loading.

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?

The tool is simple (one optional nested param, output schema present), so return values need no explanation, and the description covers the key caveats about exclusions and result interpretation. The remaining hole is that the `query` parameter is entirely unexplained.

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 0% for a single nested `query.include` parameter whose only meaningful value is the `regions` enum. The description says nothing about how to use `query`, what `include` accepts, or whether it omits/expands fields, so it fails to compensate for the coverage gap.

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 ("List all sportsbooks/affiliates"), so an agent knows exactly what it returns. However, it never distinguishes itself from the near-identical siblings v2GetAffiliates, list_affiliates, or v1GetSportsbooks, which is exactly the disambiguation an agent needs. Clear purpose, missing sibling differentiation.

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 offers implied guidance: use the returned canonical IDs downstream, treat one request as bounded, and don't infer coverage from an empty result. But it gives no explicit when-to-use vs the v2/list_affiliates alternatives, which is the main selection question for this tool.

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

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

Annotations already declare readOnly/idempotent/non-destructive/openWorld, so the bar is lower, yet the description adds real value beyond them: a bounded single request with no polling or auto-retry, metered usage tied to the connected account, affiliate 27 exclusion, and the warning that an empty result does not imply coverage.

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

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

The purpose is front-loaded, but the body is a run-on chain of clauses with no sentence break after 'multiple events' and no grouping of access, coverage, and exclusion caveats. Every clause is relevant, but the structure makes it hard to scan.

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

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

An output schema exists so return values need not be explained, and annotations cover the safety profile; the description fills the remaining gaps (rate/usage model, retry behavior, coverage caveat, affiliate exclusion). Only the nested request shape and period parameter remain unaddressed.

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

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

Schema description coverage is reported at 0%, though event_ids and affiliate_ids do carry inline descriptions in the schema. The description only reinforces 'canonical IDs' and the affiliate 27 exclusion, and says nothing about the nested 'query' wrapper or the 'period' enum/default, so it only partially compensates.

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 best lines') and the scope 'multiple events', which distinguishes it from the singular sibling v2GetBestLineByEvent. However the opening sentence runs directly into unrelated clauses, and it never contrasts itself with closer siblings like v2GetBestOdds or get_main_lines.

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 scattered operational guidance ('Use returned canonical IDs', 'never infer coverage from an empty result', 'no background polling or automatic retry') but never states when to choose this over the many sibling best-line/odds tools. Usage is implied rather than routed.

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

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

Annotations already declare readOnly, idempotent, openWorld, non-destructive, but the description adds real behavioral context beyond them: metered usage and account-dependent access/delay, a single bounded request with no polling or auto-retry, affiliate 27 exclusion, and the caveat that an empty result does not prove lack of coverage.

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

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

The purpose is front-loaded, but the body is a run-on sequence of policy fragments ('Read-only Product data or price calculation', 'Access, delay and metered usage...') that mixes purpose, safety, and caveats without clear structure. It is compact but not cleanly organized.

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. However, for a nested 2-parameter tool with 0% schema description coverage and many near-identical siblings, the description omits parameter meaning and sibling differentiation, so an agent still lacks enough 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?

Schema description coverage is 0%, so the schema documents only types and patterns for eventId, lineId, and the 'include' enum. The description never explains what lineId is, how it differs from eventId, or what the include=all_periods option returns; 'Use returned canonical IDs' is the only faint hint and is not tied to a named 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 opening phrase 'Get event by line ID' states a verb and resource, but it is essentially a restatement of the title and name rather than a richer explanation. It does not distinguish this tool from close siblings like v1GetEventByID or v2GetEventByID, leaving the agent to guess which lookup key (line ID vs event ID) selects it.

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

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

There is no explicit when-to-use or when-not-to-use guidance, and no alternative tool is named despite a dense sibling set (v1GetEventByID, get_main_lines, v1GetMoneylines). 'Use returned canonical IDs' hints at a workflow but does not tell the agent when this tool is the right call versus a sibling.

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

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

Annotations already declare readOnly/idempotent/openWorld/non-destructive, so the safety profile is covered. The description adds real context beyond that: metered/account-bound access, no background polling or automatic retry, one bounded request, and that empty results do not imply zero coverage. The 'no wagers, account changes' line largely restates readOnlyHint.

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?

Purpose is front-loaded, but the sentence is missing punctuation between 'date' and 'Read-only', and the remainder is a dense run-on of clauses of mixed relevance. It is not padded so much as poorly 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?

For a read-only query tool with full annotations and an output schema (so return values need no explanation), the description covers the important operational caveats: metering, no retry, exclusion, and empty-result semantics. The remaining gap is sibling differentiation (v1 vs v2 closing) and parameter-level guidance.

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 description itself contributes nothing about parameters. The reported 0% schema coverage is misleading here: the schema actually documents sportID (with enumerated common values), offset (UTC minutes), affiliate_ids (sportsbook IDs plus the sentinel behavior), and event_status inline. With that in-schema richness, baseline 3 is appropriate, but the description earns no credit.

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

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

The first sentence states a specific verb and resource ('Get closing lines for a sport and date'), so the agent knows what the tool returns. However, it is verbatim identical to the title and does not distinguish it from near-identical siblings such as v2GetClosingBySportAndDate or v1GetOpenersBySportAndDate, so the agent cannot tell which closing-lines variant to pick.

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 ('Use returned canonical IDs', 'never infer coverage from an empty result') and states an exclusion (Affiliate 27), which is genuinely useful. But it never says when to choose this v1 closing tool over the v2 sibling, an opener tool, or a moneyline tool, so the selection 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 already cover readOnly/idempotent/openWorld/non-destructive, and the description adds real value beyond them: metered usage tied to the connected account, one bounded request with no polling or retry, affiliate 27 exclusion, and the warning not to infer coverage from an empty result.

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 key purpose is front-loaded, but the body is a dense run-on mixing operational boilerplate ('Read-only Product data or price calculation') with policy notes. It is functional but not tight.

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

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

An output schema exists so return values need no explanation, and the description covers access model, exclusions, and empty-result interpretation. The main gap is the missing v1/v2 differentiation for a single-parameter lookup tool.

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

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

Schema description coverage is reported at 0% at the top level and the description never mentions sportID or its accepted values. The nested schema does carry a common-value mapping, but the description contributes no parameter meaning of its own.

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 conferences for a sport'), which is clear on its own. However, it does not distinguish itself from the sibling v2GetConferencesBySport, so an agent cannot tell which version to pick from the description alone.

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 when-to-use guidance and no mention of the v1 vs v2 alternative despite v2GetConferencesBySport being a sibling. 'Use returned canonical IDs' is downstream consumption advice, not a selection 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?

Annotations already establish readOnly, idempotent, openWorld and non-destructive behavior, and the description usefully layers on non-obvious traits: an empty result does not imply missing coverage, affiliate 27 is excluded, and no background polling or automatic retry should be attempted. These are genuine additions beyond the structured hints, though the opening 'Product data or price calculation' phrasing is vague.

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 content is a run-on, comma-spliced block that mixes purpose, data provenance, ID guidance, transport policy, an affiliate exclusion, and legal disclaimers without structure. Only the first clause is front-loaded; the rest is boilerplate that is hard to scan.

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

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

An output schema exists, so return values need not be explained, and the safety profile is covered by annotations. What is missing is the disambiguation an agent needs in a family of ~80 tools with four near-duplicate date-lookup endpoints, plus any hint of what 'canonical IDs' feed into.

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 description adds no meaning for any parameter: the sportID, the iso8601/epoch format choice, and the UTC offset in minutes are all documented only in the schema. With reported schema description coverage at 0% (nested path/query objects), the description should have compensated for that gap and does not.

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 opening clause 'Get available dates for a sport' states a specific verb and resource, so the core purpose is clear. However, it does nothing to distinguish this tool from near-identical siblings such as v2GetDatesBySportID, v2GetDatesBySportIDs, v1GetScheduleBySport, and v1GetEventsBySportAndDate, leaving the agent to guess which variant to call.

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 explicit statement of when to use this tool versus the many sibling date/schedule endpoints. 'Use returned canonical IDs' and 'never infer coverage from an empty result' are useful operational hints but not selection guidance, and the one-bounded-request/no-retry note is about transport behavior rather than tool choice.

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

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

Annotations already declare readOnlyHint=true, destructiveHint=false and idempotentHint=true, so the safety profile is covered. The description adds useful non-obvious context: 'never infer coverage from an empty result', 'One bounded request, no background polling or automatic retry', and that affiliate 27 is excluded. These go beyond the annotations but are scattered and partly redundant with the schema's affiliate_ids note.

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 text is a run-on stream of unrelated clauses with the redundant title restated up front. It is neither front-loaded with purpose nor organized; sentences like 'No wagers, account changes or guarantee of returns' are boilerplate that don't help an agent invoke the 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 nested-object, 0%-coverage parameterized tool with output schema present, the description leaves the delta cursor semantics and include/sport_id filtering unexplained. It mentions bounded requests and metered usage but omits the operational facts (response shape is covered by output schema) an agent needs to call it correctly versus V2 siblings.

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 0%, so the description carries the full burden for the nested query object (last_id, include, sport_id, affiliate_ids), yet it explains none of them. The one concrete constraint it does add, affiliate 27 exclusion, is already present in the schema's affiliate_ids description, so it adds no net 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?

The description opens by repeating the title verbatim ('Get event deltas (V1 format)') rather than stating a specific purpose. It never explains what a 'delta' returns or how this tool differs from the many sibling delta tools (v1GetDeltaV2, v2GetDelta, v2GetMarketsDelta). An agent cannot distinguish it from its siblings from the text alone.

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 explicit when-to-use or when-not-to-use guidance, and no alternatives are named. The phrase 'Access, delay and metered usage follow your connected account' gestures at metering but gives no routing condition between this V1 tool and V2 variants.

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 read-only, idempotent, open-world, non-destructive. The description adds genuinely useful operational traits beyond them: access/delay/metered usage tied to the connected account, a single bounded request with no polling or retry, and no wagers/account changes. It doesn't state rate limits or pagination, so a 4 rather than 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 purpose and dense rather than bloated, but the sentences are fragmented and run-on ('Read-only Product data or price calculation'), mixing unrelated caveats. Some clauses (no wagers/guarantee of returns) feel like boilerplate that dilute the core delta semantics.

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

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

An output schema exists, so return values needn't be explained, and the description does cover several constraints. But for a delta/cursor tool the semantic core (what last_id means, what a delta represents) is missing, leaving the definition adequate but with a real gap an agent would need.

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 0%, so the description must carry the parameter burden, and it largely doesn't. The required query.last_id — the core cursor parameter for a delta endpoint — is never explained, and sport_id is untouched. Only the affiliate exclusion note tangentially relates to affiliate_ids, which already has its own inline documentation.

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

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

The opening phrase 'Get event deltas (V2 format via V1 path)' essentially restates the name and title, though the 'V2 format via V1 path' clause does hint at a compatibility shim. It names the resource (event deltas) but never says what a 'delta' actually is here (changed events since last_id?), and with v1GetDelta, v2GetDelta, and v2GetMarketsDelta as siblings, the agent cannot confidently distinguish them.

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

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

There is partial guidance ('Use returned canonical IDs', 'never infer coverage from an empty result'), but no when-to-use or when-not-to-use versus the sibling delta tools. 'Affiliate 27 is excluded' is a scope note, not usage direction. The agent is left to infer the alternative.

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

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

Annotations already declare readOnly, idempotent, non-destructive and open-world, but the description adds real behavioral context beyond them: access/delay/metered usage follow the connected account, a single bounded request with no background polling or automatic retry, and an explicit empty-result caveat. These are genuinely useful traits an agent could not infer from the annotations.

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

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

Purpose is front-loaded, but the remainder reads as concatenated boilerplate clauses ('No wagers, account changes or guarantee of returns') that carry little selection value for this specific tool. It is not bloated, but several clauses do not earn their place.

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

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

An output schema exists, so return values need not be explained, and the coverage/metering caveats are helpful. Still, for a single required parameter with no schema description at the top level, the description leaves parameter usage entirely to the schema.

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

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

Schema description coverage is reported at 0% for the top-level structure, and the description adds nothing about the sportID parameter or its path nesting. Only 'Use returned canonical IDs' touches the data model, and that concerns outputs rather than the input 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?

States a specific verb and resource (get divisions for a sport), which is clear enough to act on. However, it does not distinguish itself from the sibling v2GetDivisionsBySport, so an agent cannot tell which version to pick from the description alone.

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?

Contains scattered operational guidance ('Use returned canonical IDs', 'never infer coverage from an empty result') but no explicit when-to-use statement and no routing against the many sibling list/get tools, notably v2GetDivisionsBySport. The affiliate-27 exclusion is a constraint, not usage guidance.

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

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

Annotations already declare readOnlyHint=true, idempotentHint=true, openWorldHint=true, and destructiveHint=false, covering the safety profile. The description adds useful behavioral context: 'One bounded request, no background polling or automatic retry', 'Access, delay and metered usage follow your connected account', and 'Affiliate 27 is excluded'. It also warns against inferring coverage from an empty result. This goes beyond annotations, but some claims like 'Product data or price calculation' are vague. Score 4 because it adds real value but could be clearer.

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 sentence with multiple clauses, which is somewhat dense but front-loaded with the core purpose. It includes several disjointed facts (product data/price calc, canonical IDs, access/delay/metered usage, bounded request, affiliate exclusion, no wagers/account changes/guarantee). While not bloated, it lacks clear structure and reads like a list of caveats rather than a coherent guide.

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

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

Given the tool has an output schema, the description needn't explain return values. Annotations cover safety, and the description adds behavioral constraints and exclusion notes. However, it omits important context for a read operation: what 'lines' are, the format of the response, and how to interpret the data. It leaves gaps for an agent trying to understand the tool's full scope, especially with 2 parameters and nested objects.

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 0%, so the description must compensate. It does not describe the 'path' or 'query' parameters beyond implying the use of event IDs. The schema itself defines 'eventId' with pattern and length constraints, and 'include' and 'affiliate_ids' are described in the schema (though coverage metric says 0%, the schema does include descriptions). The description adds no parameter-specific meaning, so baseline 3 is appropriate when schema provides some documentation, but not enough to compensate for the 0% coverage metric.

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 a specific verb and resource: 'Get a single event with lines'. This is distinct from sibling list tools like list_events and v2GetEventByID. However, it doesn't explicitly differentiate itself from v2GetEventByID, a very similar sibling; the 'v1' vs 'v2' distinction is not explained.

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 some context such as 'Product data or price calculation' and 'Use returned canonical IDs', but it does not explicitly state when to use this tool versus alternatives like v2GetEventByID or v1GetEventsBySportAndDate. The usage guidance is implied rather than explicit.

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, idempotentHint and destructiveHint=false, so the safety profile is covered. The description goes beyond that by disclosing operational traits: one bounded request, no background polling or auto-retry, metered/delayed access tied to the account, affiliate 27 exclusion, and the warning that empty results don't imply lack of coverage. These are useful 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?

The core purpose is front-loaded, but the text is a run-on block that mixes purpose, product/price wording, operational limits and legal disclaimers with no separation. Several phrases ('Product data or price calculation', 'No wagers, account changes or guarantee of returns') are boilerplate that dilute the actionable 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?

An output schema exists, so return values need not be explained, and annotations cover the read-only/idempotent profile. Still missing are sibling differentiation and any parameter-level guidance for a two-object nested schema, leaving gaps an agent must resolve elsewhere.

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 reported at 0% at the parameter level, so the description is expected to carry meaning — yet it never mentions sportID, date, offset (timezone boundary), or the include/status filters. The only parameter-adjacent statement is the exclusion of affiliate 27. It fails to compensate for the coverage gap.

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 — get events with lines for a sport and date — which matches the title and is a clear improvement over a bare name. It does not, however, distinguish this tool from close siblings like v2GetEventsBySportAndDate, v2GetEventsByDate or v1GetScheduleBySport, leaving the agent to infer which variant to pick.

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 implied usage guidance: use the returned canonical IDs downstream, treat results as bounded, and don't infer market coverage from an empty result. But there is no explicit when-to-use-this-vs-alternative statement against the many sibling event-list tools, and the phrase 'Read-only Product data or price calculation' reads as boilerplate rather than actionable instruction.

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 substantial behavioral context beyond the annotations: account-dependent access/delay/metered usage, no polling or automatic retry, empty-result coverage caveat, affiliate 27 exclusion, and no wagering or account changes. These details are consistent with the read-only, idempotent, non-destructive annotations.

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

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

The description is front-loaded with the core action and is reasonably dense, but it has a run-on opening without punctuation and includes some broad disclaimer language. Most sentences still earn their place by adding operational constraints.

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 and the annotations cover the safety profile, so return values and read-only behavior need not be explained. However, the nested required path.id and optional query.include remain undocumented in both schema and description, leaving a meaningful gap.

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

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

Schema description coverage is 0%, and the description does not explain the required path.id event identifier or the optional query.include parameter. It mentions 'canonical IDs' generally, but this does not compensate for the missing parameter-level 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 starts with a specific verb and resource: 'Get moneylines for an event.' This clearly distinguishes it from sibling market-type tools such as v1GetSpreads, v1GetTotals, and v1GetTeamTotals without needing to name them.

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

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

The description implies usage through 'Get moneylines for an event' and gives some operational guidance such as 'Use returned canonical IDs,' but it does not explicitly compare this tool to alternatives or state when not to use it.

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

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

Annotations already declare readOnly, idempotent, non-destructive, open-world behavior, so the bar is lower, yet the description adds real operational context: metered usage/delay tied to the account, a single bounded request with no polling or retry, affiliate 27 exclusion, and no wagers or account changes. These are traits an agent cannot get from the annotations.

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

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

The text reads as concatenated fragments ('...for a sport and date Read-only Product data or price calculation.') with no front-loading or logical grouping, and the compliance boilerplate occupies more space than the tool-specific 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?

An output schema exists, so return values need no explanation, and the description covers safety, coverage caveats, and the affiliate exclusion. However, it omits the primary selection question — why choose v1 openers over the v2 openers or the closing-lines sibling — leaving an agent to guess on routing.

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 schema itself documents sportID (with a full sport lookup table), offset, event_status, and affiliate_ids, so the heavy lifting is done structurally; the description contributes only the affiliate-27 exclusion. It adds nothing about date boundary handling or include/division/conference filtering, so it neither compensates for nor meaningfully extends 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 clause states a specific verb and resource ('Get opening lines for a sport and date'), which cleanly separates it from siblings like v1GetClosingBySportAndDate (closing lines) and the v2 variant. It does not explicitly call out the v1-vs-v2 distinction, so an agent must infer that from the name, but the core purpose 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 implies usage context ('Use returned canonical IDs', 'never infer coverage from an empty result') but never says when to prefer this over v1GetClosingBySportAndDate or v2GetOpenersBySportAndDate. Guidance is present but implied rather than explicit 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 readOnly, idempotent, non-destructive, open-world, so the safety profile is covered. The description goes further with genuinely useful operational context: one bounded request, no background polling or automatic retry, metered/account-scoped access, affiliate 27 excluded, and the warning that an empty result does not imply missing coverage. That is real value beyond the annotations.

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

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

The content is packed into an unstructured run-on string with no sentence separation, and the trailing clause 'No wagers, account changes or guarantee of returns' is generic boilerplate. The most valuable constraint (bounded request, no retry) is buried mid-string rather than front-loaded after the purpose.

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 the description adequately covers the safety/operational envelope. What is missing is any guidance on the query filters that actually shape a schedule request (date window, team/division/conference narrowing, pagination behavior), leaving a nested-schema tool under-explained.

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 description never mentions sportID, date ranges, pagination cursors, or any of the nine query filters. With schema description coverage reported at 0% and a nested two-object schema (path + query), the description should have compensated for the undocumented filters (from, team_id, division_id, season_year, limit) and it does not.

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 opening clause 'Get event schedule for a sport' gives a clear verb and resource, which is enough to separate it from data-point siblings like v1GetMoneylines or v1GetTeamsBySport. However it does not differentiate itself from the very close sibling v1GetEventsBySportAndDate, so an agent still has to guess which one to pick.

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 returned canonical IDs' and 'never infer coverage from an empty result' are downstream usage hints rather than when-to-use guidance. There is no statement of when this tool is preferred over v1GetEventsBySportAndDate or the other schedule-adjacent siblings, so selection remains 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 declare readOnlyHint, idempotentHint, openWorldHint and destructiveHint=false, so the safety profile is covered. The description adds genuinely new disclosure beyond that: account-dependent access, delay and metered usage, a no-retry/no-polling constraint, and an explicit affiliate exclusion (27). What it omits is any statement about result shape or scoping by sport, but the output schema covers returns.

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 is front-loaded correctly, but the body is a run-on string of concatenated clauses with no sentence structure. Several clauses ("No wagers, account changes or guarantee of returns") read as generic boilerplate applicable to every tool in this server rather than earning their place here, diluting the tool-specific 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?

For a zero-parameter read tool with an output schema, the description covers the remaining agent-relevant dimensions: read-only nature, connectivity/rate-limit behavior, retry expectations, and an affiliate exclusion. The gap is sibling disambiguation (v1 vs v2 season-type endpoints) and any hint of what a "season type" denotes, which would help the agent confirm the right endpoint.

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

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

The tool takes zero parameters, so the baseline of 4 applies; there is no argument whose semantics could be clarified. The line "Use returned canonical IDs" is output-chaining advice rather than parameter documentation, and it is not accompanied by a parameter it applies to.

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 opening clause gives a specific verb and resource ("List season types per sport"), matching the title and telling the agent exactly what is enumerated. It does not, however, distinguish itself from close siblings such as v2GetSeasonTypes or v1GetDivisionsBySport/v1GetConferencesBySport, so an agent cannot tell from the description alone which of these to pick.

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 operational usage context (one bounded request, no background polling or automatic retry, do not infer coverage from an empty result) which steers invocation behavior. It never addresses when to use this tool versus a sibling like v2GetSeasonTypes, nor any prerequisite for acquiring a sport identifier, so selection 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 already declare this read-only, idempotent and non-destructive, so the safety profile is covered. The description goes well beyond that by disclosing metered/billing behavior tied to the account, access and delay variability, a no-retry/no-polling constraint, the exclusion of affiliate 27, and the important caveat that an empty result does not mean no coverage.

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

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

It is compact overall, but the opening is a run-on with no punctuation ('List all sports Read-only Product data or price calculation'), jamming the purpose and a policy phrase together. Later clauses are dense and mix billing, retry policy, affiliate exclusion and result-interpretation without clear ordering.

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

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

With an output schema present and zero parameters, the description need not explain return values and doesn't. It covers the operational caveats an agent needs (metered usage, no retry, empty results not implying absence), though it omits any note on result size or how the canonical sport IDs relate to the sibling sport-scoped 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?

This is a zero-parameter tool, so the baseline is 4 and there is nothing for the description to clarify about arguments. It correctly adds no spurious parameter detail.

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 all sports'), so the operation itself is unambiguous. However, it offers no differentiation from the closely related siblings 'list_sports' and 'v2GetSports', leaving the agent to guess which version to call.

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 never says when to use this tool versus 'list_sports' or 'v2GetSports'. 'Use returned canonical IDs' is downstream advice for chaining calls, not selection guidance, and 'never infer coverage from an empty result' is a caveat rather than a when-to-use rule.

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

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

Annotations already declare readOnly/openWorld/idempotent/destructive, and the description adds real context beyond them: metered/access behavior tied to the connected account, a bounded single request with no polling or auto-retry, exclusion of affiliate 27, and an explicit empty-result caveat. This is substantive behavioral disclosure.

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

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

Reasonably short but delivered as one run-on with a garbled opening clause ('Read-only Product data or price calculation') that does not earn its place. The actionable constraints are present but not cleanly front-loaded or separated.

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

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

An output schema exists so return values needn't be described, and annotations cover the safety profile; the description fills in the remaining behavioral caveats well. Its one meaningful gap is sibling routing (v1 vs v2GetSportsbooks), which the description never addresses.

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 0% and the single parameter (query.include, enum 'regions') is entirely undocumented in both schema and description. The description must compensate at low coverage but says nothing about the filter, so an agent cannot learn the only usable argument from the text.

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 all sportsbooks'), so the agent knows what it returns. However, it never distinguishes itself from the sibling v2GetSportsbooks, and the '(alias)' tag plus the fragment 'Read-only Product data or price calculation' muddies rather than sharpens the 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 downstream usage tips ('Use returned canonical IDs', 'never infer coverage from an empty result') that imply how to consume results, but offers no when-to-use guidance or comparison against the many alternatives, notably v1 vs v2GetSportsbooks.

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

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

Beyond the readOnly/idempotent annotations, the description discloses substantive traits: access, delay and metered usage follow the connected account, an empty result must not be read as no coverage, requests are single bounded calls with no polling or retry, affiliate 27 is excluded, and no wagers or guarantees apply. That is real added context.

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?

Purpose and read-only nature are front-loaded, and the remaining caveats are terse and clause-like with little filler. Slightly run-on, 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?

An output schema exists, so return values need not be described, and the safety behavior is well covered. The gap is request construction: with two undocumented, nested parameters and no field guidance, an agent lacks enough to reliably form the call.

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 0% and neither parameter is explained. The only clue is 'Use returned canonical IDs', which loosely justifies the required path.id string but says nothing about format/bounds or the query.include=all_periods option, leaving the schema to carry an undocumented request shape.

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 opening 'Get spreads for an event' gives a specific verb and resource, and 'spreads' implicitly distinguishes it from siblings like v1GetMoneylines and v1GetTotals. It does not, however, explicitly name those alternatives to disambiguate the market-type choice.

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 call this versus the many related line tools (moneylines, totals, team totals, best line). 'Use returned canonical IDs' hints at chaining but is a data-hygiene note, not usage guidance.

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

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

Annotations already declare read-only, idempotent, open-world and non-destructive behavior, yet the description adds real operational context beyond them: metered/account-dependent access and delay, one bounded request with no background polling or automatic retry, and an exclusion for affiliate 27. These are genuinely useful traits not derivable from 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?

The leading sentence is fused into the next clause without punctuation ('Get teams for a sport Read-only Product data...'), making the front-loaded purpose hard to parse. Several trailing statements ('No wagers, account changes or guarantee of returns') read as boilerplate that dilute the core 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?

With an output schema present, return values need no explanation, and the description supplies the behavioral envelope an agent needs (metering, bounded single request, affiliate exclusion, empty-result caveat). The only meaningful gap is the lack of v1-vs-v2 disambiguation.

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

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

The only parameter (sportID) already carries a rich schema description enumerating common sport IDs, so the schema does the heavy lifting. The description adds nothing specific about the sportID format or accepted values, matching the 3 baseline for a well-documented single 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?

States a specific verb and resource ('Get teams for a sport'), which is clearly distinct from siblings like v1GetConferencesBySport or v1GetDivisionsBySport. It does not, however, distinguish itself from the near-identical v2GetTeamsBySport, so an agent must infer the version difference.

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?

Implies context with 'Product data or price calculation' and tells the caller to 'Use returned canonical IDs' downstream, but gives no explicit when-to-use/when-not guidance and never routes between v1 and v2 alternatives. Caveats like 'never infer coverage from an empty result' are warnings, not usage selection criteria.

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

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

Annotations already declare readOnly, idempotent, non-destructive, and open-world behavior, so the safety profile is covered. The description adds genuine operational context beyond that: one bounded request with no polling or auto-retry, metered/delayed access tied to the connected account, affiliate 27 excluded, and the warning that an empty result does not imply no coverage.

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

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

The purpose is front-loaded, but the remainder reads as a run-on string of clauses joined by semicolons, mixing useful constraints with low-value disclaimers ('No wagers, account changes or guarantee of returns') and the unclear 'Product data or price calculation' fragment.

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 cover the safety profile. For a one-required-parameter tool this is close to adequate, but the complete absence of parameter documentation and sibling differentiation leaves the agent short of what it needs to invoke 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?

Schema description coverage is 0% for two parameters (path.id and query.include), so the description must carry the burden. It only hints that IDs are canonical ('Use returned canonical IDs') and says nothing about the id format, the event ID requirement, or the meaning of the 'include' query option, leaving the parameters largely undocumented.

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 team totals for an event), which is clear enough to act on. However, it offers no differentiation from close siblings such as v1GetTotals, v2GetTeamStats, or v1GetEventByID, so the agent must guess how this tool's scope differs from those.

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 explicit when-to-use guidance and no alternatives named. The clause 'Read-only Product data or price calculation' gestures at a context but is too garbled to tell the agent which sibling to pick or when to prefer this over v1GetTotals.

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 (which already cover readOnly/idempotent/openWorld): it discloses that affiliate 27 is excluded, that coverage follows the connected account and should not be inferred from empty results, and that it is one bounded request with no polling or automatic retry. This is meaningful operational context an agent would otherwise have to guess.

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 is front-loaded, but the remainder is a run-on string of clauses with no punctuation separating them, making it harder to parse than it needs to be. Several caveats are valuable; the packaging is not.

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 the annotations plus description cover safety and access semantics. The one real gap is the undocumented nested parameters, which is the only thing keeping this from being fully 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?

Schema description coverage is 0% and both parameters are nested (path.id with a pattern/length constraint, query.include with an enum). The description adds only 'use returned canonical IDs', which gestures at the ID format but does not explain the id pattern or the meaning of include=all_periods.

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 totals (over/under) for an event'), which separates it from v1GetMoneylines and v1GetSpreads. It only partially distinguishes itself from the sibling v1GetTeamTotals, since neither the title nor description clarifies event-level vs team-level totals.

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 (retrieve over/under totals for a given event ID) and it notes that returned canonical IDs should be reused, but it never names an alternative tool or states when this is preferred over v1GetTeamTotals. No explicit when-not guidance beyond the affiliate-27 exclusion.

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 readOnly/idempotent/openWorld, and the description adds real operational context beyond them: no authentication required, affiliate 27 excluded, one bounded request with no background polling or automatic retry, and metered/access behavior tied to the connected account. The 'never infer coverage from an empty result' caveat is a genuinely useful behavioral note, though the phrase 'Read-only Product data or price calculation' is confusing filler.

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?

Purpose is front-loaded, which is good, but the body is a run-on string mixing return fields, availability caveats, rate/metering notes, an exclusion, and generic disclaimers ('No wagers, account changes or guarantee of returns'). Several clauses are boilerplate that dilute the signal.

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

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

An output schema exists, so return values need no explanation, and the description still names the key returned fields plus the no-auth and exclusion facts. The one real gap is the undocumented query.include parameter, but overall an agent has enough 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 0% and the single nested parameter (query.include with the 'regions' enum) is never mentioned in the description, so it provides no compensating meaning. An agent must rely entirely on the schema to discover that region data can be requested.

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 ('List all sportsbooks/affiliates') and enumerates what comes back (IDs, names, URLs, integration status). However, it never distinguishes itself from the very similar siblings list_affiliates, v1GetAffiliates, and v2GetSportsbooks, so an agent cannot tell which one to pick from the description alone.

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?

Offers fragments of usage context ('Use returned canonical IDs', 'Availability can vary by sport and market') but never says when this tool should be chosen over list_affiliates, v1GetAffiliates, or v2GetSportsbooks, nor states any preconditions. No when-not guidance at all.

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

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

Annotations cover the safety profile (readOnly/idempotent/non-destructive/openWorld), and the description adds real context on top: metered, delayed usage tied to the connected account, a single bounded request with no polling or auto-retry, affiliate 27 excluded, and the warning not to infer coverage from an empty result. That is materially more than the structured fields provide.

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 definition crams many clauses into a near run-on with missing punctuation ('...market definitions Returns all...'), mixing purpose, caveats, and disclaimers. It is front-loaded with the purpose, which helps, but several sentences (e.g. the wager/returns disclaimer) add limited value.

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

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

Because an output schema exists the description needn't explain return values, and annotations carry the safety profile, so the remaining needs are scope and operational caveats — which the description supplies (metering, retry, affiliate exclusion, empty-result caution). It is close to complete, with sibling differentiation the only notable gap.

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

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

The tool takes zero parameters, so there is no syntax to document and the baseline is 4. The listed output fields are redundant with the existing output schema rather than adding new parameter meaning.

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

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

States a specific verb and resource ('List all market definitions') and enumerates the returned fields (IDs, names, period info, participant flag). It does not, however, differentiate itself from overlapping siblings such as list_markets, v2GetMarketsByDate or v2GetAvailableMarketsByEvent, so an agent cannot tell from the text alone when this unfiltered variant is the right pick.

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 returned canonical IDs' and 'Read-only Product data or price calculation' imply a usage context, and the empty-result caveat is useful. But there is no explicit when-to-use/when-not guidance and no named alternative, so routing versus the many list_/v2GetMarkets* siblings is left to inference.

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

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

Annotations already cover read-only, idempotent, non-destructive and open-world traits, but the description adds genuinely new context: a single bounded request with no background polling or automatic retry, account-dependent access/delay/metered usage, affiliate 27 exclusion, and the warning not to infer coverage from an empty result. That empty-result caveat is especially valuable for an agent interpreting output.

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

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

The text reads as concatenated fragments from multiple fields — 'List all stat definitions Read-only Product data or price calculation.' lacks punctuation and cohesion, and the trailing 'No wagers, account changes or guarantee of returns' is a boilerplate disclaimer. Purpose is front-loaded, but structure is poor.

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

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

An output schema exists, so return values need not be described, and annotations cover the safety profile. The operational caveats add real value, but the missing filter semantics and absent sibling routing leave gaps for a list tool sitting among ~80 related endpoints.

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 a query object with id and sport_id filters, but the description says nothing about filtering by stat ID or sport ID. With reported schema description coverage at 0% (top-level), the description was expected to compensate and does not, leaving parameter meaning entirely to 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 lead sentence 'List all stat definitions' gives a specific verb and resource, and the title reinforces it. It is implicitly distinguishable from data-oriented siblings like v2GetStatsByEvent or v2GetTeamStats, since this returns definitions rather than stat values, though it never explicitly draws that contrast.

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 phrase 'Use returned canonical IDs' implies this is a discovery step feeding downstream stat queries, which is useful. However, there is no explicit statement of when to call this versus the many v2GetStats* siblings, nor any exclusion guidance.

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