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 cover read-only/idempotent safety, but the description adds substantial non-obvious behavior: tier gating (Hobby+ returns prices; free tier returns structure with prices nulled and redacted:true), which book types are excluded, and the conditional Underdog inclusion. These are exactly the quirks an agent must know before trusting a returned price.

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

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

Front-loaded with the core definition and then the tiering caveat, the /ev comparison, and the exclusion rules. Dense but each clause carries information; it runs long and could be tightened, but nothing is 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?

No output schema exists, so the description carries the return contract itself: best price, all_prices sorted best-first with one row per book and last_update, plus the link/app_link behavior. For a cross-book shopping tool with tier gating, this is complete enough to call and interpret correctly.

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

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

Schema coverage is 60%, and the description adds meaning only for bookmakers, explaining its purpose (shop only books the user holds accounts at) beyond the schema's terse 'shop only those books' plus the shape of each per-book row. markets, event_id, and sport_key get no prose elaboration, and include_links is left entirely to the schema.

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

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

States a specific verb+resource with precise scope: for every (market, player, line) tuple on an event, it returns the single best American price and an all_prices array sorted best-first. It explicitly separates itself from the odds tool and the /ev tool, so an agent can pick it without opening a sibling schema.

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

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

Gives an explicit routing rule: 'Companion to propline_get_event_ev: /ev says whether a price beats the no-vig fair line; best-line says which book pays the most.' It also states exclusions (DFS pick'em books, Underdog only at two-way lines) and a concrete use case for the bookmakers filter (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?

Annotations already cover the safety profile (readOnly, idempotent, non-destructive), so the bar is lower, yet the description still adds a lot: free-tier status (an access/cost constraint), the scoring methodology (de-vig + Brier vs. result and vs. other books), and the meaning of each emitted field including the skill_bp sign convention and the verdict enum values. It also sets an explicit expectation boundary by denying any betting-edge interpretation.

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

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

Front-loaded with the free-tier flag and purpose, then the methodology, then the field list and use cases. The metric enumeration is long but earns its place since there is no output schema; only minor tightening is possible.

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 takes on the return-value burden and does so thoroughly, enumerating per-book fields plus by_sport and by_market breakdowns. Both optional parameters are fully documented in the schema, so nothing needed to call this correctly is missing.

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

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

Schema description coverage is 100% – both parameters carry ranges, defaults and examples in the schema itself. The description adds no syntax, format or semantics for 'days' or 'sport', so the baseline 3 applies.

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

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

The description names a specific verb+resource ('How well each sportsbook prices player props') and immediately scopes it to a de-vigged Brier scoring report, which cleanly separates it from sibling tools like propline_get_best_line or propline_get_event_ev. An agent can tell what this returns without opening the schema.

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

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

It gives two concrete selecting questions ('which book prices props most accurately', 'which book has the lowest margin') and flags that this is a pricing report, never a profit claim or betting edge, which implicitly routes agents away from EV/edge tools. It does not name an explicit alternative sibling or state when NOT to use it, 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?

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 already declare a safe read-only, idempotent, open-world operation, and the description layers on substantial extra behavior: outcomes sorted with +EV floated up, PrizePicks excluded, per-line anchor selection order, and the crucial warning to read the anchor from fair_source per line rather than assuming Pinnacle. That is real behavioral context beyond structured fields.

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

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

It is front-loaded with the core purpose and then builds method detail efficiently. It is dense but mostly earns its length; the closing restatement of the bookmakers/filter behavior slightly overlaps the per-line anchor point, a minor 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 complex, 8-parameter analytics endpoint with no output schema, the description conveys return shape (per-outcome, sorted, fair_source, fair_books, last_update, devig_method echo) and the critical interpretation caveat about anchors. It stops short of enumerating the full output fields, which would be expected given the absence of an output schema.

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

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

Schema coverage is 63% and the schema already carries rich text for devig, max_age, fair_source, and bookmakers. The description still adds cross-parameter meaning, notably that filtering to DraftKings 'still measures DraftKings against Pinnacle' (anchor unaffected by bookmakers) and that fair_source must be reported per line. It does not clarify markets/event_id/sport_key semantics, keeping it from a 5.

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

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

The description gives a specific verb+resource: 'Returns cross-book +EV per outcome for an event,' and immediately frames the methodology (anchor on a sharp book, remove vig, derive no-vig fair line, compute EV% per book). It is clearly distinguishable from siblings like propline_get_best_line or propline_get_odds, and states its scope exclusions (PrizePicks dropped from EV math).

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?

Guidance is present but embedded in method notes rather than an explicit when-to-use statement: devig='shin' is recommended 'when the user asks about longshot props,' and the bookmakers filter is explained as narrowing to the user's books. It does not explicitly name alternatives (e.g. get_best_line) or state when not to use this tool, so it falls short of a 5.

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

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

Annotations already declare readOnly, idempotent, non-destructive, and openWorld, so the safety profile is covered. The description adds genuinely new context: it is a 'Free-tier endpoint' and it defines the temporal window (3 days back to 30 days ahead) and the shape of each returned object.

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

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

Front-loads the free-tier tag and resource, then the window, then the field list. The sentence is dense with an inline field enumeration, but every element (window, id systems, books) earns its place given there is no output schema.

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, and the description compensates well by naming the fields returned (PropLine id, commence_time, espn_event_id, mlb_game_pk, merged_from_event_ids, per-book ids/links). Pagination and response envelope details are absent, keeping it just under a 5.

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

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

Schema coverage is 100% and there is a single param, so the schema already carries the meaning. The description only adds that the crosswalk is scoped to 'one sport', which lightly reinforces sport_key but adds no format or enumeration detail. 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?

States a specific resource (id crosswalk) with explicit scope (one sport) and enumerates the returned fields, including the alternate id systems. It does not name or distinguish itself from the nearby sibling propline_list_events, so it falls short of a 5.

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

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

The 'Useful for' clause gives concrete when-to-use scenarios (joining PropLine events onto ESPN/MLB Stats API/a sportsbook feed, mapping DraftKings ids). It provides clear context but no explicit exclusions or named alternatives, so it is a 4 rather than 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 cover the safety profile (readOnly, idempotent, non-destructive), and the description adds substantial context beyond them: steam is computed across all 37 books, an outcome whose book moved the line itself yields prob_shift=null and direction='line_moved' and is excluded from steam, and results are tier-gated ('Hobby+ full; free tier redacted'). With no output schema, disclosing these return-shape and edge-case behaviors is genuinely load-bearing.

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

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

It is front-loaded correctly with what the tool does, but it is one dense paragraph that interleaves return fields, edge cases, tier gating, and a sales line ('No pull-only odds API can produce this') that does not earn its place. Informative but under-structured.

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

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

For a 7-parameter, no-output-schema tool the description does the heavy lifting on return shape, steam semantics, and tier access, which is what an agent needs. It leaves minor gaps around sibling selection and any rate/volume limits on the tick history.

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 since, period, markets, bookmakers, and include_book_ids; only event_id and sport_key lack descriptions but are self-evident. The description's field notes (outcome_id, steam rows carrying team/open_point/latest_point) describe outputs rather than adding parameter meaning, so the baseline 3 holds.

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 (line movement and steam detection) and pins the data source (snapshot tick history), which is enough to separate it from generic odds siblings. It never explicitly contrasts itself with the closest neighbors (get_odds_history, get_odds_closing), so an agent still has to infer the boundary.

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

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

There is no when-to-use guidance: no statement of when movement/steam is the right call versus get_odds_history or get_odds_closing, and no exclusions. The 'since' behavior is explained in the schema, not the description, so usage context is only implied by the marketing claim 'No pull-only odds API can produce this.'

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?

Annotations already declare read-only, open-world, and idempotent behavior, so the bar for added value is met. The description adds the pro-tier requirement, the free-tier redaction of resolution and actual_value, and the payload-size warning (`unfiltered MLB game can run several MB`). These are useful behavioral insights beyond the structured annotations, 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 three sentences, front-loaded with purpose ('Pro-tier endpoint. Returns graded prop outcomes...'), then adds tier and size context. Every sentence earns its place 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, idempotent tool with no output schema, the description covers the output structure, redaction behavior, and the large-payload caveat—enough for an agent to call it correctly. Minor gap: it does not specify what happens if the event is not yet completed, but the phrase 'completed event' implies that. Overall, it is nearly complete for the given 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?

Schema description coverage is 50% (markets and bookmakers have descriptions; sport_key and event_id are self-explanatory names). The description does not add parameter-level meaning—its mention of 'actual stat value' refers to output, not input. The payload-size hint is inside the bookmakers schema description, not the tool description, so the description itself adds little over 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 verb and resource: 'Returns graded prop outcomes for a completed event' with a specific output format (won/lost/push/void plus actual value). It distinguishes from a competitor API but not explicitly from sibling tools, relying on the name and context. It is specific and useful, but could be more explicit about how it differs from other propline_get_* tools like get_scores or get_event_stats.

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?

No guidance on when to use this tool versus sibling alternatives. The description mentions tier differences (pro vs free) but does not say 'use this when you need graded props' or point to any other tool for ungraded data. An agent is left to infer usage from the name and description without explicit routing 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 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?

Beyond the readOnly/idempotent annotations, it discloses 'newest first' ordering, that in-progress rounds are excluded, the 2024 coverage floor, that hole counts are null on DP World, LPGA and some LIV rounds, and that it is a free-tier endpoint. These are exactly the operational and data-quality caveats an agent needs.

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 scope and return contents are front-loaded, followed by caveats and examples; every sentence carries information. The middle sentence is a long clause stack, which slightly blunts scanability but is not padded.

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 step-in explains the returned fields (strokes, score to par, hole counts, averages), the coverage window, ordering, and null-handling per tour, so an agent can interpret results without anything essential missing.

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

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

Schema description coverage is 100%, so tour/limit/since/player are already documented in the schema. The description reinforces the tour values and the default-ish volume implied by 'last-5/10/20 averages', but adds no new syntax or format detail over the schema, so the baseline of 3 applies.

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

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

The description names a specific verb+resource ('completed rounds' for a golfer) and pins the scope: 'Every player in the field, back to 2024.' It distinguishes this tool from adjacent siblings like propline_get_golf_tournaments and propline_get_player_history by returning per-round scoring detail and rolling averages.

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 concrete usage examples ('Scheffler's last 10 rounds', 'how has Bryson scored on LIV lately') that map directly to the tour filter and limit behavior. It does not name an alternative tool or state when not to use this one, so it stops short of full routing guidance.

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

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

Annotations already cover the safe-read profile (readOnly, idempotent, non-destructive), so the bar is lower. The description adds real behavioral context beyond them: free-tier access, newest-first ordering, and returned counts. It does not mention pagination or how the default limit of 50 behaves.

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

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

Two tight sentences with no waste. The tier/access caveat and the core purpose are front-loaded ahead of the filter details, so the agent gets the essential framing immediately.

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 carries the return-value burden, and it does state the shape (player and round counts, newest first). For a zero-required-parameter read-only list tool this is nearly complete; only pagination/limit behavior is left entirely to the schema.

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

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

Schema description coverage is 100%, so baseline is 3. The description adds value by enumerating the concrete tour values (pga, dp_world, liv, lpga, korn_ferry, champions) that the schema leaves as a free-form string, and by confirming comma-separated multi-tour filtering 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?

States a specific resource and scope: golf tournaments 'we hold round data for,' returned newest first with player and round counts. This implicitly separates it from the sibling propline_get_golf_rounds (rounds vs. tournaments) without the agent needing to open either schema.

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

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

The 'Free-tier endpoint' note gives useful cost/access framing, and the filter dimensions (tour, season) imply when the tool is appropriate. However, it names no alternative and gives no when-not guidance, such as routing to propline_get_golf_rounds for per-round detail.

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?

Annotations already cover the safety profile (readOnly, idempotent, non-destructive), and the description adds exceptional operational context: suspended_at semantics for pulled markets, pregame_only frozen quotes that suspended_at cannot express, book coverage counts, line_type taxonomy, and team scoping on totals. This is behavior an agent cannot derive from the annotations or 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?

Front-loaded with purpose and mode selection, and nearly every sentence carries domain-critical caveats (team totals vs game totals, Underdog payout_multiplier, pregame_only). However it is a single dense block with no formatting, and the enumeration of 30+ book names is bulky relative to its decision value.

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

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

With 8 parameters, no output schema, and openWorld behavior, the description compensates by documenting the return shape in detail (bookmakers[] array, per-market line_type/suspended_at/team, per-outcome side/payout_multiplier, is_outright/tournament/tour). Nothing an agent needs to call and interpret this tool is missing.

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

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

Schema coverage is 88% (above the 80% baseline of 3), and the description still adds real meaning: markets passed as a comma-separated list with concrete examples ('h2h,spreads,totals', 'player_points,player_rebounds') and the event_id branching rule. It also explains include_book_ids pitfalls (shared Kalshi outcome id across legs) that the schema only partially captures.

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

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

States a specific verb+resource ('Get live odds') and immediately disambiguates the two operating modes: event_id supplied returns per-event props, otherwise bulk game-line odds for the sport. An agent can tell what this tool does and how its behavior forks without opening the schema.

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

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

Gives strong conditional guidance: filter to line_type == 'main' for primary lines, exclude pregame_only books when reasoning about a live game, keep payout_multiplier == 1.0 for DFS comparison, filter team == null for the game total. It does not name any sibling alternatives (e.g. get_best_line, get_odds_history, get_odds_closing), so routing between this and adjacent odds tools is left to inference.

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

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

Annotations already cover readOnly/idempotent/non-destructive, and the description adds substantial new context: tier gating ('Hobby+ endpoint', free tier returns redacted structure with upgrade pointer), the archive start date (2026-04) and what a small opening_age_seconds implies about polling lateness, and the lookback limitation semantics of opening_window.

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

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

Front-loaded with the tier and the core return definition, then builds out semantics; nearly every sentence adds a distinct fact (closing definition, opening definition, window, point caveat, archive caveat, tier behavior). It is dense but justified for a data-returning tool with no output schema.

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 return-shape burden and does so: it names opening_price/opening_point/opening_at, closing price/point/closing_at, and opening_age_seconds, and explains the archive caveat that governs interpretation. An agent has enough to call and interpret the result correctly.

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

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

Schema description coverage is ~50%: opening_window and period/bookmakers are documented, but markets, event_id, and sport_key have no schema descriptions and are not clarified in the description either. The description compensates for the opening/window semantics and adds the point-vs-price warning, but leaves the remaining undocumented parameters untouched, so it only partially fills the gap.

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

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

States a precise verb+resource: returns the OPENING and CLOSING line per (book, market, outcome) for an event, and explicitly defines what each means (last snapshot at/before commence_time vs first snapshot held). It distinguishes itself from the generic siblings like propline_get_odds and propline_get_odds_history by naming the CLV-tracking use case and both endpoints of the line in one call.

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

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

Clearly frames the when-to-use case (canonical CLV-tracking helper) and the alternative it replaces ('instead of fetching full history and post-processing'), plus warns to compare points as well as prices on spreads/totals. It does not name a specific sibling tool or state exclusions as crisply as an explicit 'use X instead of Y' would.

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

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

Annotations already cover safety (readOnly, idempotent, non-destructive), and the description adds substantive behavior: tier gating, redacted snapshots plus an upgrade pointer on the free tier, and the downsample 'latest snapshot per bucket wins' rule. It stops short of describing pagination or result volume limits.

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

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

Three dense sentences, front-loaded with tier gating and the core return, then filters. Every clause carries information, though the filter sentence packs five concepts and is heavy to parse.

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 an 11-parameter read tool with no output schema, the description covers the notable behaviors an agent needs: tier gating, redaction, filter semantics, and downsample rules. Remaining gaps are the response shape details and pagination/volume expectations.

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 73% schema coverage the schema already documents most parameters, yet the description adds value beyond it: it clarifies the relative offset syntax ('-3h' or '0'), the absolute-vs-relative pairing, the interval enum, and the exact semantics of changes_only ('drop unchanged adjacent snapshots'). That goes past restating 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?

States a specific verb and resource: 'Returns the historical line-movement snapshot series for an event', including the granularity (every recorded price/point change per outcome). It does not, however, differentiate itself from close siblings like propline_get_event_movement or propline_get_odds_closing, so an agent must infer the split.

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 'Hobby+ endpoint' note and the free-tier redaction behavior are useful prerequisites, and the filter options imply intended usage. But there is no explicit when-to-use/when-not guidance nor any pointer to an alternative sibling, which is what an 11-parameter, multi-purpose tool most needs.

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

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

Annotations already cover the safety profile (readOnly, idempotent, non-destructive), yet the description adds critical behavior beyond them: limit is applied AFTER the opponent filter, H2H is not capped to the current season, unpriced games are included (unlike trends), and fields are null for individual sports or unknown sides.

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?

Long but dense and front-loaded: purpose first, then the usage routing, then the H2H, raw-archive and null-field caveats. Every sentence carries distinct information with no filler.

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

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

With no output schema, the description compensates by describing what is returned (per-game raw box-score stats, player_id in the response, null-when-unknown fields) and the constraints on filtering. Nothing an agent needs to call it correctly is missing.

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

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

Schema coverage is already 80%, but the description adds semantics the schema lacks: opponent accepts full name/nickname/abbreviation, limit is post-filter, player_id is accepted in place of the name, and the null-field behavior of player_team/opponent/is_home is explained.

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

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

States a specific verb+resource ('a player's recent games with every raw box-score stat per game') and explicitly distinguishes itself from sibling tools like propline_get_player_trends and propline_get_player_history by contrasting raw box-score archive vs graded-prop 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?

Gives explicit when-to-use ('how has X actually performed lately?', building L5/L10/L20, splits, H2H) and when-not ('use propline_get_player_trends for hit rates against a posted line'). The opponent/limit interaction warning is a concrete usage rule, not vague guidance.

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

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

Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the description's safety burden is low. It adds meaningful behavior beyond annotations: field-level output details, main-line vs alt-ladder semantics, and free-tier redaction behavior with an upgrade pointer. There is 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 with no filler: purpose, return fields, and usage caveats are each covered in order. The conditional and tier notes are placed at the end without burying the main purpose.

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

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

There is no output schema, but the description compensates by listing the key returned fields and explaining tier-dependent redaction. Required parameters are covered by the schema, and the description gives enough top-level behavior for a read-only history tool. Minor details like ordering and exact date range are left unspecified, but 'recent games' plus the limit parameter provides adequate 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?

Schema description coverage is 83%, so the input schema already documents most parameters. The description adds useful context for main_line_only and clarifies the single-market nature of the call, but it does not substantially compensate for or explain parameters beyond what the schema already provides.

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

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

The description starts with a specific object and scope: 'Player prop history across recent games for one market.' It then enumerates the returned fields, so an agent knows exactly what data this tool produces and can distinguish it from sibling history/game tools even without seeing their 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 first sentence establishes the intended use: fetching prop history for one market for a player. It also provides actionable conditional guidance ('Pass main_line_only=true to drop alt rungs') and tier-based expectations. It stops short of explicitly naming alternatives or when-not-to-use, so it doesn't earn 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?

The description adds rich behavioral detail beyond the readOnly/idempotent annotations: it returns over/under/push splits across 5/10/20/50 games, includes streak and average actual stat, defaults to all markets, and explains the dfs_odds_type cross-book behavior. This gives an agent a strong model of what the call will do.

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, front-loaded with the core concept, and every sentence adds value. It avoids repeating schema boilerplate while still giving a complete picture of output scope and parameter behavior.

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

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

Given the tool's moderate complexity and the absence of an output schema, the description adequately lists what the response contains and how market and dfs_odds_type affect results. It does not describe exact response formatting or error cases, but an agent has enough to call it correctly.

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

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

The input schema already covers most parameters well, and the description reinforces market scoping with concrete examples ('player_points', 'batter_hits'). It also clarifies the all-markets default behavior, which adds meaning beyond the bare 'optional' schema wording. The sport_key parameter has no schema description, but its name and the player_name examples make it unambiguous.

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: computing hit-rate trends and last-N-games over rates for a player, with specific output fields. It is easy to distinguish from generic stats tools, though it does not explicitly name sibling alternatives like propline_get_player_history or propline_get_player_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?

The description provides clear usage context: 'This is the did X go over in N of his last M games? surface.' It also explains how to scope by market and the default all-markets behavior. However, it does not explicitly state when not to use this tool or point to a specific alternative.

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

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

Annotations already declare 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?

Annotations already declare readOnly/idempotent/non-destructive, and the description adds real context beyond them: tier gating with a 403 plus upgrade URL, that signing secrets are always masked, and that write operations are deliberately absent from this server. That is exactly the behavioral disclosure an agent cannot get from the annotations.

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

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

Front-loads the core action and the tier constraint, and every sentence carries information rather than filler. The trailing parenthetical enumerating filter fields (min_ev_pct / max_ev_pct / ev_fair_source) is dense with detail but slightly burdens an otherwise lean description.

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

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

With no output schema, the description compensates by naming the row fields (url, subscribed events, filters, active status) and by covering the access-tier and masking behavior. Nothing an agent needs to call this correctly or interpret the result is missing.

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

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

The tool takes zero parameters, so there is nothing for the description to disambiguate and the baseline is 4. It instead spends its words on the shape of each returned row, which is useful but belongs to output rather than 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?

States a specific verb and resource ('List the API key's webhook subscriptions') and immediately scopes it against siblings by pointing to propline_get_webhook_deliveries as the follow-up. An agent can tell this apart from the other 30+ propline tools without opening a schema.

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

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

Explicitly states when it works (Streaming Lite tier and up, others get 403 with an upgrade URL), when it will fail, and the exact ordering rule ('Use this first to find the webhook id for propline_get_webhook_deliveries'). It also rules out the alternatives for mutation by noting no create/update/delete tools exist.

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.

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

Annotations already declare readOnlyHint, idempotentHint, openWorldHint, and destructiveHint=false. The description adds useful behavioral context beyond these: the result contains stable IDs and all known book spellings, and the tool is on a free tier. It does not contradict 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 compact and front-loaded: it states the core behavior in the first sentence and provides the downstream usage in the second. Every sentence adds value, and there is no filler.

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

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

The description explains what the tool returns, why it is useful, and how to chain it with related tools. The main gap is that the required sport_key parameter is not explained, though its name and the 'mlb' example provide some implicit guidance.

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

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

The schema already describes search and limit well, so the description adds little parameter-specific meaning. The required sport_key parameter is undocumented in both the schema and the description, and the description does not compensate for this gap.

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

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

The description states a specific verb and resource: find a player by name fragment and obtain a stable player_id plus known_names. It also clarifies the output format with an example and distinguishes the tool from the downstream history/trends tools by explaining how its result should be reused.

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

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

The description gives clear when-to-use guidance by explaining that the resolved player_id should be passed to propline_get_player_history and propline_get_player_trends to avoid name-spelling ambiguity. It does not explicitly list exclusions or when-not-to-use cases, but the context is clear.

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