Server Quality Checklist

Tool Scores

• get_player_statsA
  3.6/5.0
  Behavior3/5

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

  With no annotations, the description must carry the behavioral disclosure. It mentions the scope (single player, optional season) and implies read-only access. It does not describe return format, authentication needs, or rate limits, but for a simple stats retrieval tool, coverage is adequate.

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

  Conciseness5/5

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

  The description is extremely concise: one sentence plus a brief usage note. Every word adds value, with no redundancy or extraneous information.

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

  Completeness4/5

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

  For a 2-parameter tool with no output schema, the description covers the essential points: what the tool does, how to use it (player_id source, optional season), and the effect of omitting the season parameter. Minor gap: no mention of return field structure.

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

  Parameters3/5

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

  Schema description coverage is 100%, so the baseline is 3. The description reiterates the season purpose and player_id source but adds no new semantic information beyond what the schema already provides.

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

  Purpose4/5

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

  The description clearly states it returns historical/season statistics for a single player, with verb and resource implied. It links to list_players as a source for player_id, but does not explicitly differentiate from sibling get_player_game_logs, which provides game-by-game data.

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

  Usage Guidelines3/5

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

  The description tells when to use (single player stats, optionally filtered by season) and provides a prerequisite (player id from list_players). However, it does not mention when not to use or alternatives like get_player_game_logs for per-game stats.

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

• get_event_oddsA
  3.8/5.0
  Behavior3/5

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

  No annotations exist, so the description carries full burden. It discloses the output includes devigged fair odds where available, but does not mention error handling, rate limits, or authentication needs. The read-only nature is implicit but not explicit.

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

  Conciseness5/5

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

  The description is a single, information-dense sentence that front-loads the core purpose and then lists output details. No extraneous words or redundancy.

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

  Completeness4/5

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

  With no output schema, the description adequately explains the output structure (row per book x market x selection) and key fields. It omits edge cases or error scenarios, but for a straightforward retrieval tool with one param, it is largely complete.

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

  Parameters3/5

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

  Schema coverage is 100% for the single parameter event_id, which is well-described in both schema and description. The description adds minimal extra value by linking to list_events, but does not provide additional nuance or format details.

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

  Purpose5/5

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

  The description clearly states the tool retrieves every sportsbook price for a single event, specifying the output structure and the source of the event ID. It differentiates from siblings like get_odds or get_event by detailing the granularity and fields.

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

  Usage Guidelines3/5

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

  The description instructs to use an event ID from list_events, but does not provide explicit when-to-use or when-not-to-use guidance relative to sibling tools such as get_odds or get_edges. No comparison 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.

• statusA
  3.9/5.0
  Behavior3/5

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

  With no annotations, the description carries full behavioral disclosure burden. It states the tool returns 'total live markets and number of sportsbooks', but does not mention cost, permissions, update frequency, or whether it is read-only. The description is minimal but adequate for such a simple, parameterless tool.

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

  Conciseness5/5

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

  The description consists of two short sentences with no wasted words. It front-loads the core purpose ('Platform status') and then adds specifics. Every sentence contributes value.

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

  Completeness3/5

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

  Given that the tool has no parameters and no output schema, the description is simple but adequate. However, it lacks details on data freshness (e.g., real-time vs. cached), which would be helpful for a health check tool. It is complete for a minimal tool but could be slightly improved.

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

  Parameters4/5

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

  The input schema has no parameters, so schema description coverage is 100% trivially. The description adds meaning by explaining what the tool returns, which goes beyond the empty schema. It effectively communicates the tool's output without needing parameter details.

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

  Purpose5/5

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

  The description explicitly states that the tool returns 'total live markets and number of sportsbooks currently ingesting', which is a specific verb+resource combination. It clearly distinguishes itself from sibling tools by being a platform-level health check rather than a data retrieval tool.

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

  Usage Guidelines3/5

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

  The description includes the phrase 'a cheap health/coverage check', implying it is lightweight and suitable for quick status verification. However, it does not explicitly state when to use this tool versus alternatives, nor does it provide exclusions or prerequisites. The context suggests it is a meta-tool, but guidance is implicit.

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

• get_arbitrageA
  4/5.0
  Behavior3/5

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

  No annotations are provided, so the description carries the full burden. It discloses that it returns legs with odds and stake fractions, and supports pagination. However, it does not mention authentication requirements, rate limits, or any side effects. This is adequate but not exhaustive.

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

  Conciseness4/5

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

  The description is concise, two sentences with no wasted words. It front-loads the core idea ('Arbitrage scanner') and then lists key features. However, the first sentence is a bit dense; splitting could improve readability slightly.

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

  Completeness3/5

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

  Given no output schema, the description should specify the full return structure. It mentions legs and stake fractions but omits details about the overall response shape, pagination fields, or error handling. While it covers the essentials, it leaves some gaps.

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

  Parameters4/5

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

  Schema coverage is 100%, baseline 3. The description adds value by providing examples (e.g., min_profit as '1 for 1%') and clarifying pagination cursor usage ('pass the nextCursor'). It slightly enhances understanding beyond the schema.

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

  Purpose5/5

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

  The description clearly states the tool's purpose: 'Arbitrage scanner: cross-book opportunities with a guaranteed profit, including each leg...' It distinguishes itself from sibling tools like get_odds or get_event_odds by focusing specifically on arbitrage opportunities.

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

  Usage Guidelines4/5

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

  The description provides clear context on when to use (for scanning arbitrage) and mentions filtering options, but does not explicitly state when not to use or offer alternatives. The context is sufficient for most agents.

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

• get_edgesA
  4/5.0
  Behavior4/5

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

  With no annotations, the description fully informs behavior: it returns edge percentages, fair value source, per-book odds, and pagination. It implies a read-only, filtering operation with no destructive side effects. Clear enough for safe selection.

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

  Conciseness5/5

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

  Single concise sentence that front-loads the core purpose and lists filters efficiently. No superfluous words; every phrase adds value.

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

  Completeness4/5

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

  For a tool with 6 parameters (all described in schema) and no output schema, the description adequately covers what it does and how to use filters. Lacks detail on output format (e.g., sort order) but mentions key returned fields, making it complete enough for most use cases.

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

  Parameters3/5

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

  Schema description coverage is 100%, so the description adds little beyond restating filter options. It lists filter categories but no new semantic details beyond what the schema already provides. Baseline 3 is appropriate.

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

  Purpose5/5

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

  The description clearly states the purpose: 'SportWizzard's edge finder: DFS/book offers that are +EV versus the devigged fair market'. It specifies the verb (find edges), resource (offers), and distinguishes from siblings by focusing on +EV edges rather than raw odds or arbitrage.

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

  Usage Guidelines3/5

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

  The description lists filters (league, source, min edge, event, pagination) implying when to use, but does not explicitly contrast with sibling tools like get_odds or get_arbitrage. No guidance on when not to use or prerequisites.

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

• get_eventA
  4/5.0
  Behavior3/5

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

  With no annotations provided, the description must cover behavioral traits. It lists the returned data but omits details like idempotency, error handling (e.g., invalid event_id), or any mutation effects. The lack of a read-only hint or status code description leaves some ambiguity, but the read nature is implicit.

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

  Conciseness5/5

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

  The description is two concise sentences with no redundant or extraneous information. Front-loaded with the key purpose, it efficiently communicates the tool's function and usage context.

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

  Completeness4/5

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

  Given the tool's simplicity (one required parameter) and the absence of an output schema, the description is nearly complete: it enumerates all major return fields, specifies the input data source, and positions the tool within a workflow. Minor omissions include no mention of error responses or authentication needs, but these are not critical for a contextually adequate description.

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

  Parameters3/5

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

  The input schema already covers the single parameter with a description (event_id: 'Event UUID (from list_events)'). The description reiterates that the event id comes from list_events, which is helpful context but does not add significant new semantics beyond the schema's full coverage (100%).

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

  Purpose5/5

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

  The description explicitly states that the tool retrieves 'full detail for a single event' and lists specific data fields (teams, start time, status, etc.), clearly distinguishing it from sibling tools like list_events (listing) and get_event_odds (odds). The phrasing 'model-builder's pre-game context endpoint' further defines its unique role.

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

  Usage Guidelines4/5

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

  The description provides direct guidance: 'Use an event id from list_events.' This tells the agent the required input source and implies a prerequisite call. It does not explicitly state when not to use this tool, but the context is clear for a single-event detail retrieval scenario.

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

• get_event_statsA
  4/5.0
  Behavior3/5

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

  No annotations provided, so description carries full burden. It discloses return content and applicable event states, but lacks explicit statement about read-only nature or any side effects. Adequate but not comprehensive.

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

  Conciseness5/5

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

  Two sentences, front-loads core purpose, no unnecessary words. Highly efficient.

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

  Completeness4/5

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

  Given no output schema, description explains return content (player stats and team result) and usage prerequisites. Lacks response structure examples but sufficient for a simple tool.

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

  Parameters3/5

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

  Schema covers 100% of parameters with clear description. Description reinforces the source (list_events) but adds no additional format or constraints. Baseline score appropriate.

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

  Purpose5/5

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

  The description clearly states the tool returns 'the box score for a single event' with player stat lines and team-level result, distinguishing it from siblings like get_event (metadata) and get_event_odds (odds).

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

  Usage Guidelines4/5

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

  Explicitly says to use an event ID from list_events and notes it works for final/in-progress events with stats, providing clear context. However, it does not explicitly name alternatives or state when not to use.

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

• get_team_oddsA
  4/5.0
  Behavior3/5

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

  No annotations provided, so description carries full burden. Mentions pagination behavior and input source, but does not disclose read-only nature, rate limits, or error handling. Adequate but not comprehensive.

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

  Conciseness5/5

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

  Two sentences, no wasted words. First sentence states purpose, second gives usage tip. Front-loaded and efficient.

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

  Completeness4/5

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

  For a simple retrieval tool with no output schema, description covers purpose, required parameter source, and pagination. Lacks information on return format or limitations, but adequate for selection and basic usage.

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

  Parameters3/5

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

  Schema coverage is 100%, so baseline is 3. Description adds 'Use a team id from list_teams' and 'Paginate with cursor,' which repeats schema information without adding new meaning. No improvement over schema.

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

  Purpose5/5

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

  Description clearly states 'All current book prices for a single team across its events and markets,' specifying the verb (get implied), resource (prices), and scope (single team, across events and markets). This distinguishes it from siblings like get_event_odds or get_odds.

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

  Usage Guidelines4/5

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

  Provides explicit guidance: 'Use a team id from list_teams' for the required parameter, and 'Paginate with cursor' for pagination. Lacks explicit when-not-to-use or alternatives, but context is clear.

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

• list_teamsA
  4/5.0
  Behavior3/5

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

  With no annotations, the description carries full burden. It discloses filter and pagination behavior but does not explicitly state that the tool is read-only, or mention rate limits, response size caps, or authentication requirements. Some traits are implied but not stated.

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

  Conciseness5/5

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

  Two sentences, each packed with information. No redundant words. Front-loaded with purpose and key features.

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

  Completeness4/5

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

  Given no output schema, the description explains the output (team UUIDs) and how to use them. It covers filtering and pagination. However, it does not describe the full response structure (e.g., fields like team name, logo), which might be inferred from usage with other tools. Overall, sufficient for an agent.

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

  Parameters3/5

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

  Schema description coverage is 100%, so parameters are well-documented in the schema. The description adds 'Filter by league' and 'Paginate with cursor' but does not provide additional meaning beyond what is already in the schema descriptions.

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

  Purpose5/5

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

  The description clearly states it lists teams, emphasizes it's a reference resource, and explains its purpose in relation to other tools (list_events, get_team_odds, get_team_stats). It distinguishes from siblings by specifying the output (team UUIDs) and filtering capability.

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

  Usage Guidelines4/5

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

  Explicitly mentions filtering by league and pagination with cursor. Provides usage context (returns UUIDs for other tools). Does not explicitly state when not to use or list alternatives, but the sibling tools list provides context.

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

• list_eventsA
  4.1/5.0
  Behavior3/5

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

  With no annotations, the description carries full burden. It mentions pagination and result fields but does not disclose traits like rate limits, authentication needs, or that it is a read operation. Fairly straightforward but lacking depth.

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

  Conciseness5/5

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

  Three sentences, front-loaded with purpose, no filler. Every sentence earns its place.

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

  Completeness5/5

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

  For a simple list tool with fully documented parameters, the description covers what the tool returns and how to use the output. No crucial missing information; it is complete enough given the complexity.

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

  Parameters3/5

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

  Schema coverage is 100%, so baseline is 3. The description adds minimal extra meaning beyond grouping parameters ('Filter by league, team, status or start-time window') and mentioning pagination, but does not elaborate on parameter details.

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

  Purpose5/5

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

  The description clearly states 'List sporting events / fixtures' with specific verb and resource, and differentiates itself from siblings like get_event and get_event_odds by positioning as the listing tool that returns IDs for further use.

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

  Usage Guidelines4/5

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

  It explains when to use it ('Filter by league, team, status or start-time window, then use the returned event id with get_event_odds') but does not explicitly state when not to use it or list alternatives. Still, it provides clear context.

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

• get_team_statsA
  4.2/5.0
  Behavior3/5

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

  With no annotations, the description carries the full burden. It indicates a read operation returning stats but does not disclose any potential side effects, auth requirements, rate limits, or whether the query is heavy. The response format is only vaguely described as 'JSON per event' without structure details.

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

  Conciseness5/5

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

  The description is two concise sentences, front-loading the main purpose and usage. No redundant or extraneous information.

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

  Completeness4/5

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

  Given no output schema and two well-documented parameters, the description covers the tool's purpose and data returned at a high level. It could benefit from more detail on the JSON structure, but is sufficient for basic usage.

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

  Parameters4/5

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

  The schema already provides clear descriptions for both parameters. The description adds value by explicitly linking team_id to list_teams and explaining season as optional scoping, though it doesn't add new parameter semantics beyond what the schema offers.

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

  Purpose5/5

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

  The description clearly states the tool returns per-game team stats and results including scores, result, and team stat JSON per event. It distinguishes from sibling tools like list_teams and get_team_odds by specifying the scope and data type.

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

  Usage Guidelines4/5

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

  The description advises using a team ID from list_teams and mentions optional season scoping. It provides context for when to use this tool versus others but does not explicitly state when not to use it or list alternatives.

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

• download_snapshotA
  4.3/5.0
  Behavior4/5

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

  With no annotations, the description effectively discloses key behaviors: saves to disk, handles gzip based on suffix, returns metadata, and supports cheap re-poll via etag. It lacks mention of error handling or permissions but is otherwise transparent.

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

  Conciseness4/5

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

  The description is dense with information but well-structured, front-loading the main purpose. It could be slightly more terse, but every sentence adds value.

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

  Completeness4/5

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

  Given no output schema, the description adequately covers return values (path, byte count, etag). Parameter details are complete. Lacks explicit error scenarios but is sufficient for most use cases.

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

  Parameters4/5

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

  Schema coverage is 100%, and the description adds meaningful context: absolute path requirement, .gz behavior, and etag usage for re-poll. This enhances understanding beyond the schema descriptions.

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

  Purpose5/5

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

  The description clearly states 'Download the FULL live board' and specifies the resource (every market from every sportsbook). It distinguishes from siblings by emphasizing the full download to disk, unlike other tools that return subsets or lists.

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

  Usage Guidelines4/5

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

  The description explains when to use (need full board, large data) and how to re-poll with etag. However, it does not explicitly state when not to use or list alternative tools for smaller queries.

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

• list_sportsbooksA
  4.3/5.0
  Behavior3/5

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

  No annotations provided; description implies read-only listing. Mentions 'live market count', but no details on data freshness, rate limits, or side effects. Adequate but minimal.

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

  Conciseness5/5

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

  Two concise sentences, no filler. Purpose, output, and usage guidance front-loaded.

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

  Completeness5/5

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

  For a zero-parameter list tool with no output schema, the description fully covers purpose, output, and usage context.

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

  Parameters4/5

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

  No parameters defined, so baseline 4. Description adds nothing extra, but none needed.

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

  Purpose5/5

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

  Clearly states it lists sportsbooks/DFS platforms with live market counts and serves as reference/discovery. Differentiates from sibling list tools by specific resource.

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

  Usage Guidelines4/5

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

  Explicitly says to call this to learn valid `sportsbook` filter values, indicating when to use. Does not mention when not to use, but context is clear.

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

• get_account_usageA
  4.4/5.0
  Behavior4/5

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

  No annotations, but description discloses read-only nature and exactly what data is returned (plan, rate, usage). No mention of rate limit impact on own usage, but sufficient for a info tool.

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

  Conciseness5/5

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

  Two sentences, front-loaded with key info, minimal wasted words.

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

  Completeness4/5

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

  Given no parameters and no output schema, description adequately covers purpose and usage. Could elaborate on response format, but not essential for usability.

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

  Parameters4/5

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

  No parameters needed; baseline 4. Description explains what the tool returns, compensating for the lack of output schema.

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

  Purpose5/5

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

  Clearly states the tool returns API plan and usage details, including plan tier, rate limit, and monthly cap. Distinguishes from sibling tools focused on sports data.

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

  Usage Guidelines4/5

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

  Explicitly notes it works without a key, showing anonymous plan. Provides useful context but could more directly state when to use it versus checking other resources.

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

• get_oddsA
  4.4/5.0
  Behavior3/5

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

  No annotations exist, so the description carries the full burden. It discloses pagination behavior (hard when unscoped) and that it returns a flat array. However, it does not mention whether the operation is read-only, authentication needs, rate limits, or data freshness. For a query tool, these are useful but not critical gaps.

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

  Conciseness5/5

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

  Three sentences, each with a clear purpose: what it does, usage warning, pagination instruction. No redundant words. Front-loaded with the core purpose.

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

  Completeness4/5

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

  No output schema, so the description must convey what is returned. It says 'flat array of book prices' but doesn't detail the fields in each price object. However, the scoping and pagination are well covered, and the tool is core enough that users can infer the structure from context. Minor gap.

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

  Parameters4/5

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

  Schema coverage is 100%, so baseline is 3. The description adds value by explaining the concept of 'scoping' and warning about unscoped calls, which goes beyond the parameter descriptions in the schema. It also references related list tools (list_markets, etc.) for valid values.

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

  Purpose5/5

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

  The description clearly states it returns 'a flat array of book prices' and lists the scoping dimensions (event_id, player_id, etc.). It distinguishes from siblings like get_event_odds by being more general. The verb 'returns' and resource 'book prices' are specific.

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

  Usage Guidelines5/5

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

  Explicit guidance is given: 'prefer scoping to at least one entity' to avoid hard pagination, and 'Paginate with cursor' with reference to nextCursor. This tells when and how to use the tool effectively.

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

• get_player_game_logsA
  4.4/5.0
  Behavior4/5

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

  With no annotations, the description carries full burden. It explains output structure ('Each row is one player-game with the raw stat JSON') and pagination mechanism. Does not mention performance implications or authentication needs, but is adequate.

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

  Conciseness5/5

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

  Two sentences, front-loaded with purpose. Every sentence provides essential information: purpose, filtering requirement, row structure, and pagination. No waste.

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

  Completeness4/5

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

  No output schema, so description must cover return format. It does so adequately with 'raw stat JSON' and row count. Could elaborate on stat fields, but given tool complexity, this is sufficient. Pagination and filtering constraints are covered.

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

  Parameters4/5

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

  Schema coverage is 100%, but description adds significant value: the requirement that at least one filter be provided (not present in schema), default limit behavior, and pagination cursor explanation. This goes beyond schema rephrasing.

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

  Purpose5/5

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

  The description clearly states it provides 'Bulk per-game player stat rows (game logs)' filtered by player, team, or event. It distinguishes from sibling tools like get_player_stats (likely aggregated) by emphasizing per-game and raw stat JSON.

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

  Usage Guidelines4/5

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

  States required filter constraint ('At least one of player_id / team_id / event_id is required') but does not explicitly mention when not to use or suggest alternative tools. However, the context of sibling tools is clear.

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

• get_player_oddsA
  4.4/5.0
  Behavior4/5

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

  No annotations are provided, so the description must convey behavioral traits. It describes the tool as returning 'current book prices' and mentions pagination, implying a read operation. It does not discuss permissions, rate limits, or response format, but given the simplicity, this is acceptable.

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

  Conciseness5/5

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

  Two short, focused sentences. No unnecessary words. Front-loaded with purpose.

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

  Completeness4/5

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

  For a simple read tool with 3 parameters and no output schema, the description covers the purpose, required input (player_id), and pagination. It is complete enough for an agent to select and invoke correctly.

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

  Parameters4/5

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

  Schema coverage is 100% with descriptions. The description adds value by clarifying that player_id comes from list_players and that cursor enables pagination, reinforcing the schema.

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

  Purpose5/5

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

  The description clearly states it returns 'All current book prices for a single player across events and markets (player props).' This distinguishes it from sibling tools like get_event_odds (focused on events) and get_team_odds (team-focused).

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

  Usage Guidelines4/5

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

  Provides a prerequisite: 'Use a player id from list_players.' and mentions pagination with cursor. However, it does not explicitly state when to use this tool over alternatives or when not to use it.

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

• list_marketsA
  4.4/5.0
  Behavior4/5

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

  No annotations provided, but the description accurately reflects a read-only list operation with no side effects. It does not disclose potential rate limits or data staleness, but for a simple discovery tool this is sufficient.

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

  Conciseness5/5

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

  Two sentences, no fluff. First sentence states functionality, second adds immediate usage guidance. Perfectly concise and front-loaded.

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

  Completeness5/5

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

  Given no parameters and no output schema, the description fully explains the tool's purpose and the nature of its output (market types with counts). It is complete for a simple discovery tool.

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

  Parameters5/5

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

  No parameters exist, so the description adds full value by explaining the tool's output purpose (learning valid market filter values). The schema provides no parameter info, and the description compensates excellently.

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

  Purpose4/5

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

  The description clearly states the tool lists market types with live counts and serves as a discovery reference. It distinguishes from sibling tools like list_events or get_odds, but could be slightly more specific about what constitutes a 'market type'.

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

  Usage Guidelines4/5

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

  Explicitly frames the tool as a reference/discovery tool for learning valid `market` filter values, giving clear context for when to use it. Does not explicitly mention when not to use, but it's implicitly understood.

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

• list_playersA
  4.4/5.0
  Behavior4/5

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

  No annotations are provided, so the description carries the full burden. It discloses the tool's read-only nature (reference resource), filtering, and pagination behavior. It does not cover rate limits or authorization, but the basic behavior is transparent.

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

  Conciseness5/5

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

  The description is extremely concise at two sentences, front-loaded with the core purpose. Every word adds value, with no redundancy. It efficiently communicates purpose, filtering, output usage, and pagination.

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

  Completeness4/5

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

  Given the lack of output schema and annotations, the description adequately covers the tool's purpose, usage, and pagination. It could mention the response format or default behavior without filters, but it is otherwise complete for a simple list tool.

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

  Parameters4/5

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

  Schema coverage is 100% (baseline 3), but the description adds value by explaining that the tool returns player UUIDs for use with other tools, and that pagination is via cursor. It also contextualizes the filter parameters as optional and combinable.

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

  Purpose5/5

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

  The description clearly states the verb 'List' and resource 'players', and specifies it's a reference resource for obtaining player UUIDs to use with get_player_odds and get_player_stats. This distinguishes it from sibling tools that return odds, stats, or other data.

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

  Usage Guidelines4/5

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

  The description explicitly states when to use this tool: to filter players by league/team and get UUIDs for other player-related tools. It mentions pagination via cursor. However, it does not explicitly say when not to use it, but the context of sibling tools implies its specific role.

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

• list_leaguesA
  4.5/5.0
  Behavior4/5

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

  The description adequately conveys that the tool performs a read-only listing operation. With no annotations provided, it carries the full burden and does so effectively, though it does not detail potential side effects (none expected).

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

  Conciseness5/5

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

  Two concise sentences that front-load the purpose and provide immediate usage guidance. No wasted words.

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

  Completeness5/5

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

  For a simple, no-parameter tool without an output schema, the description is complete. It explains what the tool does and how to use it.

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

  Parameters4/5

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

  The input schema has zero parameters, so the description adds value by explaining the output's purpose. Baseline for 0 parameters is 4.

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

  Purpose5/5

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

  The description clearly states the tool lists leagues with live markets and serves as a reference to learn valid league filter values. This is specific and distinguishes it from sibling tools like list_events or list_sportsbooks.

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

  Usage Guidelines4/5

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

  The description explicitly indicates when to use the tool: 'Reference/discovery — call this to learn valid league filter values.' This provides clear context but does not explicitly mention when not to use it or alternatives.

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