Lumify Sports Intelligence

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

Annotations already mark this read-only, idempotent, and non-destructive. The description adds valuable behavioral detail beyond that: a 25-id max, full detail for existing ids plus a not_found list, and that missing ids are never billed. This extra operational context helps an agent predict side effects and cost.

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

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

Three dense sentences carry the primary purpose, constraints, billing behavior, output shape, and sibling routing. Every sentence earns its place, and the most decision-relevant information is front-loaded.

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

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

For a batch-read tool with a rich output schema and annotations, the description covers everything needed to invoke it correctly: when to use it, max batch size, return behavior, and which sibling to use instead. No critical context is missing.

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

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

Schema description coverage is 100%, so the schema fully documents event_ids, bookmaker, include_odds, and include_intelligence. The description adds the high-level batching/billing behavior but no per-parameter details beyond what the schema already provides, so the baseline 3 applies.

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

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

Description leads with a specific verb-resource pair ('Get multiple events by id in one call') and clearly distinguishes the batch operation from its single-id sibling get_event. It names the intended use case (agents that already have ids and want full detail) without ambiguity.

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

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

The description explicitly states when to use this tool: when the agent already has a list of ids and wants full detail without per-event calls. It also names alternatives and the routing condition: use get_event for a single id, or list_events / query_events to discover ids first.

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

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

Beyond the annotations (readOnlyHint, idempotentHint, destructiveHint), the description adds valuable behavioral detail: no credits are spent, results are a [min_credits, max_credits] range, costs are data-dependent, and specific free-call cases are given. This goes well beyond the structured safety hints and enriches the agent's mental model.

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

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

Three sentences accomplish all goals: purpose, behavior, and usage example. Nothing is redundant; every sentence carries essential information. The structure is front-loaded with the core function and then elaborates with context and a concrete example.

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

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

Given the tool's moderate complexity (array input, max 50 items) and the presence of an output schema, the description fully covers what an agent needs to invoke it correctly: the input format, the output format (range), and special cost edge cases. No critical information is missing.

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

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

With 0% schema description coverage, the description fully compensates by explaining the required 'calls' array structure, the 'tool' and 'arguments' fields, and providing a concrete JSON example. The agent knows exactly what to pass without needing to infer from a bare schema.

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

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

The description opens with a specific verb ('Estimate') and resource ('credit cost of planned tool calls'), making it unmistakable. It explicitly states 'before making them' and 'no credits are spent,' distinguishing it from all sibling tools that actually fetch data. This is a model of clear purpose differentiation.

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 clearly conveys when to use the tool (before executing calls, to estimate cost) and provides a usage example. However, it does not explicitly state when not to use it or name alternatives. The context makes the use case obvious, but explicit exclusion guidance is missing.

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

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

Annotations already declare readOnlyHint, openWorldHint, idempotentHint, and destructiveHint=false, so the safety profile is covered. The description adds value beyond that by disclosing the not-found error behavior for invalid event_id and the credit/pricing behavior (1 credit, inlining adds no credits).

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

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

Three sentences, front-loaded with the core purpose and covering scope, error behavior, and routing in a tight order. Minor redundancy: the 'does not add credits' information is repeated in both the description and the parameter schema, and the phrase 'same 1 credit as the event call' is slightly awkward since this tool is itself the event call.

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 a rich output schema, full param coverage, and safety annotations, the description covers the main operational details: high-level return contents, error behavior, id discovery, and batch alternative. A small gap is that it doesn't disambiguate when to inline odds/intelligence here versus calling sibling tools get_odds or get_intelligence directly.

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

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

Schema description coverage is 100%: event_id provenance, bookmaker defaults/valid values, and include_odds/include_intelligence credit behavior are all in the schema. The description mostly restates the credit aspect already present in the parameter descriptions, adding little new param meaning, so the baseline 3 applies.

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

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

The description opens with a specific verb+resource statement ('Get a single event with participants and venue') and marks this as the single-item variant, which distinguishes it from sibling batch_get_events. The optional inlining of odds and intelligence is also stated clearly.

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

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

Explicit guidance is provided: use list_events / query_events to discover event ids first, and use batch_get_events for fetching several ids in one call. This names the alternatives and the conditions that select them, leaving nothing to inference.

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

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

Even with annotations already marking readOnly/openWorld/idempotent, the description adds substantial behavioral detail: beta status, league coverage windows, the 'no charge' behavior before a first structured report, polling triggers, the absence of an in-game feed, and the non-effect of exclude_status on availability or credit. This goes well beyond the annotations.

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

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

The description is dense but every sentence contributes operational knowledge an agent needs. It is front-loaded with the primary purpose and then efficiently covers coverage, timing, webhooks, and parameter behavior without redundancy.

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

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

The description is exceptionally complete for a complex data tool: it covers availability semantics, timing, charge behavior, update triggers, webhook subscription, limitations, and parameter nuances. The presence of an output schema means return-value documentation is handled elsewhere, so no essential calling context is missing.

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

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

Schema coverage is 100%, so the schema already documents both parameters. The description adds extra semantic value for exclude_status, explaining its purpose as dropping noisy long-standing designations and clarifying that it does not affect availability or credit, which is not evident from the schema alone.

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

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

The description clearly states the tool's function: 'Get late-breaking player injury and availability status for an event,' naming a specific verb, resource, and scope. It also enumerates the specific statuses and fields returned, and it is clearly distinct from sibling tools like get_event or get_player because it targets injury intelligence.

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

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

The description provides strong contextual guidance: Beta coverage is limited to NFL and MLB, with specific monitoring windows and cadence. It also explains when the tool may return 'available:false' and directs users to webhooks for material/critical changes, though it does not explicitly contrast with alternative tools since no direct sibling exists.

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

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

The description adds substantial behavioral context beyond the readOnlyHint/idempotentHint annotations: bookmaker is ignored, match-level tokens have null player/team attribution, edge/tier are null, has_recommend is false, and forecasts[] can populate when available is false. These are the exact caveats an agent needs to interpret results correctly, and nothing contradicts the annotations.

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

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

The description is dense but information-dense: every clause covers a meaningful scope, caveat, or field behavior. It is not as cleanly structured as a bulleted field list, and it repeats bookmaker being ignored from the schema, but the complexity of the tool warrants most of the length.

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

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

The description covers the core purpose, live sports coverage, forecast coverage, attribution null cases, pricing caveats, and even points to a field catalog link. Given the tool's complexity, an agent has enough context to invoke it correctly and interpret the response.

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

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

The input schema already documents both parameters at 100% coverage; event_id includes its source and bookmaker already states it is ignored with the valid values listed. The description adds little beyond the schema, so the schema-heavy baseline of 3 is appropriate.

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

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

The description opens with a specific verb and resource: 'Get predictive bet intelligence for an event,' and then enumerates the concrete fields returned, such as vig-stripped probability, fair_price, and forecasts[]. It clearly distinguishes this tool from siblings like list_forecasts and get_event by describing its unique composite payload and by stating that bookmaker is ignored.

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

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

The description gives strong contextual guidance about when the tool is relevant: it supports specific sports for bets[] and forecasts[] and even states a condition for free access ('Free only when available is false and forecasts is empty'). It does not explicitly say 'use list_forecasts instead of this tool when...', so it stops just short of fully spelled-out when-not alternatives.

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

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

Annotations already declare readOnlyHint and idempotentHint, but the description adds valuable context: 'Cheaper and faster' performance expectations and the 'not-found error' behavior. It also clarifies the lightweight nature and what fields are included, exceeding the structured metadata's coverage.

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

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

Two sentences, front-loaded with the main purpose, followed by usage and error info. Every sentence adds distinct value with no redundancy, making it highly efficient.

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

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

For a single-parameter tool with output schema and strong annotations, the description covers purpose, usage, alternatives, and error behavior. It is complete and self-contained for an agent to correctly invoke the 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?

The schema provides 100% coverage for the single parameter event_id with a clear origin ('from list_events, query_events, or search results'). The description adds no new parameter-level semantics beyond what the schema already states, so the baseline of 3 applies.

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

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

The description uses a specific verb ('Get a lightweight live score snapshot') with a clear resource ('an event') and enumerates exact contents (status, period, clock, scores, last-updated). It also distinguishes from sibling get_event by highlighting the scope difference, making its purpose unambiguous.

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

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

The description explicitly states when to use this tool instead of get_event ('when you only need the score, not participants or venue') and notes the error condition for a non-existent event_id. This provides clear decision guidance relative to alternatives.

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

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

Annotations already mark this as read-only, open-world, idempotent, and non-destructive. The description adds substantial behavioral context beyond that: books with no recent quote are omitted, unavailable events return available:false with no charge, fallback bookmaker behavior is explained, and the result grading from pre-kickoff close is disclosed. No contradiction exists.

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

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

Every sentence in the description carries operational information an agent needs: defaults, fallbacks, charge behavior, availability semantics, and sibling routing. Though the paragraph is dense, it is appropriately sized for the tool's complexity and front-loads the core purpose before edge cases.

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

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

Given the tool's complexity and the presence of an output schema, the description covers all critical contextual gaps: live-event behavior, missing-odds handling, fallback selection rules, alternate markets, result grading, and fair_price availability. An agent selecting or invoking this tool has enough information to predict behavior across edge cases.

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

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

Schema coverage is 100%, so the baseline is already strong. The description goes much further by explaining default values ('bookmaker defaults to pinnacle'), the special 'all' and comma-separated syntax, the 1-credit guarantee across multiple books, and the interaction between include_alts and main lines. This adds meaning well beyond the raw parameter descriptions.

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

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

The description opens with a specific verb and resource: 'Get current betting odds for an event,' followed by the key outputs (per-bookmaker lines, last-updated time). It clearly differentiates from the sibling get_odds_history by explicitly routing line-movement queries there.

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

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

The description gives explicit when-to-use guidance, including behaviors for live events, post-event grading, unavailable odds, and fallback selection. It names get_odds_history as the alternative for line movement over time, making the choice between siblings unambiguous.

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 as a safe, read-only, idempotent operation. The description adds behavioral context by specifying that it returns a list of past snapshots, each with a timestamp, capped by the limit parameter, and noting the default bookmaker. This is useful context beyond the structured annotations.

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

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

The description is compact and front-loaded: it states the core purpose first, then important defaults, then the alternative tool. Every sentence earns its place and there is no redundant 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 a full input schema, explicit annotations, and an output schema, the description provides enough context for correct invocation. It covers the operation, the result shape, the limit behavior, the default bookmaker, and when to use a sibling tool instead.

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

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

Schema description coverage is 100%, so the schema fully documents event_id, limit, and bookmaker. The description reinforces the meaning of limit ('up to limit entries') and mentions the bookmaker default, but it does not add substantial meaning beyond the schema.

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

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

The description clearly states the tool's function: retrieving line-movement history for an event, i.e. past odds snapshots with timestamps. It explicitly distinguishes itself from get_odds, which returns only the current line, making the tool's purpose unambiguous.

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

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

The description explicitly names the alternative get_odds and gives the condition for choosing it instead: 'Use get_odds instead if you only need the current line.' This gives the agent clear routing guidance.

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

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

Annotations already mark the tool as read-only/idempotent/non-destructive, and the description adds meaningful behavior beyond that: it joins persisted period mains to live scores, grades the period rather than the full game, explains the no-charge available:false state, and documents the HTTP 400 restriction. No contradiction with annotations.

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

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

Every sentence earns its place and the main purpose is front-loaded. The description is somewhat dense and the phrase 'GET /odds / get_odds' is slightly awkward, but overall it is efficiently structured for the amount of domain nuance it conveys.

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

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

Given the complexity of period definitions and sport-specific rules, the description is remarkably complete. It covers supported sports, how period scores are computed, the difference from full-game grades, the no-charge empty state, and the error case. With an output schema present, nothing essential is missing.

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

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

The schema has 100% coverage for the single required parameter, event_id, and already explains where it comes from. The description does not add parameter-specific detail, but the schema carries the full burden, so the baseline of 3 is appropriate.

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

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

The description states a specific verb ('Get'), a specific resource ('first-half / first-five / first-set lines and live progress'), and the sports covered. It explicitly distinguishes itself from get_odds, which stays on moneyline/spread/total, so an agent can immediately tell what this tool is for.

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

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

The description says when to use this tool: when period-specific lines/progress are needed, not full-game odds. It names the alternative (GET /odds / get_odds) and gives exclusion signals such as 'Other sports return HTTP 400' and 'available:false with no charge if no period mains have been ingested.'

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

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

Beyond the annotations (readOnly, idempotent, non-destructive), the description discloses important runtime behavior: it raises a not-found error for invalid player_id, and it explains null semantics for rankings on non-tennis sports and image_url before enrichment. This gives the agent accurate expectations for edge cases and return values.

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 information-dense but well-structured and front-loaded. Every sentence earns its place: the first defines the tool and its output fields, the second states error behavior, and the third gives id resolution guidance. There is no redundant or filler content.

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

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

Given the single required parameter, a high-coverage schema, an output schema, and strong annotations, the description is complete. It covers the return payload's special cases, the error case, and how to obtain a valid player_id. An agent has everything needed to call this tool correctly.

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

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

The input schema already documents player_id with 100% coverage, including 'from search_players.' The description reinforces this by saying 'Resolve ids via search_players,' but it does not add meaningful new parameter semantics beyond what the schema provides. The error behavior is useful context but is more behavioral than parameter-specific.

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

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

The description states a specific verb and resource: 'Get a single player identity profile', then enumerates the fields returned (name, sport, country, position/handedness, physical stats, current team, rankings, image_url). It clearly distinguishes from siblings like get_team, get_player_events, and get_player_props by scoping the tool to identity/profile data rather than events, odds, or props.

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

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

The description provides clear context for when to use this tool: to retrieve a single player's identity profile, and it explicitly routes id resolution via search_players. It does not explicitly state when not to use it or name alternatives for events/props, but the profile-scoped wording and the mention of search_players provide adequate 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 indicate read-only and idempotent. The description adds useful behavioral details: pagination by after_id and the default ±30-day date window when no filter is provided. No contradictions with annotations.

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

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

Two concise sentences, front-loaded with the core action. Every clause adds value: scope, pagination, default window, and prerequisite. Zero waste.

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 a full output schema and rich annotations, the description doesn't need to detail return format or safety. It covers core behavior, pagination, defaults, and the player_id prerequisite, making it complete for the tool's complexity.

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

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

Schema descriptions cover 100% of parameters, including player_id origin and after_id cursor semantics. The description reiterates these but doesn't add substantially new parameter-level information beyond connecting the pagination flow.

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

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

The description clearly states it lists a player's events, with 'player's' distinguishing it from broader event tools. The parenthetical (schedule/results) and pagination mention add specificity. This is a specific verb+resource+scope, meeting the top criteria.

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

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

Provides clear context: it's for retrieving a specific player's events, and instructs to resolve player_id via search_players first. However, it does not explicitly contrast with alternative event-listing tools like list_events or query_events, so it lacks explicit exclusions or alternatives.

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

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

Annotations already signal read-only and idempotent behavior, but the description adds substantial non-obvious context: joining persisted prop mains to box counts, grading various prop types, returning available:false without charge when no prop mains exist, and rejecting unsupported sports. Nothing contradicts the annotations.

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

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

The description is dense but every clause earns its place: sports scope, output contents, prop types covered, sibling distinction, no-charge behavior, and error handling are all stated with no filler or repetition.

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

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

An agent has enough information to call the tool correctly: which sports/events are valid, what categories of props are graded, when not to expect results, and which sibling tools to use instead. The presence of an output schema covers return structure, so nothing essential is missing.

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

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

The schema already fully documents event_id, including its source from list_events, query_events, or search results. The description adds useful sport-level context but does not materially extend the meaning of the single parameter beyond the schema.

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

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

States a specific verb and resource: retrieving player-prop lines and live progress, and enumerates the supported sports. It also differentiates itself from get_odds by explicitly saying that odds tools stay on moneyline/spread/total.

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?

Names the alternative tool category (GET /odds / get_odds) and clarifies that those tools cover moneyline/spread/total, making the selection boundary clear. It also explains the no-charge available:false case and the HTTP 400 behavior for unsupported sports.

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

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

Annotations already mark the operation readOnly, idempotent, and non-destructive, and the description adds meaningful behavior beyond that: persist-then-read semantics, data sources, the no-charge available:false return on missing rows, HTTP 400 for other sports, and its nature as a price-input read rather than a trading product. This is rich, honest behavioral disclosure.

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

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

The description is front-loaded with the core purpose and then delivers dense, non-redundant guidance: source providers, price format, contract scope, empty-result behavior, error behavior, and product positioning. Every sentence earns its place without fluff.

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

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

For a single-parameter tool with an output schema and strong annotations, the description is fully sufficient. It covers sports coverage, data sources, price semantics, contract restrictions, no-data behavior, and error conditions, leaving no caller-relevant ambiguity.

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 only parameter, event_id, is already fully documented in the schema with its source (list_events, query_events, or search results), and schema coverage is 100%. The description adds no additional parameter-level semantics because none are needed, so the baseline 3 applies.

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

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

The description opens with a specific verb-resource pair ('Get prediction-market game-line probabilities') and enumerates the supported sports, making the tool's purpose immediately identifiable. It also actively distinguishes itself from get_odds / GET /odds by stating it returns implied probabilities, not American odds, which separates it clearly from siblings.

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

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

The description gives clear context for when this tool applies: prediction-market game-line contracts for specific sports, with explicit exclusions for non-game-line contracts and unsupported sports. It references get_odds as a different surface, but it does not explicitly say 'use X instead' for the alternatives, which keeps it just short of a 5.

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

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

Annotations already cover readOnly, openWorld, idempotent, and non-destructive behavior. The description adds valuable detail beyond that: no charge when splits are unavailable, upstream 400 errors for unsupported sports, and the bookmaker slug mapping convention relative to get_odds.

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

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

The description is dense and front-loaded with the core purpose, followed by availability and fallback behavior. The first sentence is long with parentheticals, but every part earns its place; it could be slightly restructured for readability without losing content.

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

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

For a one-parameter read-only tool with an output schema, the description is complete: it states what is returned, which sports are supported, when no data is available, and the billing behavior. No critical calling context is missing.

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

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

The schema fully covers the only required parameter, event_id, with guidance to source it from list_events, query_events, or search results. The description does not add extra parameter-level meaning beyond what the schema already provides, so the baseline of 3 applies.

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

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

The description begins with a specific verb and resource: 'Get public betting splits (bets% and handle%) for an event'. It clearly distinguishes the tool from siblings like get_odds by describing the exact data returned: consensus split, per-bookmaker breakdown, and captured_at timestamp.

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

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

The description provides clear usage context by listing supported sports (MLB, NBA, NHL, NFL, NCAAF, NCAAB) and explicitly stating tennis and soccer are not available. It also explains when the tool returns available:false, but it does not name an alternative tool or explicitly say when to prefer get_splits over get_odds.

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

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

Annotations declare safety (readOnly, openWorld, idempotent) but the description adds rich behavioral detail beyond them: sport-specific payload shape, tennis doubles/qualifying returning available:false, exclusions from form/record/H2H, and HTTP 400 behavior. This materially improves an agent's understanding of what to expect when calling the tool.

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

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

The description packs critical usage information into three tightly written sentences, front-loading the core purpose and differentiating siblings first. Every sentence earns its place; there is zero fluff or repetition.

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

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

Given the tool's moderate complexity, the description covers supported sports, payload structure, edge-case availability, statistical exclusions, and error handling. Combined with annotations and output schema, an agent has everything needed to invoke this tool correctly without additional context.

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

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

The only parameter, event_id, is fully described in the schema (coverage 100%) with a clear source and type. The description adds no extra parameter-level meaning, but the baseline of 3 applies because the schema already carries the necessary semantic weight.

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

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

The description states a specific verb ('Get'), a clear resource ('raw, deterministic team/match statistics'), and enumerates supported sports, explicitly distinguishing it from siblings by excluding odds and scoring. This makes the tool's purpose unmistakable and differentiates it from get_odds and get_intelligence.

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

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

The description explicitly tells when to use this tool (raw statistics) and when not to, naming alternatives: 'no odds (use get_odds) and no scoring (use get_intelligence)'. It also provides error conditions (HTTP 400 for unsupported sports), leaving no ambiguity about selection.

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

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

Annotations already signal read-only, idempotent, non-destructive behavior. The description adds value by disclosing the not-found error behavior for invalid team_id, which the annotations do not cover, and notes the return includes home venue.

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

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

Three short sentences, each carrying distinct information: purpose, error behavior, and id resolution. No filler or repetition of annotation fields.

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 one required parameter, a full output schema, and strong annotations, the description covers the essential call pattern and failure mode. Nothing needed to invoke correctly is missing.

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

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

The schema already documents team_id as an id from list_teams, so the baseline is 3. The description adds meaning by warning that a nonexistent team_id triggers an error and reinforces the resolution path, going slightly beyond the schema.

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

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

The description uses the specific verb 'Get' with the resource 'single team profile' and adds 'with its home venue' to define scope. It contrasts with list_teams by indicating a single team, and the explicit mention of list_teams helps disambiguate from that sibling.

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

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

The description gives a clear prerequisite sequence: resolve ids via list_teams before calling get_team. It implies use when a single team profile or home venue is needed, though it does not enumerate exclusions like team props or stats.

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 read-only, idempotent, and non-destructive behavior. The description adds meaningful operational context: joining persisted Pinnacle team-total mains to live scores, grading over/under/push, and no-charge behavior when data is unavailable. This goes well beyond the annotations without contradicting them.

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 four tightly packed sentences with no filler. The main action is front-loaded, and every clause adds new information: supported sports, data join logic, sibling differentiation, and edge-case behavior.

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

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

With an output schema present and only one well-documented parameter, the description covers all essential selection and invocation context. It includes sport restrictions, no-data behavior, and the relationship to get_odds, so nothing critical is missing.

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

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

The only parameter, event_id, is already fully described in the schema with sourcing guidance ('from list_events, query_events, or search results'). The description's supported-sport scope is useful but does not add parameter-level mechanics, so the high schema coverage baseline of 3 is appropriate.

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

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

The description names a specific resource ('team-total lines and live progress') and scopes it to NFL, NCAAF, MLB, and soccer events. It explicitly contrasts with get_odds's moneyline/spread/total scope, so an agent can distinguish it from siblings.

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

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

It states when to use this tool for team-total props and indicates that GET /odds and get_odds cover moneyline/spread/total instead. It also gives practical fallback/edge behavior: available:false with no charge when no team-total mains exist, and HTTP 400 for unsupported sports.

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

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

Annotations already indicate readOnly, idempotent, and non-destructive behavior. The description adds substantial context beyond that: the tool costs 1 credit, is in Beta, sorts by ev_pct, suppresses MLB moneyline null books, skips to the next eligible book, applies sharp-fair price gates, and returns 400 for tennis totals.

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

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

The description is dense but well-organized, front-loading the core purpose and then adding constraints, gates, cost, and a reference link. Every sentence earns its place; there is no filler.

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

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

With an output schema present, the description does not need to explain return values. It covers supported sports, market families, default behavior, edge cases, EV gates, cost, and links to the full field catalog, making it fully actionable for an agent.

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

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

Schema description coverage is 100%, so the baseline is 3. The description goes beyond the schema by explaining the market default, the tennis totals 400 error, the MLB null-book behavior, and the soccer league scanning behavior, adding useful semantics for parameter selection.

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

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

The description clearly states the tool lists pregame main-line +EV opportunities, names the supported sports, and specifies sorting by ev_pct descending. It also differentiates the tool from siblings by mentioning market families and the tennis totals exclusion.

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

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

The description gives clear context for when to use the tool: it is for pregame +EV opportunities, not live events, and it specifies market defaults and unsupported combinations. It references get_intelligence for the shared EV gates, which helps an agent relate the tool to a sibling, though it does not explicitly say 'use this instead of X'.

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

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

Annotations already declare readOnlyHint, openWorldHint, idempotentHint, and destructiveHint=false. The description adds valuable behavioral context beyond those: pagination via after_id, include_scores inlining scores only for small result sets, and the specific event fields returned. This is richer than a minimal read-only list description, though it does not discuss rate limits or authorization.

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

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

The description is a single dense paragraph with no filler. It front-loads the core purpose and pagination model, then efficiently conveys filters, return fields, the include_scores caveat, and alternatives. Every sentence contributes actionable 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 13-parameter list tool, the description covers pagination, filters, return representation, the small-result-set caveat, and alternative tools. The output schema exists, so returning full field details is not required, but the description still summarizes key fields. Nothing an agent needs to call this tool correctly is missing.

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

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

Schema description coverage is 100%, so the baseline is 3. The description adds extra meaning by grouping parameters (sport, league, status, date range, season, team_id), explaining that team_id is resolved via list_teams / get_team, and clarifying the include_scores behavior for small result sets. This goes beyond the schema's individual parameter descriptions.

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

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

The description opens with a specific verb and resource: 'List events (schedules and live scores), paginated by id (after_id).' It clearly identifies the tool as a paginated list operation and differentiates it from siblings by naming get_event and query_events as alternatives with distinct purposes.

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

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

The description explicitly states when to use alternatives: 'use get_event for one event's full detail, or query_events for free-text/natural-language filters instead of structured params.' It also gives guidance on resolving teams via list_teams / get_team and warns that include_scores is 'intended for small result sets,' providing clear when/when-not context.

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

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

Annotations already mark it read-only and idempotent, but the description adds meaningful behavioral context: this is a prediction model not a beat-the-market claim, reliability is emerging, credit cost is disclosed, and the 'empty slate is still 200' quirk is noted. All this goes beyond the annotation hints and clarifies expectations.

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

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

The description is dense but each sentence earns its place: the core differentiation is front-loaded, sport-specific caveats are grouped, and supporting links are at the end. Slightly long, but no wasted words given the complexity.

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?

Considering the tool's complexity (multi-sport, multiple models, market nuances), the description covers the essential context: what the forecast represents, field semantics (p_hit, conviction), limitations (no OOS gate, soft-book lines), and pointers for further details. An output schema exists, so return values don't need elaboration here.

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

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

The input schema already provides 100% description coverage for all four parameters, including enums and defaults. The description adds supplemental context for sport and market (e.g., tennis's three market families), but it does not redefine parameter semantics beyond the schema. Baseline 3 is appropriate.

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

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

The description states a specific purpose: 'Daily board of forecasted wagers from Lumify's model' and explicitly contrasts with list_ev ('use this tool to scan high-probability forecasts'). It clearly identifies the resource and what makes it distinct from the sibling tool.

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?

Direct guidance is given: 'Use list_ev to scan main lines by sharp-fair price gap; use this tool to scan high-probability forecasts.' It also clarifies scope across sports and market types, including caveats like tennis-specific behavior, leaving no ambiguity about when to invoke this tool.

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

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

Annotations already cover safety (read-only, idempotent, non-destructive), and the description adds meaningful behavior: default active-only filtering, optional historical inclusion, and return field details. It does not contradict annotations and provides useful context beyond structured fields.

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

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

Four short sentences, front-loaded with the core purpose, then defaults, return fields, and an alternative. Every sentence earns its place with no filler or redundancy.

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

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

For a simple read-only list tool with an output schema and full annotations, the description fully covers defaults, filtering, and alternatives. There are no meaningful gaps for selection or invocation.

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

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

Schema coverage is 100%, so the baseline is 3. The description mirrors the schema's current_only and sport semantics without adding new parameter-level details, but it does reinforce them in natural language.

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

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

The description uses a specific verb 'List' with a clear resource 'seasons' and scope 'per sport/league'. It explicitly distinguishes itself from the sibling list_sports by directing users there for just current-season info.

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

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

It states the default behavior (only active seasons), how to opt into historical seasons (current_only=false), optional sport filtering, and explicitly names list_sports as an alternative when simpler data suffices. This provides clear when-to-use 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 read-only and non-destructive behavior. The description adds useful context about the returned data structure (sport id, slug, name, team-sport flag, leagues with current_season) that is not redundant with the output schema, and it clarifies the tool's scope beyond the hints.

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

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

Two sentences: the first leads with the action and key outcome, the second details return fields and the alternative for historical data. Every sentence earns its place with no redundancy or filler.

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

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

Given the single optional parameter, rich annotations, and presence of an output schema, the description fully covers the tool's purpose, return shape, and related tool guidance. No important gaps remain for a simple list operation.

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

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

The input schema already provides a full description for active_only (100% coverage), so the schema does the heavy lifting. The description does not add additional parameter meaning beyond what is in the schema, meeting the baseline for high schema coverage.

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

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

The description clearly states the tool lists supported sports with their leagues and current season, naming the exact fields returned. It distinguishes from sibling tools by explicitly pointing to list_seasons for historical seasons, and the scope (sports vs teams/events) is unambiguous.

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

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

Provides explicit guidance to use list_seasons with current_only=false for historical seasons, which is a clear alternative. Does not enumerate all when-not-to-use scenarios, but the primary use case is evident and the alternative is well-targeted.

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 non-destructive behavior, so the description only needs to add extra context. It adds useful behavioral details: pagination is driven by after_id, results are a summary set, and image_url is null until ingest.

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

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

Three sentences with no filler; the main action and pagination are front-loaded, followed by filters, return fields, and the sibling-tool handoff. Every sentence earns its place.

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

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

For a list endpoint with an output schema and annotations covering safety and idempotency, the description covers how to paginate, what filters exist, what fields come back, and how to get full detail afterwards. Nothing essential is missing.

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

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

Schema description coverage is 100%, so the schema already documents all nine optional parameters. The description mostly restates the filter categories and cursor semantics rather than adding new parameter-level meaning, which is adequate but not additive.

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

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

States a specific verb and resource (List teams), names the pagination mechanism, enumerates filters, and specifies the returned fields. It also distinguishes itself from get_team, so an agent can tell the two apart.

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

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

Provides clear context for when to use this tool: resolve a team id here, then call get_team for full detail. This explicit routing to a sibling tool eliminates ambiguity about the boundary between list and detail operations.

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

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

Beyond the annotations (read-only, idempotent, non-destructive), the description adds critical behavioral details: it is rule-based not an LLM, specific language features are recognized, bare 'football' is ambiguous and left unrecognized, and the response includes interpreted filters, equivalent REST call, and unrecognized_terms.

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

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

The description is dense but every sentence contributes useful information. It opens with the primary purpose, provides illustrative examples, explains internal behavior, and closes with usage guidance—all without fluff.

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

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

Given the tool's natural-language processing complexity, the description thoroughly covers usage scope, behavioral limitations, and response contents. The output schema handles return values, so no additional detail is needed there. The description is comprehensive for an AI agent to decide when and how to invoke it.

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

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

Although the schema documents both parameters, the description enriches the 'query' parameter by detailing supported sports, statuses, date formats, and the ambiguity behavior. It also clarifies the 'limit' parameter's override semantics, adding value beyond the schema fields.

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

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

The description clearly states the tool's purpose: search events using natural-language queries instead of structured filters. It provides concrete examples and explicitly distinguishes it from sibling tools like list_events.

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 explicit guidance on when to use this tool versus the alternative, stating 'Prefer list_events when you already know the structured filters you want.' This directly addresses tool selection.

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

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

Annotations already mark this as readOnly, openWorld, idempotent, and non-destructive, so the bar is lower. The description adds valuable behavioral context: the identity object is the same across sports with null meaning unknown, not wrong sport, and that rankings only nests under tennis while being null elsewhere. This goes beyond the structured annotations.

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

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

The description is three sentences with no filler. The main action and filters are front-loaded in the first sentence, behavior notes in the second, and routing to alternatives in the third. Every sentence earns its place.

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

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

Given the output schema exists and annotations cover the safety profile, the description covers the remaining important context: null/unknown semantics, sport-specific rankings shape, and the relationship to sibling tools. Nothing critical is missing for an agent to call this tool correctly.

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

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

Schema coverage is 100%, so the baseline is 3. The description reinforces the role of parameters like sport, country, ranking, and after_id, and clarifies pagination via id, but it does not significantly deepen the semantics beyond what the schema already states.

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

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

The description opens with a specific verb and resource: 'Search players by name, sport, country, ranking, or active status, paginated by id (after_id).' It clearly identifies the action, the target, and the available filters, and distinguishes itself from get_player and get_player_events by naming them as alternatives.

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

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

The description explicitly states when to use alternatives: 'Use get_player for full detail on one id, or get_player_events for a player's schedule/results.' It also provides pagination context with after_id and next_after_id, making the usage conditions clear.

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