PropLine — Sports Betting Odds & Prop Resolution

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

Annotations already declare readOnlyHint=true and idempotentHint=true, but the description adds critical behavioral context: CSV output format, per-row granularity, row cap of 200, the need for a bounded window due to huge archive size, and the alternative endpoint for full dataset access. This transparently discloses limitations and error handling beyond the structured metadata.

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

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

The description is dense yet efficient, with each sentence contributing essential information: access restrictions, format, scope, alternative, requirements, cap, endpoint workaround, and error behavior. It is front-loaded with the core purpose and avoids repetition.

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

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

For a complex export tool with no output schema and 5 parameters, the description covers all necessary context: what it returns (CSV rows), who can use it, why to use it, its limitations, and what happens on failure. It is fully self-contained for an agent to decide and invoke 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?

The schema already has 100% parameter description coverage, so the baseline is 3. The description adds extra value by explaining that since/until keep the pull bounded, advising 'Keep the window narrow', and clarifying that sport_key governs the whole-sport scope. This enriches parameter understanding beyond the schema.

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

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

The description specifies a clear verb and resource: 'Bulk line-movement tick history as CSV' with detailed scope ('every recorded odds snapshot ... across a whole sport'). It distinctly separates this from sibling tools like propline_get_odds_history, making its unique purpose 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?

It explicitly states when to use this tool ('Backfill-pass / Enterprise only') and names the alternative for other tiers ('Pro/Streaming use propline_get_odds_history per event instead'). It also provides prerequisites (since/until window) and error behavior (403 for non-entitled keys), fully guiding selection.

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

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

Annotations already declare readOnlyHint=true, openWorldHint=true, idempotentHint=true, destructiveHint=false. Beyond this, the description adds rich behavioral context: tier-dependent behavior ('Hobby+ for prices; free tier gets the full structure... but prices nulled and redacted:true'), return-structure details (all_prices array sorted best-first, one row per book with last_update), and book-coverage quirks (DFS exclusions, Underdog two-way limitation). No contradiction with 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?

Five information-dense sentences with zero filler — every sentence carries distinct value (tiering, return contract, sibling differentiation, exclusions, filter intent). Slightly front-loaded with a parenthetical-heavy first sentence ('Hobby+ for prices; free tier gets the full structure...'), which takes effort to parse, but nothing is wasted.

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

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

For a complex tool with tiered access, no output schema, and 22 siblings, the description covers the critical gaps: it documents the return contract (best-first all_prices, per-row last_update, redacted pricing flag) where no output schema exists, explains conditional availability (DFS exclusions, Underdog limitation), and positions this tool among its get_* siblings. This is complete enough for an agent to know exactly what to expect.

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 60% (markets, bookmakers, include_links documented; sport_key and event_id bare). The description reinforces the bookmakers parameter's intent ('to shop only the books the user holds accounts at'), which mostly restates the schema's own 'to shop only those books.' It adds tier context that affects observable output behavior but no new per-parameter syntax or format guidance beyond the schema, so it neither compensates for the gap nor adds much incremental 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?

Clear verb+resource+scope: 'returns the single best American price across all comparable books' for each (market, player, line) tuple. Explicitly distinguishes from siblings by naming propline_get_event_ev as a companion and contrasting: '/ev says whether a price beats the no-vig fair line; best-line says which book pays the most.' Also details exclusions (DFS pick'em books) that separate it from generic odds tools.

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

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

Provides explicit when-to-use and when-not-to-use guidance: it names the alternative (propline_get_event_ev) and articulates the decision rule for choosing between them. Also covers behavioral exclusions ('DFS pick'em books... are excluded; Underdog only at clean two-way lines') and usage intent for the filter ('to shop only the books the user holds accounts at').

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 annotations (readOnly, idempotent, etc.), the description discloses important limitations: it is 'reference math' only, does not include demon/goblin modifiers, and assumes independent legs. These caveats add behavioral context that the annotations do not capture, and there is no contradiction with the 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?

Every sentence earns its place: the opening phrase sets expectations, the return content is listed, the optional parameter is explained, examples are included, and the caveats are clearly marked with 'NOTE.' The structure is front-loaded with the core function and progressively adds detail without redundancy.

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

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

Given the tool has one optional parameter, no output schema, and several sibling tools, the description is quite complete. It explains the return values (payout schedule, breakeven, expected_return, is_plus_ev) and important assumptions. It could be slightly more precise about the exact structure of the returned payout schedule, but overall it covers the essential context.

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 already documents leg_win_prob with 100% coverage. The description adds a concrete example value ('0.58') and clarifies that is_plus_ev represents the slip-level breakeven, which is not obvious from the schema alone. This adds meaningful semantic value beyond the schema.

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

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

The description clearly states the tool returns PrizePicks Power Play and Flex Play payout schedules for 2-6 legs plus per-leg breakeven probabilities. It uses specific verbs like 'Returns' and 'Pass' and mentions unique resources (Power Play, Flex Play) that distinguish it from sibling tools focused on odds, events, or scores.

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 'Useful for' section provides concrete example queries, giving clear context on when to use this tool. It does not explicitly mention exclusions or alternative tools, but among the siblings there are no other payout-specific tools, so the guidance is sufficient.

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. The description adds valuable behavior: indoor venues return weather=null, the free tier, and a 404 when no context exists. These details go beyond what annotations provide, enriching transparency.

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 purpose, then organizes sport-specific details, and ends with free tier and error behavior. It is dense but not overly long; every sentence adds meaningful context, though it could be trimmed slightly.

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

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

It covers the contents for MLB and NFL/NCAAF, the indoor-venue weather edge case, the relationship to get_event_results, and the 404 error. The lack of a response structure is a minor gap, but given the small parameter set and no output schema, it is largely complete.

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

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

With schema_description_coverage at 0%, the description must compensate for parameter meaning. It never explains sport_key or event_id values or constraints, only implicitly referencing sports and 'event' in the 404 note. The schema provides only types and required flags, leaving the agent to infer usage.

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

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

The description clearly states the tool provides 'Game context for an event — the conditions a prop settles under' and details sport-specific content. It distinguishes from siblings like get_event_results by noting the same block is embedded there, establishing a unique standalone 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?

The description gives clear context by outlining MLB, NFL & NCAAF specifics and mentions that the same block is embedded in get_event_results, implying when to use this standalone tool. However, it doesn't explicitly state exclusions or say 'use this instead of X,' so it stops short of fully explicit guidance.

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

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

The description goes well beyond annotations by disclosing concrete behavioral details: the anchor selection order per line, fair_source semantics, PrizePicks exclusion, outcome sorting, and the fact that bookmaker filtering does not change the anchor. This is rich, non-obvious behavioral information that an agent needs to interpret results correctly.

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

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

The description is dense but every sentence earns its place: main purpose, methodology, sorting, exclusion, anchor-order caveat, and filter nuance. The most important caveat about fair_source is prominently included rather than buried.

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

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

For a complex EV endpoint with no output schema, the description provides substantial operational context: what fair_source means, how the anchor is chosen, and how filtering behaves. However, it does not describe the expected response structure or clarify the markets parameter, so it is not fully complete.

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

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

Schema description coverage is only 40%, so the description must compensate for the undocumented parameters. It adds valuable nuance to bookmakers, but it does not explain markets, sport_key, or event_id, and min_ev_pct is only covered by the schema. The description mentions 'event' generically but leaves real gaps for required and optional parameters.

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

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

The description opens with a specific verb and resource ('Returns cross-book +EV per outcome for an event') and explains the methodology clearly. This purpose is distinct from sibling tools like get_best_line or get_odds because it is explicitly focused on EV calculation and per-book comparisons.

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

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

The description gives clear context on when this tool is used: when cross-book EV per outcome is needed, with optional bookmaker filtering and min_ev_pct filtering. It does not explicitly name alternatives or state when NOT to use it, so it stops short of a 5, but the intended usage is apparent.

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, it discloses important edge-case behavior: when a book moves the line itself, prob_shift is null and direction is 'line_moved', and those outcomes are excluded from steam. It also explains the steam[] definition, the 27-book scope, and the free-tier redaction.

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 purpose and stays tight; each sentence adds a distinct fact: output fields, steam signal definition, null behavior, uniqueness, and access tier. There is no filler.

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

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

With no output schema, the description does a solid job of defining the meaningful output semantics and null/edge cases. It does not describe the outer response shape or pagination, and access specifics are only hinted by 'Hobby+ full; free tier redacted,' but the schema covers the main input filters.

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 contributes no input-parameter semantics; it focuses on output shape. Schema coverage is only 60%, and the two required parameters (sport_key, event_id) are left without schema descriptions, so the description does not compensate for that 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 artifact: line movement and steam detection from snapshot tick history, and enumerates exact per-(book, market, outcome) fields: opening line, latest line, signed implied-probability shift, point shift, direction. It also differentiates from ordinary odds retrieval with 'No pull-only odds API can produce this,' so an agent can distinguish it from get_odds and get_odds_history siblings.

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

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

The description clearly implies the use case: call this when you need line-movement and steam/wise-money signals rather than plain odds. It adds an exclusion context ('No pull-only odds API can produce this') and access-tier conditions, but it does not explicitly name sibling alternatives or spell out when-not-to-use versus each adjacent 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?

While annotations cover read-only/idempotent safety, the description adds essential behavioral context beyond them: the values are market-implied with no accuracy claim, not a forecast, player_id is null until graded, and tier differences in output. This fully discloses the behavior and limitations.

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

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

The description is dense but every sentence earns its place: definition, use case, interpretation warning, exclusions, and tier info. It's front-loaded with the core purpose, and the structure flows logically from what to how to 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?

Given the lack of an output schema, the description covers output semantics (no-vig cross, books_contributing, player_id null until graded), exclusions, and tier restrictions well. Minor gaps include not explaining what 'Hobby+' tiers mean or how event_id/sport_key should be formatted, but these are likely standard to the API.

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 only 33% (only 'markets' has a description), yet the description doesn't clarify 'sport_key' or 'event_id' beyond their names. It mentions the output is per (market, player) but provides no format or allowable values for the required parameters, failing to compensate for the schema gaps.

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

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

The description clearly states the tool returns market-implied consensus projections per (market, player) for an event, with a precise definition (no-vig P(over) crossing 50%, median across sportsbooks). This is specific and distinct from sibling tools like odds or EV, making its purpose 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?

Explicitly says to use it to validate statistical or fantasy projections against the live market, and warns how to present results ('the market implies X', not 'PropLine projects X'). It also notes the DFS exclusion, giving both positive and negative guidance without naming alternatives directly.

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 annotations (readOnly, idempotent, non-destructive), the description adds valuable behavioral details: tier-dependence, data redaction on free tier, the specific grading outcomes included, and the presence of actual stat values. It also mentions the upgrade pointer, giving a clear picture of response variations without requiring an output schema.

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

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

The description is concise at three sentences, front-loaded with the main action. However, the opening fragment 'Pro-tier endpoint.' is grammatically incomplete, and the second sentence about the-odds-api, while informative, is somewhat tangential to operational usage. Overall, it is efficient with no fluff.

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 simple schema (2 required params) and no output schema, the description covers key aspects: return content, tier limits, and redaction behavior. It does not address error conditions or parameter formats, but these are less critical for such a straightforward read tool. The description is sufficiently complete for an agent to understand the tool's role.

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 meaning or format of event_id and sport_key. It only implies event_id pertains to a 'completed event,' but this is insufficient to compensate for the lack of parameter descriptions. The agent must rely on external knowledge or schema types.

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

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

The description clearly states the tool's function: 'Returns graded prop outcomes for a completed event' with specific grading outcomes (won, lost, push, void) and actual stat values. It differentiates from siblings by highlighting the unique grading capability compared to the-odds-api, making it instantly clear what this tool specifically offers.

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 usage context by noting it is a 'Pro-tier endpoint' and describing free-tier limitations (redacted resolution/actual_value). However, it does not explicitly instruct when to choose this tool over sibling tools like propline_get_odds or propline_get_event_context, leaving the selection inference to the agent.

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 mark the tool as read-only, but the description adds substantial behavioral detail: stats refresh ~every 90 seconds during live games, in-progress numbers are partial, final status means official box score, and other sports populate at completion. This goes far beyond the annotation hints and gives the agent accurate expectations about data freshness and reliability.

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

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

The description is dense but every sentence contributes: purpose, content, live refresh, partial-data caveat, coverage across sports, and free tier. It is front-loaded with the core purpose and avoids fluff.

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?

Despite having no output schema, the description gives a clear picture of what to expect (per-player stats, live vs final, refresh cadence). For a simple two-parameter read-only tool, the description is sufficiently complete for an agent to invoke it correctly and interpret results appropriately.

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 0% and the description does not explain the 'sport_key' or 'event_id' parameters. It mentions sports by name (MLB, WNBA) but never maps them to the required parameters, leaving the agent to guess acceptable values. The description adds no direct 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?

The description clearly states the tool returns 'book-agnostic raw box-score stats for an event' with specific examples (strikeouts, hits, points). It distinguishes itself from sportsbook-line tools by emphasizing the stats are 'decoupled from any sportsbook's lines', making the purpose unambiguous.

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

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

The description provides explicit context on when to use the tool: 'use this to answer how is this prop tracking right now' and explains live behavior during games. It does not name alternative sibling tools or provide explicit when-not-to-use guidance, but the targeted use case is clear.

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?

Although annotations already mark this as read-only and idempotent, the description adds meaningful behavior: it is free-tier, aggregates across five books, emits one row per futures event/book/market, and notes that marquee markets have multi-book coverage while exotic ones are often single-book. It also states that futures are unresolved, which is valuable operational 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?

The description is dense but every sentence earns its place: tier, resource, market examples, row structure, book comparison behavior, and resolved/unresolved state. It is front-loaded with the core purpose and avoids filler.

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

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

With no output schema, the description compensates by explaining the row shape, outcome/price content, book aggregation, and settlement state. For a one-parameter read-only tool, this is sufficient for an agent to select and 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?

The single sport_key parameter already has 100% schema description coverage with examples. The description reinforces that the parameter selects a sport but adds no new parameter-level semantics beyond the schema, so the baseline of 3 is appropriate.

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

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

The description opens with a specific verb and resource: it returns season-long futures/outright markets for a sport. It enumerates exact market types and books, making the tool's purpose unmistakable and clearly distinct from sibling odds/results tools.

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

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

The 'Useful for:' section gives concrete query intents such as Super Bowl favorites and NFL MVP odds, making the intended use clear. It does not explicitly name alternatives or state when not to use this tool, but the market-type context strongly implies where it fits.

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 adds meaningful context by labeling the endpoint as free-tier, explaining the synthetic derivation from multiple books (Pinnacle, Polymarket, etc.), and clarifying that no retail sportsbook quotes this market—useful behavioral details 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 description is three sentences, front-loaded with the core function ('Returns the synthetic daily MLB Grand Salami'), and every clause earns its place—including the data-source detail and practical examples. It is simultaneously concise and information-dense.

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

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

For a simple read tool with one optional parameter and no output schema, the description fully explains what the output contains (total runs plus each book's implied line), the data sources, and the use cases. It also notes the synthetic nature and unique market status, making it complete for an agent to decide whether to invoke it.

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

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

The input schema already documents the single optional 'date' parameter with format and default, achieving 100% coverage. The description only repeats the notion of 'given UTC date' without adding syntax or additional parameter behavior, so it meets the baseline for high schema coverage without adding extra 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 clearly states the tool returns the synthetic daily MLB Grand Salami for a UTC date, with the exact meaning of the metric explained (total runs plus each book's implied line). It distinguishes itself from siblings by specifying the MLB Grand Salami niche and explicitly noting no retail sportsbook quotes it as a single market.

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

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

The description provides explicit example use cases ('what's the total run line for tonight's full MLB slate', 'did the Grand Salami go over yesterday', 'historical results for backtesting'), which clarify when to use the tool. However, it does not explicitly contrast with sibling tools like the NHL daily goals total, though the examples suffice for typical selection.

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 disclose readOnlyHint, idempotentHint, and destructiveHint. The description adds behavioral context: 'Free-tier endpoint', 'synthetic' nature, inclusion of OT/SO goals, and the calculation method (median of per-game totals). No contradictions with 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 four sentences, each contributing value: access tier, definition, calculation, and use cases. It is slightly more verbose than strictly necessary but well-structured and free of filler.

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

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

For a moderate-complexity tool with no output schema, the description explains both the returned metric (total goals plus each book's implied line) and its derivation, giving an agent a complete understanding of what to expect. It is sufficient for the tool's niche.

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 covers 100% of parameters with a clear description ('YYYY-MM-DD UTC date, defaults to today UTC'). The description reinforces the UTC date but adds no new parameter-specific detail beyond the schema, so it does not exceed the baseline.

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

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

The description uses a specific verb ('Returns') with a precisely defined resource ('synthetic daily NHL goals total') and states its scope ('total goals scored across every NHL game on the slate'). It distinguishes from siblings by referencing the MLB Grand Salami and noting that no retail sportsbook quotes this as a single market, making it uniquely identifiable.

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 provides clear 'Useful for:' examples (slate total, over/under, backtesting) that indicate when to use the tool. Although it does not explicitly mention alternatives or when-not-to-use, the context of a niche synthetic market is sufficient to guide an agent's selection.

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 declare read-only/idempotent/non-destructive, and the description adds rich behavioral context on top: response shape (bookmakers[] across up to 27 books with sport-varying coverage), plus four critical data semantics — payout_multiplier (including the trap that 'filtering on non-null would drop every Underdog line'), suspended_at as last-quoted legs/probable scratch, pregame_only as a frozen quote invisible to suspended_at, and the team/totals key-collision warning. No contradiction with 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?

Well front-loaded: core action and mode switch first, then response shape, then the data-interpretation warnings. However, it redundantly enumerates all 27 book names that the schema's bookmakers parameter already lists as keys, inflating the description by roughly 40 words. Every other sentence earns its place given the tool's complexity.

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

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

A 7-parameter tool with no output schema and 25 siblings, and the description covers the highest-risk interpretation areas exhaustively: identifying the true game total (team == null), treating suspended/pregame_only books as unbettable, and normalizing Underdog lines. Minor gaps remain — decimal price format, timestamps, and bulk-response ordering are unmentioned — but nothing that would cause a mis-invocation.

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

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

Schema description coverage is 86%, so the schema carries most parameter meaning and the baseline is 3. The description adds the fallback behavior for omitted event_id (bulk game lines for the whole sport) and reinforces the comma-separated markets format with examples, but the bulk of parameter detail (period codes, book keys, include_links/include_book_ids semantics) lives in the schema — the description exceeds it only modestly.

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 live odds') and immediately disambiguates the two operational modes: full per-event props when event_id is supplied vs bulk game-line odds otherwise. The 'live' qualifier distinguishes it from siblings like propline_get_odds_closing and propline_get_odds_history, and the mode switch is stated in the first sentence.

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?

Internal usage guidance is strong: the event_id-triggered mode selection is explicit, and the description gives practical data-handling rules (filter payout_multiplier == 1.0, exclude pregame_only books for live games, filter team == null for game totals). However, it never names sibling tools or states when to choose this over propline_get_odds_closing/history — tool-selection guidance exists only implicitly through the word 'live'.

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

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

Annotations already declare readOnlyHint=true and destructiveHint=false. The description adds detailed behavioral context: definitions of opening/closing snapshots, the 14-day pre-kickoff window, the archive start date (2026-04) and its implication for opening_age_seconds, and the warning to compare points as well as prices. It also mentions free tier redaction. This goes well 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 description is front-loaded with the core function and then provides definitions, use-case, and caveats. Each sentence adds value, but it is somewhat lengthy with multiple caveats. It is well-structured and readable, though not as tight as a two-sentence description.

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

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

With no output schema and 5 parameters, the description covers the key return fields (opening/closing prices, points, timestamps, opening_age_seconds) and important caveats (archive start, free tier redaction). It doesn't explain the response structure or undocumented parameters like markets and event_id, but the core semantics are sufficiently covered for an agent to invoke the tool 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?

The schema description coverage is 40%, with only period and bookmakers documented. The description refers to output fields like opening_price/opening_point/opening_at and opening_age_seconds, adding some meaning, but it doesn't explain the input parameters such as markets, event_id, or sport_key beyond saying 'for an event' and mentioning 'spreads and totals.' Thus it only partially compensates for the schema's gaps.

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 explicitly states 'Returns the OPENING and CLOSING line per (book, market, outcome) for an event,' providing a specific verb and resource. It distinguishes from siblings by calling itself the 'Canonical CLV-tracking helper' and noting it returns both data points 'instead of fetching full history and post-processing,' differentiating it from history endpoints.

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

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

The description gives clear context for when to use this tool: for CLV tracking, as it returns both opening and closing lines in one call. It contrasts with alternatives by saying 'instead of fetching full history and post-processing,' implying this is the simpler choice. It also notes the free tier limitation, but doesn't explicitly name alternative tools or provide exclusions for other cases like current odds.

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 non-destructive. The description adds value by disclosing free-tier redaction behavior and filter semantics (e.g., changes_only drops unchanged snapshots, interval downsampling). No contradiction with 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?

Three sentences pack a clear purpose, tier limitations, and filter list. Each clause adds meaningful detail without fluff. Slightly dense but appropriately sized for a complex 11-parameter endpoint.

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

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

For a tool with 11 parameters and no output schema, the description explains what is returned (historical snapshot series, market structure in free tier) and key filters. It lacks explicit return shape details but compensates with practical usage 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?

Schema coverage is 73%, so the description carries some weight. It explains relative_from/to offsets ('-3h' or '0'), interval downsampling ('latest snapshot per bucket wins'), and changes_only behavior. These details enrich the schema's terse descriptions.

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 action: 'Returns the historical line-movement snapshot series for an event' with details about price/point changes. It distinguishes from siblings by emphasizing the snapshot series and filters, differentiating from export/current odds tools.

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

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

Provides clear usage context: 'Hobby+ endpoint', free tier limitations with 'redacted snapshots' and an upgrade pointer, and lists applicable filters. It does not explicitly name alternatives but implies when to use via filter semantics and tier constraints. No explicit exclusions, but context is sufficient.

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 mark it read-only and idempotent, and the description adds substantial non-obvious behavior: it returns the raw box-score archive including games no sportsbook priced, carries no line/price/grade, applies limit after the opponent filter, and explains that team fields are null for individual sports. No contradiction with 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 dense but well-ordered: core purpose first, then semantic details, important caveats, and final null-field guidance. Every sentence contributes meaning and the tool is not padded with 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?

Even without an output schema, it explains what the response contains, what it does not contain (lines, prices, grades), how H2H scoping behaves, and how to handle unknown team/null values. This is complete enough for an agent to call the tool correctly and reason about the returned stats.

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?

Despite 80% schema coverage, the description adds real value beyond schema: opponent accepts full names, nicknames, or abbreviations; limit is applied after H2H filtering; and player_name must match box score formatting. This gives the agent practical guidance that the schema alone does not provide.

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

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

The description states a specific verb and resource: it returns a player's recent games with every raw box-score stat per game. It also distinguishes itself from propline_get_player_trends and clearly mentions the H2H use case, so an agent can tell it apart from very similar siblings.

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

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

Explicitly says when to use it ('how has X actually performed lately?', build L5/L10/L20/season splits/H2H yourself) and when not to: use propline_get_player_trends for hit rates against a posted line. It also calls out the important caveat that unpriced games are included and H2H is not limited to the current season.

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 provide readOnlyHint=true and idempotentHint=true, so the safety profile is known. The description adds valuable behavioral context about tier-differentiated data (full data vs redacted resolution/actual_value) and the upgrade pointer, going beyond the structured 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 three concise sentences: it front-loads the core purpose, then details the return fields, and finally explains tier behavior. Every sentence adds value with no redundancy or filler.

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

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

For a read-only tool with 4 parameters and no output schema, the description adequately explains the output fields, the scope ('recent games'), and the tier behavior. It could be improved with a concrete example or explicit default limit, but the schema already handles parameter constraints.

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 input schema covers 75% of parameters with descriptions (limit, markets, player_name), and the description does not add much parameter-specific meaning. 'Recent games' loosely hints at the limit parameter, but the description largely relies on the schema for parameter 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 description clearly states 'Player prop history across recent games' and 'Returns each prior prop this player took with line, prices, resolution, and actual value,' specifying both the resource and the exact output. This distinguishes it from siblings like propline_get_player_trends or propline_get_odds.

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

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

The description does not explicitly state when to use this tool over alternatives such as propline_get_player_trends or propline_get_event_results. It mentions tier-based limitations (Pro vs free) but lacks explicit 'use this when...' guidance or exclusions.

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

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

Annotations already indicate readOnlyHint, idempotentHint, and destructiveHint=false. The description adds significant behavioral detail beyond that: the return fields (over/under/push splits, streak, average actual stat, recent line), the trend windows (5/10/20/50), and how dfs_odds_type modifies computation. It doesn't mention empty-result behavior, which is a minor gap.

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

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

The description is three sentences, front-loaded with the core purpose, and includes concrete examples and usage notes. Every sentence contributes distinct value without redundancy or fluff.

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

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

No output schema exists, so the description appropriately enumerates the returned data and explains the trend computation logic. It covers market scoping and dfs_odds_type nuance. It doesn't discuss sport_key format or empty-result behavior, but for a read-only data query with strong annotations, it's sufficiently complete.

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

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

Schema coverage is 75% (3 of 4 params have descriptions). The description adds meaning to 'market' by explaining scoping and to 'dfs_odds_type' by describing the line-comparison behavior, which goes beyond the schema. However, the required 'sport_key' parameter lacks both schema description and description text, leaving a small but relevant 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 uses a specific verb+resource: 'Hit-rate trends / last-N-games over rate for a player,' clearly defining what the tool does. It distinguishes itself from sibling tools by highlighting it's 'unique to PropLine's prop-resolution data' and provides a concrete consumer-facing phrasing ('did X go over in N of his last M games?').

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

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

It gives clear context for when to use the tool: 'Omit market for all markets, or pass one to scope' and explains the conceptual surface. However, it doesn't explicitly name alternative tools or state negative usage conditions, so it lacks the explicit when-not-to-use guidance needed for 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 read-only, idempotent, and non-destructive. The description adds valuable context: it is a free-tier endpoint, returns only aggregated counts (not individual records), and explicitly states it is not a profitability claim. This goes beyond the structured 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 three focused sentences, front-loaded with 'Free-tier endpoint' and 'Returns'. Every sentence adds distinct information: what it returns, when to use it, and an important caveat. No filler.

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

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

The tool is simple, with one optional parameter and no output schema. The description explains the return content (total graded/settled, games, sports, per-sport and top-market breakdowns) and the use case. Annotations cover safety. Complete for the tool's complexity.

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 covers 100% of the single parameter (days) with a clear description including range and default. The description merely echoes 'last N days' without adding additional semantics, so the schema carries the burden. Baseline 3 is appropriate.

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

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

The description clearly states what the tool does: returns aggregated counts of graded player props over a look-back window. It explicitly distinguishes this from other tools by noting 'aggregated counts only' and positioning it as a coverage proof, not a profitability claim.

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 a clear 'Useful for' context ('how much graded prop data does PropLine have, what's the coverage') and explicitly says it is never a profitability claim. It does not list alternative tool names, but the context is sufficiently clear to guide an agent.

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. The description adds 'Free-tier endpoint', indicating access/rate-limit characteristics, and clarifies the returned statuses (scheduled, live, final). This is useful context beyond the annotation metadata.

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 two sentences long, front-loaded with the key point 'Returns recent and live game scores plus status', followed by a concrete use case. No wasted words or redundancy.

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

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

For a simple read-only tool with 2 parameters and no output schema, the description sufficiently covers purpose, usage, and constraints. It could be slightly more complete by explicitly stating the required sport_key parameter, but the schema already covers that. Overall adequate.

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 covers 50% of parameters (days_from has a description, sport_key does not). The description mentions 'for a sport' implying sport_key but does not explain its format or required nature. No additional detail is given for days_from beyond the schema. Given partial coverage, the description could have compensated but does not fully.

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

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

The description clearly states the tool returns recent and live game scores plus status (scheduled, live, final) for a sport, using a specific verb and resource. It distinguishes itself from siblings by focusing on scores and status rather than odds, events, or statistics.

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 a clear use case: 'is this game over yet, what was the final score'. It implies when to use this tool for score lookups, though it does not explicitly name alternative tools or exclusionary criteria. This is clear context without direct alternatives.

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 significant behavioral context beyond the annotations: it explains what the returned rows contain, how to interpret pending vs. failed status, the meaning of response_code null, and the 8-second timeout detail. It also explains pagination behavior. This is valuable context that the readOnlyHint/idempotentHint annotations do not cover.

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

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

The description is compact yet information-dense. It front-loads the core purpose, then provides essential interpretation and pagination guidance within two sentences. Every sentence adds value: no filler, no repetition of schema details. The structure is efficient and scannable.

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 description is thorough given the tool's complexity. It explains the row structure, status semantics, error conditions, and pagination. The annotations cover safety (read-only, idempotent) and the schema covers parameters, so the description adds the remaining behavioral context. No output schema is present, but the description sufficiently outlines the data returned.

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 already documents all three parameters with descriptions, and the description adds extra nuance: it explains the pagination cursor (before_id = smallest id from previous page) and mentions the default limit of 50. The description also adds interpretative semantics for the status field, which is not a parameter but enhances understanding. Since schema coverage is 100%, the baseline is 3, but the added pagination and default-value context earn a 4.

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

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

The description clearly states the tool's purpose: it retrieves recent delivery attempts for one webhook, listing them newest first. It specifies the resource (webhook deliveries), the action (get), and the scope (one webhook, newest first). It also differentiates itself from sibling tools by framing it as the debugging surface for webhook issues, which is distinct from the other propline_* tools.

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

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

The description provides clear usage guidance: it explains when to use this tool (to debug why a webhook isn't firing) and offers specific navigation instructions (using before_id for pagination, interpreting status entries). It also hints at alternatives by mentioning propline_list_webhooks as the source for the webhook_id, which helps distinguish this from listing tools.

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

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

The description goes far beyond the annotations (readOnly, openWorld, idempotent, non-destructive) to disclose behavioral nuances: it states statelessness, explains that two CLV numbers are returned deliberately and the distinction between them, details the de-vig anchoring to the sharpest book (noting the negative CLV if de-vigging own book), describes fail-closed matching with unmatched_reason, and clarifies that pending bets are excluded from averages. It even notes the free tier nulls numbers. This comprehensive transparency is exemplary and no contradictions with annotations exist.

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 fairly long, but every sentence contributes essential information. It opens with the core purpose, then logically explains outputs, nuances (CLV types, de-vig anchoring), edge cases (pending bets, fail-closed matching), and limitations (max 500, free tier). The structure is coherent and front-loaded, though it could be slightly tightened without losing meaning. Overall, it's dense but not verbose, and the organization aids readability.

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's complexity (no output schema, nuanced CLV concepts, matching behavior, and various constraints), the description is exceptionally complete. It covers inputs, outputs, interpretation, edge cases, limits, and even gives strategic advice (which CLV metric to report). This leaves virtually no question unanswered for an agent deciding when and how to use the tool. It is highly complete for a tool with such intricate behavior.

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?

Although the schema already covers 100% of the single parameter (bets) with descriptions for each property, the tool description adds significant semantic depth: it clarifies what the tool does with the bets, explains that 'selection' is the subject, and outlines the meaning of the output fields (e.g., clv_pct vs ev_vs_close_pct). It also explains the matching logic and the significance of fields like closing_is_final. This goes well beyond the schema, providing crucial context that helps the agent understand how to construct and interpret the input.

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

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

The description clearly states the tool's purpose: 'Grades PLACED bets against their closing lines.' It specifies the resource (bets), the action (grading), and the key concept (comparison to closing lines). It also distinguishes from sibling tools like propline_get_odds or propline_get_event_results by focusing on bet grading and CLV calculation. The detailed explanation of outputs (closing price, de-vigged probability, CLV) leaves no ambiguity.

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

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

While the description does not explicitly list alternative tools or 'when not to use,' it provides strong usage context: it explains that the tool grades placed bets and highlights specific scenarios (e.g., 'Bets whose event has not started... do not present those as results'). It also guides output interpretation: 'report that one when the user asks whether they got value.' This implicitly tells when to use the tool (when grading bets) and how to handle edge cases. A bit more explicit exclusion of alternatives would be ideal, but it's already clear enough.

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

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

Annotations already declare readOnlyHint=true and destructiveHint=false, so the description need not repeat that. It adds contextual detail about return content (market types) but does not disclose pagination, output format, or whether results are dynamic. This is moderate added value beyond 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?

Two sentences, front-loaded with the action and examples, plus a clear use-case clause. No redundancy or filler; 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 simple list tool, the description gives the purpose and when to use it, and annotations cover safety. However, the lack of parameter explanations and any output format description creates gaps that could confuse an agent, especially with two required fields lacking schema descriptions.

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 only hints at 'specific event' but never explicitly explains event_id or sport_key, their formats, or why sport_key is needed. This leaves the agent guessing about required parameter 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?

Description clearly states the tool lists market types for a specific event, with concrete examples (h2h, spreads, totals). The verb 'List' matches the title and it distinguishes itself from sibling tools like list_events and list_sports by focusing on per-event markets.

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

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

Provides explicit context: 'Useful when you don't know which prop markets a given event carries.' This clearly indicates when to use the tool, but it does not name alternatives or when-not-to-use scenarios, so it falls short of a full prescriptive set.

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, idempotentHint=true, and openWorldHint=true. The description adds value by specifying exactly what data is returned (event id, teams, commence_time) and how to use that output downstream. No contradiction with 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?

Two sentences, front-loaded with the action, followed by return fields and usage. Every clause earns its place; no fluff or redundancy.

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

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

For a simple list tool with no output schema, the description fully explains what is returned and how to proceed. Combined with strong annotations and full schema coverage, it leaves no significant gaps.

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

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

Input schema covers all parameters with descriptions (100% coverage). The description adds little beyond the schema, only implying sport_key via 'for a sport' and not mentioning the 'live' boolean. Baseline 3 is appropriate because schema does the heavy lifting.

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

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

Description uses specific verb 'list' with resource 'events' and clarifies scope 'for a sport'. It explicitly enumerates returned fields (id, home_team, away_team, commence_time) and distinguishes its role as an entry point for per-event tools, clearly separating it from siblings like list_event_markets or get_scores.

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

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

The description gives clear context: it is the initial step to obtain event IDs, and explicitly says to use the returned event_id for further drilling. It does not explicitly state when not to use it or name alternative tools, but the workflow guidance is strong enough to guide appropriate usage.

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

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

Annotations already declare readOnlyHint, openWorldHint, idempotentHint, and destructiveHint=false, so the safety profile is well-covered. The description adds context about the return structure (sport keys, titles, active status), which is valuable 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?

Two concise sentences with no filler. The first sentence states the action, the second explains the return format and provides actionable guidance. 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 zero-parameter discovery tool with no output schema, the description fully covers what the tool does, what it returns, and how to use it. No gaps remain.

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

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

The tool has zero parameters, so the baseline is 4. The description appropriately omits parameter details because there are none, and it instead explains the output, which is more useful in this context.

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

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

The description clearly states the tool lists all sports PropLine currently polls, with a specific verb and resource. It also differentiates itself from sibling tools by focusing on sport discovery rather than odds, events, or results.

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 instructs the agent to use this tool first to discover valid sport_key values for other tools. This provides clear when-to-use guidance and distinguishes it from alternative tools that consume sport keys.

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 valuable behavioral context beyond the annotations: signing secrets are always masked, the server deliberately lacks management tools, and the tier-based 403 behavior with an upgrade URL. Even though readOnlyHint is already set, the extra details about masking and tier restrictions enrich the agent's understanding, going beyond the minimal annotation 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 description is three sentences, front-loaded with the primary purpose, and every sentence adds critical information: scope, tier behavior, read-only nature, output fields, and usage pointer. No wasted words or redundancy, making it highly concise and well-structured.

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

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

Given the tool has no parameters, no output schema, but has robust annotations, the description is complete. It covers purpose, restrictions, behavior, output fields, and a specific use case, leaving no gaps for the agent. It fully equips the agent to invoke the tool appropriately.

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

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

With zero parameters, the baseline is 4 per the rubric. The description doesn't need to explain parameters, but it does describe the output fields (url, subscribed events, filters, active status), which is relevant. Since there are no parameters, no further semantic clarification is required.

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

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

The description clearly identifies the tool's purpose: 'List the API key's webhook subscriptions.' It specifies the resource and scope, and differentiates it from siblings by noting the tier restriction and the absence of management tools, making it easy to distinguish from the other tools.

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

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

Explicit usage guidance is provided: 'Use this first to find the webhook id for propline_get_webhook_deliveries.' It also covers when the tool works (Streaming Lite and up) and when it doesn't (403 response for lower tiers), plus points out that create/update/delete are handled via REST API/SDKs, leaving no ambiguity about when to use 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 mark this as read-only, open-world, idempotent, and non-destructive. The description adds meaningful behavioral detail beyond that: fail-closed matching, 422 leg_unmatched errors, quoted=false semantics, refusal failure codes, free-tier nulled prices, and how to interpret correlation_factor. No contradiction exists.

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

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

The description is long, but the tool is complex and every clause carries necessary information: pricing semantics, parameter conventions, error behavior, response fields, and free-tier caveats. The core purpose statement is front-loaded, and the rest reads as a dense but efficient specification.

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

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

With no output schema present, the description takes on the burden of explaining return semantics and does so thoroughly: sgp_price, independent_price, correlation_factor, quoted=false, and failure_code. It also covers edge cases like unmatched legs, Over without a point, and free-tier nulling, making the tool fully usable by an agent.

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

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

Schema coverage is 75%, but the description substantially enriches it. It explains bookmaker values, sport_key format, compact leg field semantics for name/description/point/period, omission rules, and the book_outcome_id alternative. This goes well beyond the schema's minimal property names.

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

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

The description opens with a specific verb and resource: 'Prices a same-game parlay at the BOOK'S OWN correlated odds', and immediately contrasts it with 'not a model of it'. This clearly states the tool's unique function and differentiates it from other odds-related siblings like propline_get_odds or propline_get_best_line.

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

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

The description gives clear usage context: 2-10 legs from ONE event, bookmaker choices, and leg-naming conventions from propline_get_odds. It does not explicitly state 'use this instead of X for single-leg pricing', but the SGP-specific wording and the detailed conditions make when-to-use evident.

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 the operation safe/read-only, so the bar is lower, but the description goes well beyond by explaining cursor semantics, monotonic sequence numbers, delivery-id pitfalls, oldest-first ordering, pagination via next_seq, retention failure modes, and the fact that sequence numbers are not guaranteed dense. This is rich behavioral disclosure with no contradiction.

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 long but dense and every sentence earns its place. The central purpose is front-loaded, then critical gotchas (cursor misuse, retention, truncation, non-dense sequences) follow in logical order. There is no filler or repeated schema 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?

Despite having no output schema, the description covers the essential runtime contract: has_more, next_seq, truncated, and latest_seq are all explained, including how to compute an honest lag. The tool's complexity (pagination, retention, ordering, cursor semantics) is fully addressed, and the alternative path for unrecoverable data is provided.

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

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

Schema coverage is 100%, so baseline is 3, but the description adds substantial parameter-level meaning: since_seq is explained as the highest processed sequence, default 0 behavior is clarified, and pagination via passing next_seq back is explicit. It also warns against using delivery id as a cursor, which is exactly the kind of semantic nuance the schema cannot convey.

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

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

States a specific verb ('Re-read'), resource ('a webhook subscription's events'), and ordering ('in order from a cursor'), with a concrete user question it answers. It also explicitly contrasts itself with propline_get_webhook_deliveries, making sibling differentiation immediate.

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 when-to-use context ('my endpoint was down, what did I miss?') and clearly names the alternative that should be used instead for debugging (propline_get_webhook_deliveries). It also instructs when to fall back to REST endpoints (on truncation), so an agent knows when not to rely on this tool.

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