PrizePicks API

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 and the description's remaining burden is behavioral context. It does add real value by disclosing that free-plan prices lag 5 minutes and that as_of is unavailable on that plan, but it says nothing about the response shape or how pagination interacts with the view/limit caps.

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 core operation, and no filler. The plan caveat is compressed into a dense clause that is slightly telegraphic but still parses cleanly.

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 full schema coverage and no output schema, the definition covers purpose, scoping and the main operational caveat (plan delay). It is slightly thin on what the returned rows look like, but the schema carries the parameter burden well enough that an agent can call it correctly.

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

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

Schema description coverage is 100%, so every parameter is already documented, and the baseline of 3 applies. The description adds only light framing — that league scoping applies and that as_of behavior depends on plan — without explaining the interaction between view, limit and alt_lines beyond what the schema states.

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 concrete verb-and-resource pair: it places PrizePicks lines beside offered sportsbook prices for a league, and adds the purpose of spotting where the line differs from the market. This distinguishes it from siblings like get_odds or get_projections, though it never names those siblings explicitly.

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

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

"Use it to see where a line differs from the market" gives one intended use case, and the free-plan note warns about delayed prices. However, it gives no when-not guidance and never points at the closest alternatives (get_odds, get_line_history, get_imported_lines) for agents who only want raw prices or historical movement.

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

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

Annotations declare a non-read-only, non-idempotent, non-destructive call but say nothing specific, so the description carries real weight: it discloses the once-per-account gating condition, the zero-quota cost, and a PII exclusion ('Leave out personal data'). It does not say what happens on a repeat call (relevant given idempotentHint=false) or what the call returns, which keeps it short of a 5.

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

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

Five short sentences, no filler, and the most consequential fact — that nothing else works until this is called — is front-loaded. Every sentence carries a distinct instruction (gate, content, ask-don't-guess, cost, PII), so nothing could be cut without losing information.

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

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

For a five-parameter onboarding tool with full schema coverage and no output schema, the description covers the prerequisites, the content expected, the anti-hallucination instruction, and the cost. The only gap is sequencing against start_signup/finish_signup, which is modest given how explicit the rest is.

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 the baseline is 3; the description earns above baseline by adding a constraint the schema omits (exclude personal data) and by directing the agent to paraphrase in its own words rather than copy boilerplate. It also glosses the two core required inputs as 'what data' and 'what they want to do with it', which helps map intent to fields, though found_us, agent and details are 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?

The description states a concrete purpose: a one-time per-account onboarding step that records what data the user wants and why. 'Required once per account before the data tools work' makes the gating role explicit. It loses a point because it never distinguishes itself from the sibling signup tools start_signup and finish_signup, nor does it explain how the fields it collects relate to those flows.

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?

Strong when-to-use guidance: it must be called once per account before other data tools, it costs no quota, and the agent is told to ask the user rather than fabricate answers. What is missing is any exclusivity or ordering guidance relative to start_signup and finish_signup, which an agent could easily confuse with this tool.

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

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

Annotations already declare readOnly, idempotent, non-destructive and openWorld=false, so the safety profile is fully covered. The description adds a genuinely useful auth fact ('Needs no key') and a return-content sketch, but the closing sentence 'Quote the read time when you state a line' is cryptic and does not clearly disclose a behavior.

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

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

Two short sentences, front-loaded with the resource and content types. The final sentence is compact but ambiguous in meaning, so it earns less than full marks despite the brevity.

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

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

With an output schema present, return values need no explanation, and annotations cover the safety profile. The description still supplies the auth note and the content-type envelope, which is nearly everything an agent needs to call it; only the unstated failure behavior for a bad id 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 100% for the single 'id' parameter, and the schema already documents that it comes from search. The description adds only that this id addresses 'one search result', which is marginal value over the schema. 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 names the resource precisely: the full text of one search result, enumerating the shapes it can take (player lines/graded results, league summary, guide, answer). That is enough to separate it from the sibling 'search' tool, which produces the list this one expands, though it never names that sibling explicitly.

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

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

Usage is implied rather than stated: the schema says the id comes 'from search', so an agent can infer the search-then-fetch flow. There is no explicit when-not guidance or statement of what happens with an invalid or stale id.

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, non-destructive and closed-world, so the safety profile is fully covered elsewhere. The only extra behavior the description adds is the word 'stable' - implying ids persist across calls - which is genuinely useful for caching/chaining but is never explained; nothing is said about result shape, paging via cursor/limit, or empty-result behavior on a tool with explicit pagination parameters.

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 a single front-loaded fragment with zero wasted words, which is good structure. However, brevity here crosses into under-specification: the tool takes 7 parameters including a required user_request and a cursor-based pager, and none of that complexity is acknowledged in even one additional clause.

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

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

For a 7-parameter search tool with no output schema, this description is far too thin. The agent cannot learn from it how results are ordered, whether person_key collapses split-league rows, or how cursor paging interacts with the 'stable ids' promise, and there is no output schema to fall back on.

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 each of the 7 parameters is already documented in the schema; baseline is 3. The description does map its three named axes onto search/league/team, giving mild orientation, but it says nothing about the interaction between them, about limit/cursor paging, or about person_key for cross-league identity - all of which live only in 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 fragment 'Stable player ids by name, league or team' names the resource (player ids) and the lookup axes, so an agent can infer it resolves players to canonical ids. But there is no verb and no differentiation from siblings like 'search', which would plausibly handle the same name lookups; the agent must guess which is authoritative for player identity.

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 when-to-use guidance, no exclusions, and no mention of when to prefer this over 'search' or the projection/game-log tools that also take players. The agent gets an implied 'use this to find players' and nothing more, so routing between this and 'search' 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?

Beyond annotations, the description discloses polling behavior, one-time key return, and secure storage requirements. It does not describe rate-limit behavior or failure modes, but adds meaningful 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?

Three short sentences with zero waste, front-loading the prerequisite and polling cadence before the return value and storage instruction.

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 polling tool with no output schema, the description covers prerequisite, cadence, termination, return behavior, and secure storage. Only edge-case behavior such as expiration or failure handling 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 0% for the single device_code parameter. The description helpfully says where device_code comes from (start_signup), but does not explain its format, lifetime, or handling expectations beyond that origin.

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 makes clear this is the completion step for signup: call with device_code from start_signup until the user approves, then receive the key. It is specific about the resource and outcome, though the verb 'Call' is less precise than 'poll' or 'finish'.

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 says to use device_code from start_signup and to call every few seconds until approval, giving clear timing and termination guidance. It does not state what to do on expiration or errors, but the main usage context is well covered.

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

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

Annotations already declare this a safe, idempotent read, so the description only needs to add gating context — and it does, disclosing that a developer key is required and that free evaluation silently resolves to a fixed training-set sample rather than true point-in-time data. That sample-substitution caveat is behavior an agent could not infer from the schema and materially affects result interpretation. It does not describe response shape, but no output schema exists to cover that gap either.

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 short sentences, front-loaded with the core identity of the tool, then use case, then entitlement constraints. No sentence is redundant and nothing is buried.

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

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

For an 8-parameter read tool with full schema coverage and rich annotations, the description covers purpose, use case, and access gating. The remaining gap is that a caller does not know what a 'board' row contains or how the snapshot relates to the live board, which matters for a point-in-time tool with no 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 description coverage is 100%, so the schema already documents as_of format, limit bounds, cursor opacity, league codes, and tier values. The description only restates the as_of format (ISO 8601 with time zone) and adds no meaning to the filtering parameters like stat, search, or tier. 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 action and resource: retrieve the board as it stood at a past instant, parameterized by as_of. The temporal qualifier distinguishes it from the current-state siblings like get_projections and get_demo_projections, though the term 'board' itself is never defined and no sibling is named explicitly.

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 clear use cases ('For backtests and point-in-time questions') and a routing rule for the free tier ('Free evaluation uses the fixed training-set sample'), which points the agent to get_training_set instead. It does not spell out the inverse case (use get_projections for the live board), so the alternative is implied rather than named.

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 closed-world, so the safety profile is covered. The description adds real context beyond that — cursor-based incrementality, a developer-tier requirement, and a fixed training-set sample for free evaluation — but it names the returned token 'next_cursor' while the schema parameter is 'cursor', leaving the loop ambiguous, and says nothing about the shape of returned change records.

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

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

Four short sentences, front-loaded with what the feed contains before the polling mechanics. Dense and mostly waste-free, with a small cost from the next_cursor/cursor naming mismatch and the environment-specific 'Developer required' clause.

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

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

With no output schema, the description carries return-value burden; it partially discharges this by naming the four change kinds and the cursor to persist, but omits anything about the change record shape, ordering, or the league filter's effect on the feed.

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 the baseline is 3. The description reinforces the cursor round-trip but adds no meaning for limit or league, and it does not reference the required user_request parameter at all, which is the one argument an agent could most easily mishandle.

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 resource and scope: a change feed covering new, changed, pulled and restored lines. The enumeration of event types distinguishes it from siblings such as get_line_history (full history) or get_stale_lines (stale-only), though it never names an alternative explicitly.

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

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

Gives concrete operational guidance: save next_cursor and pass it back to read only what moved since, framed as 'the cheap way to stay current'. This implies the incremental-polling use case versus a full refetch, but no explicit when-not or named alternative is stated.

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 closed-world behavior, so safety is covered. The description adds substantive return content (per-league offer counts, available stat sets, which leagues have history and graded results), which matters because there is no output schema. It says nothing about result size, freshness window, or whether the listing is paginated, which are the remaining behavioral unknowns for a coverage call.

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 compact sentences with zero filler, and the actionable instruction ('Start here') is front-loaded before the content description. Every clause conveys distinct information about what the response contains.

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 one-parameter discovery tool with annotations and no output schema, the description covers the essentials: entry-point role plus the categories of data returned. The remaining gap is precision on what 'available stats' and 'offer counts' actually look like in a response, but that is a minor gap for an index-style tool.

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

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

Schema description coverage is 100% and the single user_request parameter is documented at length in the schema itself, so the description carries no burden here. The description adds no meaning about the parameter beyond what the schema states, which matches the baseline 3 for high-coverage schemas.

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 the resource clearly: every league on the board, with offer counts, available stats, history flags and graded results. That is a specific enumeration rather than a restatement of 'get_coverage'. It stops short of naming a sibling it differs from (e.g. get_board_at or get_live_sports), so sibling differentiation is only implied by 'Start here'.

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?

'Start here' is an explicit ordering instruction that tells the agent to call this before the other board/data tools, which is real when-to-use guidance. There are no exclusions or named alternatives, so it does not reach the 5 bar of stating when NOT to use it or which sibling to pick for a narrower question.

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, destructiveHint=false and openWorldHint=false, so the safety profile is covered. The description adds the one trait annotations cannot express: the returned data is fabricated and must never be surfaced as real lines, which is the critical behavioral caveat for this tool.

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

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

Two short sentences, zero filler, with the identity of the data front-loaded before the misuse warning. Every clause 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 10-parameter read-only tool with full schema coverage and no output schema, the description supplies the essentials: what the payload is, that it mirrors the live shape, and that it must not be reported as real. It could note that filters still apply to a fixed fictional dataset, but nothing critical 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?

Schema description coverage is 100%, with enums and defaults documented for status, tier and limit, so the schema carries parameter meaning on its own. The description adds nothing about how stat/league/tier/cursor behave on sample data, nor whether filters meaningfully reduce the fixed sample set — that ambiguity is left unresolved.

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-like behavior and resource: it returns fictional sample rows shaped like the live response, explicitly for keyless trials. That distinguishes it cleanly from get_projections and the other data siblings, and the 'Never present these as real lines' clause adds a scope boundary an agent can act on.

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?

'For trying the API without a key' gives a clear selecting condition, and the warning implies these rows are not for real analysis. It stops short of naming the alternative (get_projections) or explicitly saying 'do not use once authenticated / when the user needs actual lines', so the exclusion 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?

The annotations establish that the call is read-only, idempotent, non-destructive, and closed-world. The description adds no behavioral context beyond those structured fields, such as lookup-failure behavior, data freshness, or response-expansion implications.

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 four-word description is direct, front-loaded, and free of filler. Its brevity conveys the essential lookup operation efficiently, with broader omissions assessed separately.

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 three-parameter read, the description is minimally sufficient when combined with the schema and annotations. With no output schema and no sibling-routing guidance, it would be more complete if it indicated what a fixture contains or when to choose get_fixtures or search.

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

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

The description confirms that id is the lookup key but adds no further parameter detail. The schema already documents include and user_request and supplies a pattern for id, so structured fields provide most of the parameter semantics at 67% description coverage.

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

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

“One fixture by id” clearly communicates retrieval of a single fixture using its identifier, consistent with the title “One game.” It does not explicitly differentiate the tool from siblings such as get_fixtures or search.

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 wording implies that the tool is appropriate when the caller already knows a fixture ID and wants that specific game. It gives no explicit guidance about when to use get_fixtures, search, or another sibling instead.

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

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

Annotations already establish readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the safety profile is covered. The description adds a useful scoping detail that results are games 'with lines on the board', but it does not explain pagination behavior, response shape, or other operational traits beyond what the schema and annotations provide.

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

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

The description is a single compact sentence with no wasted wording, and the core resource phrase 'Games with lines on the board' is front-loaded. It is appropriately brief, though for a nine-parameter tool it is arguably too terse rather than richly 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 nine-parameter list tool with no output schema, the description gives only a minimal indication of what is returned: games with lines. The schema covers filters well, and annotations cover safety, but the description does not clarify output shape, pagination behavior, or how this differs from close sibling tools.

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

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

Schema description coverage is 100%, so all nine parameters are already documented in the input schema. The description mentions only league, date, and status, which does not add meaning beyond the schema's own parameter descriptions. Baseline 3 is appropriate when the 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?

The description identifies the resource as 'Games with lines on the board' and lists filtering dimensions (league, date, status). It is clear enough to distinguish this from unrelated siblings, though it does not explicitly contrast itself with close siblings like get_fixture or get_board_at.

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

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

Usage is implied by the filtering dimensions 'by league, date or status', so an agent can infer it is for listing games with lines under those filters. However, there is no explicit when-to-use guidance, no exclusions, and no routing toward alternatives such as get_fixture, get_board_at, or get_odds.

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

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

Annotations already cover safety (readOnly, idempotent, non-destructive), and the description adds real behavioral context the schema does not: newest-first ordering, free-plan row caps, empty-page-with-warning behavior for unloaded leagues, and paid-plan cursor pagination. It does not say what meta looks like beyond next_cursor and stats_leagues, which is minor.

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 what a row is, then id options, then access limits and league coverage; every sentence carries a constraint. Slightly dense and the SOCCER/TENNIS sentence reads as an appended caveat rather than part of the flow.

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 17-parameter, output-schema-less list tool this covers the correctness essentials: id resolution, pagination, plan gating, and which leagues have stats. Return-shape detail (what compact vs full rows look like) is left to the schema, which is acceptable, and meta fields beyond next_cursor/stats_leagues go unmentioned.

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 the baseline is 3, but the description adds cross-parameter semantics the schema only states locally: last is tied to a single player, and the season-wide read needs league+season plus cursor following. It reinforces the meta.stats_leagues and SOCCER/TENNIS league expansion rules that govern whether a query returns rows at all.

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 box score line per past game) with field detail (minutes, opponent, home/away, every stat) and distinguishes itself from get_projections, find_players and get_results by pointing at them for ids.

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

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

Explicitly names uses (recent form, prop model features), the two id paths (player_id from get_projections or find_players, or player+league), and the season-wide path with next_cursor. It also states what does not work: free plan limits to last 10 games and no season-wide reads, and leagues without stats return an empty page.

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 closed-world, so the safety profile is covered. The description adds genuinely new behavioral context — plan-tier caps on game count and the 7-day window on per-game rows — but leaves unclear what "graded" means (settled vs. pending), what the tier field actually counts, and, with no output schema, what the returned hit-rate rows look like.

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

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

Two short sentences, front-loaded with the core definition, with the plan restriction appended as a secondary qualifier. Nothing is padded, though the extreme brevity leaves real gaps that a slightly longer description could close.

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, single-required stats tool with no output schema, the description covers what is computed and the free-plan limitation, which is the most important operational fact. It does not explain the more/demon/goblin tier semantics, how league affects results, or what the response contains, leaving meaningful work to the agent's inference.

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 fully documents last, stat, tier, league, player/player_id and user_request; the baseline is 3. The description does add one constraint not visible in the schema — that the free plan effectively caps results at the last 10 games — which clarifies the practical ceiling of the `last` parameter (schema allows up to 100).

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?

"How often one player has gone over, per stat, across their last graded games" gives a specific verb-like computation (over-rate frequency), a scope (single player, per stat, last graded games), so an agent knows this is a hit-rate aggregation rather than a raw log. It does not, however, distinguish itself from plausible siblings such as get_game_logs or get_projections, which could return overlapping underlying data.

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 no when-to-use guidance and names no alternative tool, so an agent must infer that this is the right call for over-rate questions versus get_game_logs for raw results. The only usage-adjacent content is the plan constraint (free plan = last 10 games, per-game rows from last 7 days), which is a limitation rather than a routing rule.

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

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

Annotations already declare this a safe, idempotent, closed-world read, so the bar is lower, yet the description still adds substantive context: every row carries provenance, the collection is empty below a dataset threshold, and the data has third-party rather than first-party status. The plan-tier limitation (7 days on free) is disclosure an agent cannot get from 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?

The identity of the data is front-loaded in the first sentence, followed by provenance, availability, presentation, and plan constraints. The telegraphic phrasing is dense but every clause carries a distinct operational fact; 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?

For an 11-parameter filtered read with full schema coverage and no output schema, the description covers the things an agent could get wrong: source attribution, empty-state precondition, and plan limits. Return shape and pagination are handled by the schema's meta references, so the remaining gap is minor.

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% with 11 well-documented parameters including three enums, so the schema already carries parameter meaning. The description adds nothing about individual parameters, which is acceptable at this coverage level but keeps it at baseline.

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

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

"Past lines supplied by third parties, not recorded by this API" states the resource and its scope precisely, and the negation clause separates it conceptually from tools returning this API's own observations (get_odds, get_line_history). It stops short of naming a specific sibling to prefer, so differentiation is conceptual rather than explicit.

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 supplies two real usage conditions: the dataset is empty until meta.available_datasets exceeds 0, and results must never be presented as lines this API observed. It also notes a free-plan restriction to the last 7 days. What is missing is routing guidance against alternatives such as get_line_history or compare_lines, so the agent must infer when this source is the right one.

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, non-destructive and closed-world behavior, so the safety profile is fully covered. The description contributes two useful facts beyond that: the data is third-party sourced and reflects 'current' status, implying freshness but not how fresh or how often refreshed. Return fields, injury status categories and pagination behavior are undisclosed.

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?

A single short sentence with no filler and the key qualifiers front-loaded. It is slightly telegraphic (no verb phrase), which reads more like a label than a description, but nothing is wasted.

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

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

For a simple four-parameter read tool with full schema coverage and no output schema, the description is barely adequate. It says nothing about what an injury record contains (player, status, body part, report date) or whether limits truncate silently, leaving the agent to infer result shape before calling.

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 team, league, limit and user_request are all already documented in structured form, and the description adds no syntax or edge-case meaning. The league enumeration in prose merely restates the enum. Baseline 3 applies when the schema carries the full parameter burden.

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?

Names a specific resource (injury reports), qualifies it as 'current' and 'third-party', and enumerates the covered leagues, so the agent can tell it apart from stat-oriented siblings like get_team_stats or get_game_logs. The verb is only implied by the name rather than stated in the description, which keeps it 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?

There is no guidance on when to call this versus alternatives, no note on prerequisites, and no exclusions. The one usable signal is the league scope, which is already in the schema's enum, so the description adds essentially nothing about 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 readOnly, idempotent, non-destructive, so the safety profile is covered. The description adds non-obvious context beyond that: chronological ordering of results, a developer-tier auth requirement, and the important caveat that free evaluation returns a fixed training-set sample rather than live data.

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

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

Four short sentences, each carrying distinct information, with the core action and ordering front-loaded before the id source and access caveats. Nothing is repeated from annotations or 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 never indicates what a "recorded change" entry actually contains (old vs new value, timestamp, actor), which is the main thing an agent needs to use the result. Pagination is left entirely to the schema's cursor parameter, leaving a notable gap for a history-listing tool.

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

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

Schema coverage is 75% and limit/cursor/user_request are already well documented in the schema, so the baseline is high. The description still adds real value by naming the provenance of the otherwise bare `id` string (take it from get_projections), which the schema does not say.

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: retrieving every recorded change to a single projection, with an explicit ordering ("oldest first"). It is distinguishable from siblings like compare_lines or get_changes, though the name/description slip between "line" and "projection" terminology without clarifying they are the same entity.

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

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

"Use an id from get_projections" explicitly routes the agent to the sibling that supplies the required identifier, and "Developer required" plus the free-evaluation note set expectations about access tier. It stops short of saying when to prefer this over compare_lines or get_changes, so the exclusion side is implied rather than stated.

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 annotations already declare readOnlyHint, idempotentHint, non-destructive and closed-world, so the safety profile needs no restating. The description adds the useful behavioral detail that data is bucketed every 15 minutes and includes the starting value. It is silent on pagination behavior even though limit and cursor exist, and on how large the result set can get.

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?

One sentence, front-loaded with the resource and the sampling interval, then the prerequisite. Nothing is wasted, though the trailing clause about the starting value is slightly compressed and could read more clearly.

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, four-parameter time-series call with no output schema, the description covers the grain of the data but not the response shape, max row count, or how pagination interacts with the 200-row default. It is adequate to call the tool correctly but not to predict what comes back.

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

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

Schema coverage is 75%, with limit and cursor fully documented and user_request explained in depth, so the baseline is 3. The description adds genuine meaning only for id by naming get_projections as its source, which is the one gap the schema leaves open.

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

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

The description states a specific verb and resource: it returns the reported pick count for a single line at 15-minute intervals, plus the starting value. An agent can tell it is a time-series read for one line rather than a comparison or a history dump. It does not distinguish itself from the similar sibling get_line_history, which leaves some ambiguity.

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

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

It gives a prerequisite pointer: 'Use an id from get_projections,' which directly tells the agent where the required id comes from. It says nothing about when to choose this tool over get_line_history or compare_lines, so the agent must infer the boundary.

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

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

Annotations only cover the read-only/idempotent safety profile, and the description adds substantive behavior beyond them: feed connectivity via meta.feed_connected, staleness caveats ('a connected socket does not mean each game changed this second', 'if disconnected, say the returned state may be stale'), and per-source differences in source_updated_at. This is exactly the kind of operational context annotations cannot express.

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?

Core purpose and source selection are front-loaded, and most sentences are terse and functional. The 'Developer or Production:' fragment at the start is slightly cryptic and the reporting instructions ('Always report observed_at...') are somewhat dense, but nothing is redundant.

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 burden of return-value context and does so for the key fields (observed_at, meta.feed_connected, source_updated_at). It stops short of describing the per-game payload itself (teams, score fields, period formatting) and how league filtering affects results, leaving a modest gap for a live-data tool.

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

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

Schema coverage is 100%, so the baseline is 3; the description goes slightly beyond by contrasting the two source values' downstream behavior (PrizePicks supplies source_updated_at, Polymarket leaves it null) and by noting the league filter is optional. It says nothing additional about the required user_request parameter, so it is not fully additive.

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 ('latest source-pushed game scores, period, clock and status') and explicitly distinguishes itself from sibling territory with 'These are game updates, not projection lines', separating it from get_projections/get_odds. An agent can route to it 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?

Gives a concrete selection rule for the source parameter ('use source=prizepicks for PrizePicks game state; default is polymarket') and instructions on what to report back. It does not name alternative siblings such as get_game_logs or get_odds when historical or betting-line data is the actual need, so the when-not guidance is implicit.

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=false and a closed world, so the safety profile is fully covered. The description adds only the scoping/grouping behavior; it says nothing about pagination behavior (limit/cursor/meta.next_cursor) or how lines and book prices are combined in the response.

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

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

Two short sentences, zero filler, and the resource identification is front-loaded before the input requirement. It is efficient, though it spends its brevity budget on almost no behavioral detail.

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?

This is a 12-parameter, paginated odds tool with no output schema, and the description is two sentences. It never explains what a result element looks like, how pagination interacts with the 5-per-page default, or how this differs from the many sibling odds/line tools, leaving real gaps for a tool of this 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 100% across all 12 parameters, so the schema already explains date, books, limit, cursor, league, market, player, status, main_only, book_lines and fixture_id in detail. The description contributes only the fixture_id-or-league requirement, which is worth something but is baseline-level when the 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?

The description names a concrete resource and shape: 'PrizePicks lines and book prices grouped by fixture.' That distinguishes it from get_fixtures (fixtures, not odds) and get_projections (modeled numbers, not market prices), but it never names those siblings explicitly, so the agent must 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?

'Needs fixture_id or league' gives a precondition, which is more than nothing, but there is no when-to-use vs when-not guidance and no routing to compare_lines, get_line_history, or get_projections. It also conflicts subtly with the schema, where only user_request is required.

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

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

Annotations already declare this a safe, idempotent, closed read, so the description is not the only safety signal. It still adds real behavioral context the annotations cannot: plan-tier limits (free plan capped at one team and its last 10 games), that an unloaded league returns an empty page with a warning, and that SOCCER/TENNIS aggregate every competition while each row names its competition. Return shape and pagination behavior remain unstated.

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?

Core purpose and the by= mode split are front-loaded in the first sentence, with prerequisites and plan limits after. It is terse to the point of clipped fragments ('Send team, or a season to read every team'), which is efficient but slightly telegraphic for a 13-parameter tool.

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

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

For a 13-parameter tool with 100% schema coverage, rich league-coverage notes, and annotations covering the safety profile, the description needs mainly to orient rather than document each field, and it does. The remaining gap is return content: with no output schema, an agent learns rows are per-game per-team or per-position stats but not which stat columns appear.

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 the baseline would be 3, but the description adds interpretive meaning the schema only hints at: the team-vs-season dichotomy for scoping rows, the by=position mode as a different unit of analysis, and end_date framed as 'the day before' a game for pre-game features. That framing is genuinely useful for an agent reasoning about point-in-time reads.

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?

Opens with a specific resource and verb-equivalent: 'What a team gives up per game to opposing teams,' and immediately branches the semantics with 'or by=position for what each position records against it.' An agent knows exactly what data is returned per row. It stops short of naming its closest sibling (get_team_stats), so an agent must infer the team-offense vs opponent-allowed distinction from names alone.

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

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

Gives concrete selection rules: pass a team for one defense, or a season to read every team, and use end_date to read a past-day snapshot. It also states hard preconditions — league must be in meta.stats_leagues — and the free-plan restriction of one team over its last 10 games. No explicit exclusion against alternatives like get_team_stats or get_hit_rates, which keeps it out of the top band.

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 closed-world behavior, so the safety profile is covered. The description adds only the qualifier 'Standard', which implies fixed PrizePicks tables rather than custom ones, but it says nothing about how many legs are covered, how the break-even rates are computed, or what the result set looks like.

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?

One sentence, front-loaded with the resource being returned and free of filler. It is arguably over-trimmed for a tool with no output schema, but nothing is wasted.

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

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

For a simple, single-parameter, read-only lookup with no nested objects, the annotations and schema cover most of what an agent needs. However, with no output schema, the description should say more about what the payout table contains, such as which leg counts and multipliers are included, so the agent knows whether this tool answers its question.

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

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

There is a single parameter and the schema documents it at 100% coverage, including length bounds and privacy guidance, so the schema carries the full load. The description adds no extra meaning about user_request or about how the payout data relates to the caller's task.

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 the specific resource returned: 'Standard PrizePicks payout tables with per-leg break-even rates.' That is concrete enough to distinguish it from every sibling, none of which deals with payout or break-even data, though the verb is implied rather than stated.

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

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

There is no when-to-use guidance at all: nothing says when an agent should fetch payout tables versus, say, compare_lines or get_odds, and no prerequisites or follow-up steps are mentioned. The agent must infer the trigger from the phrase 'break-even rates' alone.

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 closed-world, so safety needs no restating. The description adds real behavioral detail beyond them: exact league codes are required, unknown start times are excluded by the time filters, and output rows switch shape based on view. Pagination behavior and rate limits are left implicit, which keeps it at a 4.

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 tool's purpose and primary value, then moves through filters, time-boundary rules, and output shape in a logical order. It is dense but each clause carries information; only the repeated view/compact explanation overlaps with the 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 11 parameters, no output schema, and heavy filtering, the description covers the return row shape (flat fields vs nested objects), the tier labeling, and the inclusive/exclusive time boundary rules. An agent has enough to call it correctly without opening the schema, and the annotations cover safety.

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 carries the parameter burden and baseline is 3. The description does reinforce a few semantics the schema also states — exact league codes only, start_after inclusive vs start_before exclusive, unknown starts excluded, view=full for nested objects — but adds little that is not already in the schema text.

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

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

States a specific verb and resource ('get current PrizePicks lines') and adds a positioning claim ('the first place to get current PrizePicks lines') that distinguishes it from the many sibling read tools like get_board_at, get_changes, and get_line_history. It also names the filtering axes and the tier labeling, so an agent knows exactly what this tool returns.

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

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

The phrase 'The first place to get...' gives a clear default entry point when the agent wants current lines, and the description enumerates the filter combinations that select this tool (league, stat, player/team search, tier). It stops short of naming explicit alternatives or when-not-to-use conditions, so it falls just below the top score.

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

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

Annotations already establish this is a safe, idempotent, closed-world read, so the bar is lower; the description still adds real behavior: an authentication/tier requirement (developer access), the data source (final box scores), and a free-tier caveat about the fixed training-set sample. It stops short of describing ordering, pagination limits, or what a void/ungraded row looks like.

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 short sentences, front-loaded with what is returned, then access constraints. The phrasing is telegraphic and slightly clipped, but nothing is redundant.

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 some burden for explaining the response, and it does name the key fields, but only in a single compressed clause. For a 9-parameter tool with pagination (limit/cursor), it does not explain result ordering or how paging interacts with filters, leaving a modest gap.

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

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

Schema description coverage is 100%, so every parameter is already documented in the schema and baseline 3 applies. The description reinforces the league filter via meta.leagues_graded and lists the outcome values, but adds no syntax or format guidance beyond what the schema already supplies.

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 the specific resource and content — lines graded against final box scores, returning closing line, actual value and outcome (over/under/push/void). It also scopes the data to NBA plus whatever meta.leagues_graded lists, but it does not contrast itself with close siblings like get_projections or compare_lines, leaving some disambiguation to the name alone.

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

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

"Developer required" gives a clear access precondition and "Free evaluation uses the fixed training-set sample" hints at an alternative path for non-developers, but the sibling get_training_set is never named and there is no explicit statement of when to prefer this tool over compare_lines or get_line_history. Usage must be inferred rather than read.

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, destructiveHint=false and openWorldHint=false, so the safety profile is covered. The description adds real value beyond that: the pre-game domain restriction, the two book sources compared, what each row contains, and a required disclosure when relaying results. It stops short of describing volume, ordering guarantees beyond the limit param, or how ties/absent books are handled.

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 core definition and followed by row contents and the relay caveat. No filler, no restatement of the title, and the non-advice instruction is placed where it will be read.

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 10 parameters and no output schema, the description carries the return-shape burden and does so by enumerating row fields, plus it scopes the domain and adds the disclosure requirement. Minor gaps remain around pagination behaviour and what an empty result implies, but nothing essential for a correct call 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%, so the schema already documents book, stat, limit, league, player, min_move, user_request, max_age_minutes, include_reverted and lookback_minutes. The description reinforces the semantics of a measured 'move in probability points' and the notion of a line that 'stayed', which underpins min_move and lookback_minutes, but adds no field-level detail the schema lacks.

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, distinctive resource: PrizePicks lines in NBA/NFL/NHL pre-game where the BetRivers or Kalshi price moved materially while the PrizePicks line stayed. It also enumerates the per-row fields (line, move in probability points, move time, staleness duration, observed_at for both sides), so an agent knows exactly what it gets and how this differs from a generic change feed or line-history sibling.

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?

Implicit usage is clear (surface stale PrizePicks lines relative to book movement) and the 'before the game' scope plus the 'information about prices, not a prediction or betting advice' relay instruction are useful constraints. However, it never says when to prefer this over siblings such as get_line_history, get_changes or compare_lines, nor any when-not conditions, leaving routing 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 safety (readOnly, idempotent, non-destructive, closed world), so the bar is lower, and the description still adds genuine context: an unknown league returns an empty page with a warning, segment leagues resolve to their parent league, and the free plan exposes only one team's last 10 games. It says little about pagination or row shape beyond the opponent-beside-team framing, which keeps it short of a 5.

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

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

Three short sentences with no filler, and the output shape is front-loaded before the mode switch and the constraints. The telegraphic phrasing ('with the opponent's beside them') is slightly harder to parse than plain prose, which costs it a point.

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 14-parameter, multi-mode tool with no output schema, the description covers the mode switch, prerequisites and plan limits but leaves return values largely implicit and says nothing about paging behavior or how view/limit interact across modes. The rich schema carries most of the weight, so this is adequate rather than complete.

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

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

Schema coverage is 100%, so baseline is 3, but the description adds meaning the schema does not: team and season are alternatives that select a different result grain, and group_by=season switches from rows-per-game to per-game averages and totals. The free-plan sentence also explains why a team/limit combination may return less than requested.

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

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

The description names a specific resource and shape: a team's per-game stats with the opponent's stats alongside, plus a season-aggregate mode via group_by=season. It implicitly separates itself from get_opponent_stats by saying opponent figures come back in the same rows, but that distinction is left for the agent to infer rather than stated.

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

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

It gives real prerequisites (league must come from meta.stats_leagues) and both usage modes: pass team, or pass a season to read every team. It also flags a plan constraint. What is missing is explicit routing against siblings such as get_game_logs or get_opponent_stats, so the agent must guess when this is the better call.

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 real substance beyond them: default void exclusion, cursor pagination, a streaming/memory warning, and a concrete free-plan ceiling (one page, up to 100 sampled rows from the last 7 days). No mention of rate limits or auth, but the plan constraint is disclosed.

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

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

Three tight sentences, front-loaded with the row shape an agent needs first, then behavioural caveats, then plan limits. The field enumeration is long but informative; nothing is wasted or buried.

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

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

For a 12-parameter read tool with no output schema, the description supplies the row shape, pagination model, default filtering, and plan limits — enough to invoke it correctly. Minor gaps remain around filter interaction (e.g., whether date filters are required) but the schema covers those fields thoroughly.

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 every parameter including cursor, include_void, and the date fields is already documented. The description's remarks on voids and cursoring largely restate the schema, so it sits at the baseline rather than adding new parameter-level meaning.

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

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

States a specific resource and its shape: one flat row per graded line, with an enumerated set of columns (opening/closing line, tier, opponent, home/away, rest days, minutes, actual value, result). This differentiates it in substance from siblings like get_results or get_game_logs, though it never names those tools explicitly.

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

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

Gives a clear usage context ('for building a prop model') plus operational guidance: voids are excluded unless opted in, page with cursor, persist rows rather than holding them in conversation. It stops short of explicit when-not-to-use or naming an alternative sibling for non-training queries.

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

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

Annotations already establish that this is a safe, read-only, idempotent call, so the bar is lower. The description still adds real behavioral context that the annotations cannot: most lines report no count, so sparse/empty values are expected, and with sort=change lines lacking an old enough sample are pushed to the end. It does not mention rate limits or payload size, but the key data-quality caveat is disclosed.

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 short sentences, front-loaded with what the tool returns rather than with preamble. "For screens and alerts" is slightly clipped and vague, but nothing in the text is redundant.

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 full schema coverage, rich annotations, no output schema and only five parameters, the description only needs to add the delta. It covers the ranking behavior and the important caveat that most lines have no count; what is missing is the distinction from get_line_popularity and any sense of the row shape 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?

Schema description coverage is 100%, so sort, limit, league, window_minutes and user_request are all documented in the schema, giving a baseline of 3. The description's phrasing of sort=change ("how fast the count is rising") only restates the schema's "biggest rise over window_minutes" and adds no new detail on window/limit interaction.

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?

"Current lines by reported pick count" states a concrete resource (lines) and ranking basis (pick count), with the alternate ranking mode called out inline. It does not distinguish itself from the close sibling get_line_popularity, which also sounds like it ranks lines by popularity, so an agent must still guess between the two.

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?

"For screens and alerts" gives an implied context but names no alternative tool and no exclusion condition. The two sort modes are effectively a usage guide (use sort=change for rising momentum), but the choice against get_line_popularity or get_line_history is left unaddressed.

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, non-destructive and closed-world behavior, so the safety bar is low. The description adds genuinely new operational context: no authentication key is required, and results feed a two-step flow into fetch via a result id, which tells the agent how to chain calls.

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 short sentences, front-loaded with the capability, then the key constraint, then the follow-up action. No filler and no 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?

An output schema exists, so return values need no explanation, and the description covers purpose, auth precondition and next step. The only meaningful gap is the lack of differentiation from find_players for a tool whose purpose is close to 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?

Schema coverage is 100% and the single parameter's own description already explains it takes words like a player name, league or question. The description's 'player, league, guide or answer' phrasing largely restates the schema rather than adding format, syntax or matching-behavior detail, 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 gives a specific verb ('Find') and names concrete resource types (player, league, guide, answer) plus the site it searches, so the agent knows exactly what it does. It stops short of distinguishing itself from the sibling find_players, which appears to overlap on player lookup, leaving some ambiguity about which to pick.

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

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

It states a clear selecting condition ('Use this when no API key is connected') and a follow-up step ('Then call fetch with a result id'), which is actionable routing guidance. It does not explicitly exclude or compare against sibling find_players, so the alternative-selection picture is incomplete.

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=false, destructiveHint=false, idempotentHint=false and openWorldHint=false. The description adds real value beyond them: submission needs no key and costs no quota, and personal data should be excluded. It does not say whether the submission is one-way or whether any acknowledgement or ticket identifier comes back.

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 short sentences, front-loaded with what to report and followed by specificity and privacy constraints plus the cost note. Every clause carries information; 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?

For a six-parameter, one-required submission tool with no output schema and rich annotations, the description covers purpose, content quality, privacy and cost. The only meaningful gap is what happens after submission, since no output schema exists to explain the response.

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

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

Schema coverage is 83%, so the schema already explains message, agent, blocking, endpoint and use_case. The description reinforces message content (league, stat, field, intent) and the privacy constraint, which meaningfully shapes what goes into that field. It says nothing about the kind enum, the blocking flag, or endpoint, which remain schema-only.

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 action and enumerates the exact things to report: missing data or features, wrong data, or anything confusing. It is unmistakably distinct from the data-retrieval siblings. It stops short of naming the destination explicitly (the team), leaving that to the title.

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

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

It gives clear when-to-use conditions (data or feature you needed and could not get, wrong data, confusing behavior) plus content guidance: be specific about league, stat, field and intent, and omit personal data. No alternative tool is named, but no sibling overlaps this submit-feedback role, so there is nothing to route away from.

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 it is a non-read-only, non-destructive, non-idempotent operation, and the description adds the crucial human-in-the-loop detail: it returns a link the user must approve in the browser, plus a code they must be shown. This return-shape disclosure is valuable given there is no output schema, though failure modes and link expiry are unstated.

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 short sentences, front-loaded with the purpose, then the prerequisite, then the next step. The first sentence is compressed into a semicolon clause but nothing is wasted.

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

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

For a signup-initiation tool with a nested details object and no output schema, the description supplies the key missing pieces: what the call returns (link and code), that the user must approve it, and what to call next. Only error and retry behavior is left implicit.

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

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

Schema description coverage is 100%, so all five parameters are already documented, including the 'ask, do not guess' instruction on found_us. The description restates the data_wanted and use_case requirements at a high level without adding format or constraint detail, so 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?

States a specific verb and outcome ('Starts getting a free API key') and names the follow-up sibling finish_signup, so the agent can place it in a two-step flow. It stops short of distinguishing itself from complete_setup or the other setup-adjacent 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?

Gives clear contextual guidance: only call it once you know what data the user wants and their use case, ask rather than guess, then call finish_signup. There is no explicit when-not-to-use or comparison against complete_setup.

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