PropLine — Sports Betting Odds & Prop Resolution

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

Discloses the key is never returned in the tool response but emailed, describes side effects (email send, re-send at most once/day), and notes free-tier limits. This goes well beyond the sparse annotations and gives the agent accurate expectations.

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 carries operational value—action, triggers, constraints, delivery, limits, idempotency behavior—with no filler. The key action is front-loaded.

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

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

For a single-parameter tool with no output schema, the description covers input requirements, output behavior, side effects, limits, and duplicate handling. Nothing essential is missing for correct invocation.

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

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

Even with 100% schema coverage, the description adds critical provenance constraints on the email parameter: it must be given explicitly in this conversation, never guessed/reused, and must belong to the user. This materially changes how the agent selects the value.

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

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

States a specific verb ('create'), resource ('free personal PropLine API key'), and delivery mechanism ('EMAIL it'). Clearly distinguishes from sibling read/export/price tools, none of which create keys.

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 trigger conditions (shared-demo rate limit, redacted paid field, user asks how to get a key) and explicit exclusions (never guess, reuse, or sign up third party). No alternative tool exists among siblings, so the when-to-use 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=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?

Annotations declare readOnlyHint=true and destructiveHint=false, so the tool is known to be safe. The description adds substantial behavioral detail beyond that: the anchor order (pinnacle→polymarket→kalshi→bovada→smarkets), fair_source per line, exclusion of PrizePicks, outcome sorting, and the influence of devig method on results. This is exactly the kind of context agents need and is not duplicated by 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 long but every sentence carries essential information: the core functionality, edge cases (PrizePicks, anchor selection), and filter semantics. It is front-loaded with the primary purpose and then adds necessary caveats. No filler or redundancy, making it efficient despite its length.

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 no output schema, the description covers all required operational details: anchor selection logic, devig options with use cases, filtering behavior, and the existence of fair_source. An agent has enough guidance to invoke it correctly, including the warning about per-line anchors. The absence of an output schema is mitigated by the description's clarity on return semantics.

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

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

Schema coverage is 50%, with markets parameter lacking any description. The description compensates for devig (explaining when to use shin vs multiplicative) and bookmakers (clarifying it narrows prices but not the anchor). It does not explain markets or min_ev_pct beyond schema, but the two most nuanced parameters are well-documented. This is better than baseline 3 but not perfect.

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

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

The description clearly states it returns cross-book +EV per outcome for an event, with a precise methodology (anchor on a sharp book, remove vig, derive fair line, compute EV%). It distinguishes itself from siblings like get_best_line and get_odds by focusing on EV calculation across books, and the mention of 'Pro-tier endpoint' reinforces its specific role.

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 concrete usage conditions: use 'shin' devig for longshot props, explains the bookmakers filter behavior, and warns about the per-line anchor selection (never assume Pinnacle). It does not explicitly contrast with alternative tools like get_best_line, but the context makes its niche clear. The lack of explicit 'when not to use' guidance prevents 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?

While annotations already declare readOnlyHint=true and idempotentHint=true, the description adds substantial behavioral detail beyond that: the steam[] array's exact definition, the null prob_shift and 'line_moved' direction when a book moves the line itself, exclusion of those outcomes from steam, the inclusion of outcome_id for /odds and webhooks, and the free-tier redaction behavior. This is rich, non-obvious behavioral disclosure that materially helps an agent 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 long but every sentence carries dense, useful information: the core output, the steam semantics, the line_moved edge case, and the outcome_id linkage. It is front-loaded with the main purpose before diving into details. It earns its length, though it could be slightly tightened without losing meaning.

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 that there is no output schema, the description does a strong job explaining what the response contains: opening line, latest line, prob shift, direction, steam rows, outcome_id, team, and open/latest point. It also flags the free-tier limitation. Combined with the 71% schema coverage on inputs, an agent has enough to call the tool correctly. Minor gaps remain, such as explicit error behavior, but not enough to lower the score further.

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 71%, so the schema already documents most parameters. The description adds valuable output context (outcome_id semantics) but does not significantly elaborate on the parameters themselves beyond what the schema provides. With moderate coverage, 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, unambiguous statement: 'Line movement + steam detection from the snapshot tick history,' naming the exact resource and operation. It further enumerates what is returned per (book, market, outcome), distinguishing this from generic odds endpoints. This clearly differentiates the tool from its siblings, especially the various odds and history 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 clearly implies when to use this tool: whenever an agent needs opening/latest lines, implied-probability shifts, and steam detection. The closing line, 'No pull-only odds API can produce this,' contrasts it with pull-only odds tools, giving context for exclusion. It does not name a specific sibling as an alternative, but the usage context is 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?

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 declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the safety profile is covered. The description adds valuable behavioral context beyond annotations: it is a free-tier endpoint, the value is synthetic, it includes OT/SO goals, and it is the median of per-game primary totals across NHL books. This gives the agent a clear picture of what the number represents and its 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 compact and front-loaded: it opens with the free-tier and synthetic nature, then defines the resource, then gives concrete use cases. Every sentence earns its place, and the use-case list is a model of efficient guidance.

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

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

For a single-parameter read-only tool with no output schema, the description is nearly complete. It explains what the value means, how it is computed, and when to use it. The only minor gap is that it doesn't describe the exact response shape (e.g., whether it returns a number, an object with per-book lines, etc.), but with no output schema and a simple parameter, this is a small omission.

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

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

Schema description coverage is 100%, so the schema already documents the single 'date' parameter as YYYY-MM-DD UTC with a default of today. The description adds the important nuance that the date is interpreted as US Eastern time ('for a given US Eastern date'), which is genuinely useful beyond the schema. However, it doesn't elaborate on edge cases like timezone conversion behavior, so a 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 states a specific verb ('Returns'), a precise resource ('synthetic daily NHL goals total'), and a clear scope ('for a given US Eastern date'). It also distinguishes itself from the MLB Grand Salami sibling by explicitly naming the hockey equivalent, so an agent can tell it apart from propline_get_mlb_grand_salami without opening schemas.

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

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

The description gives explicit use cases ('what's the total goal line for tonight's full NHL slate', 'did the Daily Goals Total go over yesterday', 'historical NHL daily-goals results for backtesting') and notes that no retail sportsbook quotes this as a single market, which clarifies when this synthetic metric is relevant. It also implicitly distinguishes from sibling tools like propline_get_odds and propline_get_scores by focusing on the aggregate daily total rather than individual games.

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 the read-only/idempotent annotations, disclosing subtle response behaviors: suspended_at semantics, pregame_only books, Underdog payout_multiplier traps, team-total vs game-total collisions, and side/is_outright fields. These are exactly the implicit behaviors an agent needs to avoid reasoning errors.

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 primary usage and then organized into dense, non-redundant caveats. The book list and return-field warnings are long, but each one prevents a real misinterpretation (Underdog, suspended markets, pregame_only, team totals, side). No filler sentences.

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 carries the full burden of explaining the response shape. It covers bookmakers[], payout_multiplier, suspended_at, pregame_only, team, side, is_outright, and tennis tournament/tour — enough for an agent to correctly interpret and act on a complex odds response.

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 88%, so the baseline is 3. The description's event_id and markets guidance largely restates the schema; its rich caveats concern response semantics rather than parameter semantics. It does not add substantial new meaning to period, include_depth, or bookmakers beyond their schema 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 opens with a specific verb-object 'Get live odds' and immediately states the two modes: event_id returns full per-event props, otherwise bulk game-line odds for the sport. This clearly separates the tool from siblings like get_odds_closing or get_odds_history.

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 operational guidance: 'If event_id is supplied... otherwise...' and explains how to request markets. However, it does not explicitly name sibling tools or state when not to use them, so it stops short of a 5.

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

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

Annotations declare readOnlyHint, idempotentHint, and non-destructive, which the description does not contradict. It adds valuable behavioral details: that opening is the first snapshot regardless of how far before kickoff, that closing is the last snapshot at or before commence_time, that the archive starts 2026-04, and that the free tier returns a redacted structure with an upgrade pointer. These disclosures go 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 detailed but efficiently front-loads the core purpose and key distinctions before diving into nuances. It is longer than typical but each sentence adds critical value, including a caveat about points vs prices and free-tier behavior. No redundancy, though it could be trimmed slightly without losing meaning.

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 two required parameters and optional filters, the description covers everything an agent needs to select it correctly: it explains the return data (opening/closing, prices/points), the lookback behavior, the archive start caveat, the point comparison guidance, and the free-tier redaction. No output schema is needed given the detailed explanation.

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

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

Schema coverage is 50%, but the description explicitly defines the semantics of key parameters like opening_window (with example value 14 and 'all'), and explains how period and bookmakers are used. It does not detail markets, but the overall context clarifies the primary parameters. This compensates well for the partial schema coverage.

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

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

The description clearly states it returns opening and closing lines per (book, market, outcome) for an event, with explicit definitions of both data points. It distinguishes itself from related tools by framing it as a canonical CLV-tracking helper and contrasts with fetching full history, making it unique among siblings like propline_get_odds_history and propline_export_odds_history.

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 when-to-use guidance: for CLV tracking, comparing points as well as prices, and understanding opening_age and archive start limitations. It does not explicitly name alternative tools or state when not to use it, but the context strongly implies it is preferred over history-fetching for CLV measurements.

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?

Beyond the annotations (readOnly, openWorld, idempotent, non-destructive), the description discloses statelessness, the deliberate return of two CLV numbers with their interpretation, de-vig anchoring to the sharpest book, fail-closed matching with unmatched_reason, exclusion of pending bets from averages, a 500-bet max, and free-tier nulling. These are rich behavioral details that materially help an agent interpret and trust results. 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 lengthy but every sentence adds value. It front-loads the core purpose and then systematically covers the two CLV metrics, de-vig behavior, pending-bet handling, matching semantics, limits, and tier behavior. The structure is logical and the detail is justified given the tool's complexity and lack of an output schema. It is not overly redundant, though it could be slightly tightened.

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 only two parameters and no output schema, the description is thorough. It explains what each output field means, including the subtle distinction between clv_pct and ev_vs_close_pct, how de-vigging works, the fail-closed matching behavior, pending-bet exclusion, and free-tier nulling. An agent has everything needed to call the tool correctly and interpret results reliably. Edge cases and limits are covered.

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 provides 100% coverage of both parameters with detailed descriptions, including the devig enum and the bets array structure. The description adds little new meaning about the input parameters themselves—it mostly explains output semantics and edge cases. It does mention the devig vocabulary links to propline_get_event_ev, which is useful, but this is a marginal addition. A 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 clearly states the tool grades placed bets against closing lines, a specific verb and resource. It enumerates the returned data (closing price, de-vigged fair probability, CLV, graded resolution, portfolio summary) and distinguishes it from sibling get_* tools by focusing on evaluation rather than fetching odds. The purpose is unambiguous and actionable.

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 context on when to use the tool (when grading placed bets to evaluate edge) and even gives interpretation guidance, such as reporting ev_vs_close_pct when the user asks about value and not presenting pending bets as results. It does not explicitly name alternative tools or say 'use X instead of Y', but the unique grading function makes this unnecessary. The 'Hobby+ endpoint' mention also hints at access constraints, though it is not fully explained.

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 declare readOnlyHint/idempotentHint/destructiveHint, and the description adds rich behavior beyond them: fail-closed matching (422 leg_unmatched, no guessing on ambiguous totals), quoted=false semantics with the book's own failure_code, free-tier behavior (matched legs with nulled prices), and the correlation_factor interpretation (below 1 = charging, above 1 = paying). No contradiction with the annotations 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?

Every sentence earns its place and the purpose is front-loaded, but the entire description is one dense run-on paragraph with no bullets or breaks. For a tool this complex the length is justified, yet the wall-of-text structure forces an agent to parse a very long block to find leg-field rules and error semantics.

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

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

With no output schema present, the description carries the full burden of return-value explanation and meets it: sgp_price, independent_price, correlation_factor, the {quotes, errors, best_bookmaker} shape for 'all', quoted=false, and the 422 leg_unmatched error. Leg construction, bookmaker routing, and edge cases are all covered, making the tool fully callable from the description alone.

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 75% schema coverage, the description goes well beyond the schema. It explains bookmaker values in detail (fanduel default, draftkings's SGP widget, betonlineag/lowvig shared Sportcast engine) and gives exhaustive leg-field semantics: what 'name' carries per bet type, when 'point' and 'period' are omitted, how 'team' selects a TEAM total vs game total, and the book_outcome_id alternative. This fully compensates for any 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 names a specific verb-resource pair (price a same-game parlay) and immediately differentiates it from a modeled price by stressing the BOOK'S OWN correlated odds. It also names the sibling it builds on (propline_get_odds for leg naming) and its 'all' mode that returns best_bookmaker, making the tool's identity distinct from the 27 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?

Provides explicit when-to-use guidance: 'use all whenever the user asks which book to bet an SGP at,' and clear operational instructions for failures ('fix the leg, do not retry blindly'). It references propline_get_odds for leg naming conventions, though it stops short of explicitly stating when NOT to use this tool in favor of a specific sibling for single-leg pricing.

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.