DraftKings API

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 fully covered. The description adds only the auth note ('No key needed'), and says nothing about what a 'page' contains or how an invalid/stale id behaves.

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

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

Two short sentences with no wasted words, and the access note comes after the core action. The terseness edges toward underspecification rather than padding, 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?

For a one-parameter read with a full annotation set and no output schema, this is close to sufficient. What is missing is the identity of the resource: what a 'page' is and what content comes back, which an agent needs to decide to call it.

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

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

The single 'id' parameter has 0% schema description coverage, so the description must compensate. It does partially, by identifying the id's source (the search tool), but gives no format, validity, or reuse guidance for that id.

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

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

States a specific verb ('Read') and resource ('a page') and ties it to the id returned by the sibling 'search' tool, which separates it from search itself. The noun 'page' stays abstract — given the surrounding sports-data siblings, an agent cannot tell what kind of page is being read.

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 an implied workflow ('by the id returned from search') and a mild precondition ('No key needed'), so an agent knows the id must come from a prior search. It never states when not to use it or how it differs from the many get_context_*/get_stats_* siblings.

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 a useful caveat that ESPN source IDs are separate from DraftKings IDs, which helps avoid ID namespace confusion, but it does not explain pagination, filter combination behavior, or what the returned scores/box scores include.

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

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

The description is two short sentences with no filler, and the key ID caveat is stated directly. However, the first sentence is a fragment rather than a front-loaded verb phrase, which slightly weakens clarity.

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 query tool with five optional parameters, no required fields, 0% schema coverage, and no output schema, the description is too thin. It should explain how event_id, athlete_id, sport, limit, and offset shape results, and ideally clarify whether this returns game-level context only or also athlete/team breakdowns.

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

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

Schema description coverage is 0%, so the description must compensate for five undocumented parameters. It only hints at ID-namespace semantics via 'ESPN source IDs are separate from DraftKings IDs,' but does not explain event_id, athlete_id, sport code format, limit, or offset, leaving most parameter meaning unstated.

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 scores and box scores, but it is written as a noun phrase rather than a clear verb-led statement of what the tool does. It does not distinguish this tool from sibling get_stats_games, which likely also returns game-level 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?

There is no explicit guidance on when to use this tool versus get_stats_games, get_context_player_stats, or get_context_team_stats. The term 'context' implies supplemental data, but the agent must infer the selection criteria from the name 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 readOnlyHint, idempotentHint, destructiveHint=false and openWorldHint=false, so safety is covered. The description adds a genuinely useful behavioral caveat that ESPN source IDs are separate from DraftKings IDs, warning about an identifier mismatch. It does not, however, describe pagination behavior, default ordering, or what happens when filters are omitted.

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

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

Two short sentences with no filler, so length is fine. However, the opening is a fragment rather than a front-loaded statement of what the tool does, which weakens structure 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?

A tool with five undocumented parameters and no output schema needs substantially more description than this. The description never explains the filters, the pagination controls, or the shape of returned scores, so an agent would have to guess at invocation details.

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

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

Schema description coverage is 0% across five parameters (limit, offset, sport, event_id, athlete_id), so the definition must compensate and largely does not. The ID-namespace sentence is tangentially relevant to event_id and athlete_id but never states which namespace the parameters expect or how sport/limit/offset behave, leaving most parameters unexplained.

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 scores and box scores attached to observed events and tags it '(player-stats)', but it is a noun phrase with no verb and never says 'retrieve' or 'list'. It does not distinguish this from the close sibling get_stats_player_games, so an agent cannot confidently tell the two apart from the text alone.

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

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

There is no statement of when to use this tool versus get_stats_player_games, get_context_team_stats, or get_context_games. The only guidance-like sentence concerns ID namespaces, not tool selection, so the agent must infer usage from the name 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 readOnlyHint, idempotentHint, and closed-world scope, so the safety profile is covered by structured data. The description adds genuinely useful domain context that ESPN source IDs differ from DraftKings IDs, which affects how IDs should be interpreted. It still says nothing about pagination behavior, result volume, or what happens when event_id/athlete_id filters are omitted.

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

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

Two short sentences with no wasted words, so it is compact. But it opens with a sentence fragment rather than leading with the operation, and the ID-namespace caveat is buried in second position without framing.

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?

Five optional parameters, no schema descriptions, and no output schema mean the description is the only place an agent can learn how to filter correctly, and it does not cover that. For a tool whose inputs determine whether it returns one event's box score or a broad paginated scan, the definition omits the information needed to call it confidently.

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

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

Schema description coverage is 0% across five parameters, so the description must carry the burden, and it largely does not. The ESPN-versus-DraftKings ID note has bearing on how event_id and athlete_id values are interpreted, and 'observed events' hints at event_id, but limit, offset, and sport are never mentioned and it is unclear whether the ID filters accept either ID namespace.

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 team-level scores and box scores attached to observed events, which is more specific than the name alone. However, it is a noun phrase fragment with no verb describing the operation (retrieve/list), and it does not distinguish this tool from the near-identical sibling get_stats_team_games.

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

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

There is no explicit when-to-use guidance: no mention of choosing this over get_context_player_stats, get_stats_team_games, or get_context_games. The phrase 'attached to observed events' weakly implies a link to event records, but the agent must infer the selection criteria entirely.

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, and openWorldHint=false, so the safety profile is fully covered by structured data. The description adds one genuinely new behavioral fact — it reports *stored* coverage, i.e. what has already been collected rather than a live query — but gives no indication of return shape or whether results are cached/stale, which matters because no output schema exists.

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

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

Two short sentences with the action directive ("Start here") front-loaded, so the agent's first read yields the routing decision. The second sentence is dense with undefined jargon, but nothing is padding or repetition of the title.

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?

Complexity is low (zero parameters, read-only), which lowers the bar, but there is no output schema and the description never says what a "coverage" response contains or how an agent should act on it. For a self-declared entry-point tool, the omission of return content leaves the most important question open.

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

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

The tool takes zero parameters, so there is nothing for the description to disambiguate. The baseline of 4 applies; no parameter guidance is needed or missing.

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?

"Measured stored coverage and collector context" names a resource (coverage) and implies it reports what data has been collected, which distinguishes it from fetch/stats/odds siblings. However, "coverage" and "collector context" are jargon that never resolves into a concrete object — coverage of what (games, players, slates, sportsbooks?), and what form the measurement takes. An agent knows it is a status/orientation tool but not precisely what it reports.

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, front-loaded call-order directive, which is exactly the guidance an orientation tool needs against 16 siblings. It stops short of stating what to do next or when it can be skipped, so it is clear context without exclusions.

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

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

The annotations already declare readOnlyHint=true, idempotentHint=true, destructiveHint=false and openWorldHint=false, so safety and mutability are covered. The only behavioral fact added is that results come from a distinct dataset not mixed with sportsbook or Pick6 data. Nothing is said about pagination behavior, ordering, or how empty results behave, despite limit/offset parameters being present.

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 two sentences are front-loaded and contain no filler, which is good structure. But the first sentence merely restates the tool name and title, so the text is under-specified rather than genuinely concise.

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?

Four undocumented parameters, no output schema, and no enum constraints mean the description would need to carry substantial explanatory weight. Instead it provides only a dataset-origin note, leaving an agent unable to predict filters or result shape with confidence.

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

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

Schema description coverage is 0% for four parameters, so the description carries the full burden of explaining limit, offset, sport, and slate_id. It mentions none of them, adding no meaning beyond the bare JSON types, defaults, and patterns. An agent can guess that limit/offset paginate, but the relationship between sport and slate_id is left entirely unexplained.

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 (DFS contests) and states it is a separate dataset from sportsbook and Pick6, which does differentiate it from those siblings. However, there is no verb and no differentiation from the closely related get_dfs_slates, get_dfs_players, and get_dfs_sports tools, so an agent cannot tell which DFS endpoint returns what.

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 only implied by the exclusion 'a separate dataset from sportsbook and Pick6', which tells the agent this is the DFS source rather than the sportsbook source. There is no guidance on when to choose this over get_dfs_slates or get_dfs_players, and no statement of prerequisites or expected result shape.

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 read, so the description's job is to add non-obvious traits — and it does: it warns that one athlete can appear in several rows (a duplicate-key hazard for consumers) and that 'salary is not a price' (a semantic caveat that prevents misuse). It stops short of describing pagination behavior or ordering despite limit/offset parameters, which keeps it from 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 very short sentences with no wasted words, and the salary caveat is placed last where it lands as a warning. However, the opening fragment is telegraphic and verbless, so brevity comes at the cost of immediate comprehension.

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 four-parameter, zero-documented-schema tool with no output schema, the description does far too little: no filter semantics, no pagination defaults, no explanation of returned fields despite referencing salaries. The duplicate-row and salary caveats partially compensate, but an agent could still call this with the wrong filter and misread results.

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

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

Schema description coverage is 0%, so the description must carry parameter meaning, and it explains none of limit, offset, sport, or slate_id. The one usable hint is the 'several rows' remark, which implicitly justifies filtering by slate_id, but the agent gets no guidance on which filter to pass or how pagination bounds interact.

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 is a noun phrase ('Roster-slot draftables with salaries') rather than a verb+resource statement, so the agent must lean on the tool name to know this lists DFS players. The domain terms 'roster-slot' and 'draftables' do narrow the resource, but nothing distinguishes it from siblings like get_dfs_slates or get_dfs_contests beyond the word 'players' being absent.

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

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

There is no when-to-use guidance, no mention of the slate_id parameter as the natural scoping path, and no reference to sibling tools for contests, slates, or sports. The agent gets no signal about whether this is the right call before or after fetching slates.

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 openWorldHint=false, so the safety profile is fully covered without the description. The description adds no behavioral context of its own – no mention of pagination defaults, what a slate record contains, or how results are ordered – so it contributes essentially nothing beyond the structured annotations.

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

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

Two short sentences with no filler, and the dataset distinction is front-loaded after the resource name. The brevity is not a virtue here, though: the text is under-specified rather than efficiently complete, leaving no room for the operational details an agent needs.

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

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

For a tool with four undocumented parameters, no output schema, and no explanation of what a DFS slate is or how it relates to contests and players, the definition is far too thin. The only useful content is the dataset boundary against sportsbook and Pick6, which does not cover what an agent must know to call this correctly.

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

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

Schema description coverage is 0% across four parameters (limit, offset, sport, slate_id), and the description says nothing about any of them. An agent gets no explanation of the slate_id format, whether sport is a name or key, or how limit/offset pagination behaves, so the description fails entirely to compensate for the coverage gap.

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

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

The description names the resource (DFS slates) and states it belongs to a separate dataset from sportsbook and Pick6, which helps distinguish it from sibling data sources. However, it never supplies a verb or explains what the tool actually does with slates (list them, filter them, return contests within them), so the purpose is only implied by the name and 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?

The only guidance is the implicit signal that this is the DFS dataset as opposed to sportsbook or Pick6. There is no statement of when to call this tool versus get_dfs_sports, get_dfs_contests, or get_dfs_players, and no prerequisites or exclusions are given.

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 only the dataset-separation fact, with nothing about result shape, ordering, or pagination behavior beyond the limit/offset 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?

Two short sentences with no filler, so nothing is wasted. But the brevity comes at the cost of substance rather than being tightly front-loaded 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?

With no output schema, zero parameter documentation, and only a one-clause purpose statement, the definition does not give the agent enough to call the tool confidently or predict what it returns. A tool that enumerates sports for a DFS dataset should at minimum say so.

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

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

Schema description coverage is 0%: neither limit nor offset carries any documentation in the schema, and the description mentions no parameters at all. The agent must infer standard pagination semantics entirely on its own, which is a clear gap given the low 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?

"DFS sports" only restates the tool name and title; no verb or resource shape is given (does it list sports, return sport metadata, or something else?). The second sentence distinguishes it from sportsbook and Pick6 datasets, which is useful routing information, but the actual operation remains undefined.

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 note that this is 'a separate dataset from sportsbook and Pick6' implies the agent should pick this tool when working with DFS data, which is a hint at alternatives. However, it gives no explicit when-to-use condition and says nothing about how it relates to the DFS siblings (get_dfs_contests, get_dfs_slates, get_dfs_players).

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=true, idempotentHint=true and destructiveHint=false, so the safety profile is covered. On top of that, the description adds real behavioral value by disclosing pagination continuation ("Continue from pagination.next_after with offset=0"), which also implies the response carries a pagination object. It still omits ordering, result shape beyond pagination, and what a returned "change" contains.

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

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

Two short sentences with zero filler and the pagination rule given last, which is reasonably front-loaded. However, the terse fragment style leaves the core purpose cryptic rather than crisp, so brevity here reads as under-specification rather than economy.

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 eight undocumented parameters, no output schema, and domain-specific identifiers, the description does far too little — it covers pagination but not what is retrieved, how filters combine, or what the returned records look like. For a tool of this schema complexity, substantially more prose is required.

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

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

Schema description coverage is 0%, so eight parameters (stat, sport, after, limit, offset, pickable_id, pick_group_id, pickable_market_id) carry no documented meaning anywhere. The description only clarifies the offset parameter in the continuation case; the other seven, including the domain-specific pickable/pick_group IDs and how "after" differs from "offset", are left entirely to inference.

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?

"Recorded Pick6 changes" is a noun phrase that essentially restates the name/title rather than stating a verb and resource. It never says whether the tool lists pick records, returns change-log entries, or what a "Pick6" entity is, so an agent cannot confidently distinguish it from get_pick6_projections or get_sportsbook_history.

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

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

There is no when-to-use guidance and no mention of alternatives, despite the sibling set containing get_pick6_projections and several other history/list tools. The only procedural hint is a pagination instruction, which is operational rather than selection guidance.

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

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

Annotations already declare readOnlyHint, idempotentHint, non-destructive and closed-world, so the safety profile is fully covered. The description adds genuine domain context that the rows carry target values and standings multipliers, but says nothing about result ordering, pagination behavior, or what an empty filter returns.

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

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

Two short sentences, front-loaded with the resource statement and free of filler. The brevity is efficient but tips into under-specification for a seven-parameter tool, so the terse structure is not fully earning 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?

With seven optional parameters, no schema descriptions, and no output schema, the description should carry most of the burden but covers roughly a quarter of the filter surface. An agent cannot tell how to page through results or how the three ID filters narrow the rows.

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

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

Schema description coverage is 0%, so the description must compensate, yet it only names two of seven parameters (sport, stat). The four identifier filters (pickable_id, pick_group_id, pickable_market_id) and the limit/offset pagination controls are never explained, and the phrasing implies sport/stat are the only available filters.

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 ("Stored Pick6 market rows with target values and standings multipliers") and a retrieval intent, but uses no verb and never states it returns a list. Against sibling get_pick6_history the distinction is unclear, since both concern Pick6 data and no differentiating scope is given.

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 is provided and no alternative is named, even though get_pick6_history sits in the sibling list and likely overlaps. The agent must infer selection criteria from the name 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 establish a read-only, idempotent, non-destructive, closed-world operation. The description adds that the events are stored and enumerates possible event_status values, but says nothing about freshness, pagination, filtering behavior, or response shape.

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 single fragment is compact, puts the resource first, and contains no filler. Its brevity omits essential operating details, making it terse rather than effectively complete.

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 four-parameter read tool with no parameter descriptions and no output schema, listing status values is not enough to support confident invocation. Pagination and filter semantics, as well as the relationship to sibling sportsbook tools, are left to schema inspection or 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 0%, and the description documents none of limit, sport, offset, or event_id. It mentions event_status even though no such parameter exists, without clarifying whether that is an output field or a filtering concept.

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 name and description together indicate access to stored sportsbook events, and the status values provide some domain scope. However, the description does not state a list/get action or distinguish this tool from get_sportsbook_history or get_sportsbook_odds.

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

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

There is no explicit when-to-use guidance, prerequisite, or alternative. An agent must infer that this tool is for event retrieval rather than history or odds from the sibling names 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?

The annotations already declare readOnlyHint, idempotentHint, openWorldHint=false and destructiveHint=false, so safety is covered structurally. The description does add one genuinely useful non-obvious trait: results are retained/partial observations rather than a complete opening-to-close series. However, it says nothing about ordering, pagination behavior, or what a caller should infer from gaps.

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

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

The text is short but consists of two fragmentary sentences that read as an internal caveat rather than a front-loaded statement of purpose. Brevity here is under-specification, not concision — the space saved is not well spent given 6 undocumented parameters.

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

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

A 6-parameter query tool with 0% schema coverage, no output schema, and no annotation explanation of the result set requires far more: what the history contains, how it is ordered, what the filters do, and why coverage is partial. None of that is present.

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

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

Schema description coverage is 0% across 6 parameters (limit, offset, sport, market, event_id, offer_id), and the description supplies no meaning for any of them — no filter semantics, no pagination explanation, no accepted values for sport or market. With no structured documentation, the description had to compensate and does not.

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

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

The description never states a verb or what the tool returns; it only says 'Retained observations' and warns the data is not opening-to-close complete. The actual purpose ('history of sportsbook odds observations') is left to the name and title, so the description is close to restating the name with a caveat attached.

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 use this tool rather than the many siblings such as get_sportsbook_odds, get_sportsbook_events, get_pick6_history, or get_dfs_contests. No exclusions, prerequisites, or context are given.

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: the data is 'stored' observations 'with provenance', signaling historically captured snapshots rather than live lines, and that coverage may be incomplete. It omits pagination behavior despite limit/offset 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?

Two short sentences with the substantive point (stored observations with provenance) front-loaded. The second sentence is short but squandered on an unresolvable '/status' reference rather than useful routing.

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 query tool with no output schema and zero parameter documentation, the description is far too thin. An agent knows roughly what the data is but not how to scope a query, what paging does, or when to prefer an alternative odds/event 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 0% across five parameters, so the description must carry the burden and does not. It mentions moneyline/spread/total, which loosely maps to the 'market' parameter, but says nothing about sport, event_id scoping, or limit/offset paging semantics.

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

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

The description names the resource ('moneyline, spread and total observations') and implies retrieval of stored odds, but never states a verb like list or fetch, and does not distinguish this from siblings such as get_sportsbook_events or get_sportsbook_history. The '/status' pointer references something outside the sibling tool set, adding ambiguity rather than clarity.

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?

'Check /status for current market coverage' is the only usage cue, and it points to a path that does not correspond to any listed sibling (get_coverage is the closest match). There is no guidance on when to use this versus get_sportsbook_events (upcoming events) or get_sportsbook_history, which an agent cannot resolve on its own.

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 openWorldHint=false, so the safety profile is fully covered and the description adds nothing on top. It says nothing about result shape, pagination behaviour (even though an `after` cursor exists), or what a season/event_id combination returns.

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

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

Two short sentences with no filler, and the required-parameter note is front-loaded. However, the brevity is under-specification rather than efficiency: the first fragment carries almost no actionable meaning and the second duplicates structured data.

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 five parameters, 40% schema coverage, no output schema, and three near-identically named stats siblings, an agent needs more than this to select and invoke the tool correctly. The description does not resolve the sibling ambiguity, explain the cursor parameter, or indicate what statistics are returned per game.

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

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

Schema description coverage is only 40%, so the description needs to compensate, but it merely repeats that sport and season are required – information already encoded in `required` and the enum. It leaves `event_id` and `limit` (1-200) entirely unexplained and does not clarify the season-year convention that the schema only partially documents.

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?

"Independent games statistics" names a resource but no verb and no qualifier an agent can act on – "independent" is undefined jargon, likely meaning independent-league or non-team-aggregated data, which the reader cannot resolve. It also fails to distinguish itself from the sibling tools get_stats_player_games and get_stats_team_games, which share the same naming family.

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 only guidance is "sport and season are required," which restates the schema's required array rather than saying when to use this tool. There is no mention of when to prefer it over get_stats_player_games, get_stats_team_games, get_context_games, or the sportsbook/DFS siblings, and no exclusion criteria.

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

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

Annotations already declare readOnlyHint, idempotentHint, openWorldHint=false and destructiveHint=false, so the safety profile is fully covered without the description. The description adds no behavioral context of its own - nothing about pagination behavior, result size, coverage limits, or empty-result handling - which is exactly what an agent would need beyond the annotations.

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

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

Two short sentences with no filler, so nothing is wasteful, but the brevity comes from under-specification rather than tight editing. The required-parameter note is front-loaded well enough for an agent to skim.

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 five parameters, no output schema, and siblings covering overlapping ground, the definition should at minimum describe the shape of the returned player-game statistics and how pagination works. Neither is present, leaving the agent unable to predict results or route 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 only 40%, and the description compensates for none of it: sport's enum, limit's bound, and event_id are undocumented in both places. Saying 'sport and season are required' repeats the schema's required list verbatim and clarifies nothing about the season semantics (starting vs ending year) that the schema does document.

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 restates the title ('Statistics player-games') as 'Independent player-games statistics' without a verb or any explanation of what 'independent' means. It never distinguishes this tool from sibling get_context_player_stats or get_stats_games, so an agent cannot tell which statistics source it should query.

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 only guidance is 'sport and season are required', which merely repeats the schema's required array. There is no indication of when to choose this tool over get_context_player_stats, get_stats_games, or get_stats_team_games, and no mention of when it should not be used.

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 openWorldHint=false, so the safety profile is covered. The description adds nothing beyond that — no explanation of what "independent" statistics mean, how pagination behaves, or what the response contains, leaving a read tool with unknown result shape.

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, front-loaded sentences with no filler, but the brevity comes at the cost of substance rather than being the product of tight editing. Nothing is wasted, but almost nothing is conveyed.

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 read-only stats tool with no output schema and 40% schema coverage, the definition leaves significant gaps: the semantics of "independent," the season-year convention for NFL vs NBA/NHL, and pagination behavior. It is not misleading, but it is thinner than the tool's complexity warrants.

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

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

Schema description coverage is only 40%, yet the description covers just sport and season — both already required by the schema — and says nothing about the season-year convention, event_id, or the after/limit pagination parameters. It therefore fails to compensate for the low 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?

"Independent team-games statistics" gives a resource (team-games statistics) and a vague qualifier ("independent"), but the verb/action is unstated and nothing distinguishes it from siblings like get_stats_games or get_stats_player_games. An agent can guess it returns team-level stats per game, but must open the schema to confirm.

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 only guidance is "sport and season are required," which restates the schema's required list rather than explaining when to choose this tool over get_stats_games, get_context_team_stats, or the other stats siblings. No when-not-to-use condition, no mention of what "independent" excludes.

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 non-open-world, so the safety profile is covered. The description adds one genuinely new behavioral fact — "No key needed", i.e. no authentication required — but says nothing about result shape, ranking, or result limits.

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

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

Two short sentences, the resource scope front-loaded and the auth fact trailing, with no filler. 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 simple single-parameter search this is nearly complete, and the absent output schema means return values needn't be explained. However, the relationship to `fetch` (the obvious follow-up) and any hint about what a result contains are missing, which an agent needs to chain the two 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?

Only one parameter exists, so a baseline of 4 applies. The description adds no syntax guidance for `query` (keywords, operators, quoting) and schema coverage is 0%, though the single string parameter's intent is largely self-evident from the enumerated resource types.

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

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

The description names a specific verb ("Search") and enumerates the resource classes it searches (guides, questions, data reports, integration resources), which is concrete enough to act on. It does not differentiate itself from the sibling `fetch`, leaving the search-vs-fetch split to inference, so it falls short of a 5.

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

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

There is no statement of when to use this tool rather than `fetch` or any of the many get_* context tools, nor any prerequisite or exclusion. The agent must infer that search comes first and fetch retrieves a document.

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