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

No annotations are provided, so the description carries full responsibility. It discloses the output contents (season metadata, data source/licence) and scope (75 competitions), but does not explicitly state read-only nature, discuss side effects, limits, or error behavior. It is adequate for a catalog tool 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.

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

Three sentences with no fluff. The main purpose is first, followed by usage guidance and coverage details. Every sentence adds value and the structure is logical and 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?

Given no output schema, the description explains enough about the return content (competitions, season metadata, source/licence). It also covers scope and guidance. While it does not detail the exact list format or any pagination, it is sufficient for a simple catalog tool and aligns with the 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?

There are no parameters (0), so the baseline is 4. The description refers to no parameters, and since none exist, it does not need to add parameter-specific semantics. Baseline applies.

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

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

States a clear verb ('List') and resource ('competitions FootballStack supports') with metadata details, and contrasts with the deep coverage to distinguish its scope. Effectively differentiates from siblings by indicating this is the broad catalogue.

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

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

Explicitly says 'Call this first,' providing a clear entry-point instruction. It also compares broad vs. deep coverage and notes historical/analytics limitations for specific leagues, giving context for when to use other tools, though it does not name sibling alternatives explicitly.

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?

No annotations are provided, so the description carries the full burden. It discloses a key behavioral trait (no API key required) and the read-only nature of checking reachability. However, it does not describe the response format, error behavior, or what constitutes 'reachable', leaving some ambiguity for the agent.

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 tightly written sentences with no waste. The core action and key context (no API key) are front-loaded, making it instantly scannable.

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

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

For a health-check tool with no parameters and no output schema, the description covers the essential points: what it does and when to use it. The only gap is the lack of detail on the return value, but this is minor for such a simple probe.

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

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

There are zero parameters and schema coverage is 100%, so there is nothing for the description to add. Per the calibration rule for zero-parameter tools, a baseline of 4 is appropriate; the description adds no parameter details because none exist.

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 a specific verb 'Check' and resource 'API', and it distinguishes itself from sibling data-providing tools by focusing on reachability. This is unambiguous and immediately differentiates it from tools like footballstack_matches or footballstack_standings.

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

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

It explicitly says it works without an API key, which implies it's for verifying server wiring and connectivity—a clear use case. It does not explicitly name alternatives or exclusions, but the purpose is so distinct that the usage context is effectively conveyed.

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?

With no annotations provided, the description carries the full disclosure burden. It does reveal the output content (xG for/against, over/under-performance versus actual goals), which is genuinely useful, but it stays silent on aggregation semantics, default league behavior, limits, or any other behavioral traits beyond the return content.

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

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

Two tight sentences with the core resource front-loaded and no filler. The 'right tool' phrasing is slightly promotional but economical, and everything present 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 single-optional-parameter, read-style tool with 100% schema coverage, the description covers the return contents adequately. It's nearly complete, lacking only an explicit nod to how it differs from the match-level xG sibling.

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

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

Schema coverage is 100% and the schema already documents the lone parameter ('League id; omit for the default league set'). The description adds nothing about the parameter beyond the schema, so the high-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 states a specific resource ('League-wide xG and performance table') with a clear verb and delineated content (xG for, xG against, over/under-performance versus actual goals). It's clear, though it only implicitly differentiates from the sibling footballstack_match_xg via the 'league-wide' framing rather than naming it.

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 a concrete use-case anchor ('The right tool for "is this team overperforming?" questions') that tells an agent when to reach for it. However, it never names alternatives like footballstack_match_xg or states when NOT to use it, leaving some routing to inference.

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

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

No annotations are provided, so the description carries the full burden. It discloses that the tool returns derived signals (form, head-to-head) but does not mention read-only nature, potential null response for invalid IDs, data freshness, or any other behavioral caveats. For a simple one-parameter retrieval, the disclosure is adequate but not rich.

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 sentence that front-loads the core purpose ('Derived context for one match') and follows with the key contents. Every word earns its place; there is no fluff or redundancy.

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

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

For a tool with one parameter and no output schema, the description covers what the returned data consists of (form, head-to-head, pre-computed signals). It does not specify exact fields or error behavior, but given the simplicity of the tool and the clarity of the description, it is sufficiently complete for correct invocation.

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

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

Schema description coverage is 100% with the parameter 'id' already described as 'Match id'. The tool description adds no additional meaning beyond what the schema provides, so the baseline of 3 applies. There is no extra syntax, format, or domain context added.

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 a verb ('Get') and a resource ('match context'), and specifies the content ('form, head-to-head and related pre-computed signals'), which separates it from sibling tools that focus on lineups, events, xG, or odds. It is not a tautology and gives enough specificity for an agent to understand what the tool returns.

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

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

The description implies the tool is for a single match's derived statistics but does not explicitly state when to prefer this over alternatives like match_lineups or match_xg. There is no guidance on when not to use it or which sibling tool to choose instead, leaving the agent to infer from the tool name and sibling names.

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?

With no annotations, the description carries the full burden of behavioral disclosure. It mentions pagination via cursor, which is a key behavioral detail. However, it does not describe response structure, default ordering, rate limits, or how multiple filters combine, leaving room for ambiguity. The pagination note adds value, but the overall behavioral disclosure is partial.

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

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

The description is two sentences with no extraneous words. It front-loads the action and filters, then follows with pagination and the relationship to sibling tools. Every sentence earns its place, and the structure is optimal for quick parsing.

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 tool with eight optional parameters and no output schema, the description covers the core aspects: filtering, pagination, and the downstream use of returned IDs. However, it omits details about the response format (e.g., fields, count, default sort order) and any error or edge-case behaviors. Given the absence of annotations, a more thorough description would improve completeness, but it is sufficient for basic usage.

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 most parameters to a high degree (88% coverage), including types and examples. The description adds the filter list and the pagination cursor mention, but does not introduce new semantic meaning beyond what the schema provides. The statement about using IDs for other tools is not directly about parameter meaning, so the baseline of 3 holds.

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

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

The description clearly states the tool lists fixtures and results, and enumerates the filter dimensions (date, competition, team, status, season, round). It distinguishes from sibling match-specific tools by directly linking the returned IDs to lineups, events, xg, and context tools, making its role as the match-identifier source explicit.

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

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

The description gives actionable guidance by telling the agent to use the returned IDs as the match id for lineups, events, xg, and context tools, which sets this tool as the entry point for match-specific queries. It does not explicitly mention alternatives for standings, competitions, or search, but the ID linkage provides clear usage context. Some exclusion guidance is missing, but the primary flow is well indicated.

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?

With no annotations, the description carries the behavioral burden. It discloses a key operational trait (polling-heavy, quota consumption), which is useful. However, it does not mention error behavior, response format, or that this is a read-only operation. The quota warning is a positive but incomplete picture.

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 succinct sentences: first states the core functionality, second adds a practical quota warning. No filler, front-loaded, every word 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 single-parameter tool with no output schema, the description covers what the tool returns (key events and commentary timeline) and a usage caveat (live match polling). While it doesn't list specific event types in full, the examples and timeline scope are enough for an agent to decide. Lacks details on pagination or data shape, but acceptable for this simplicity.

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

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

Schema coverage is 100% for the single parameter 'id', with a clear description 'Match id'. The description adds no further semantics beyond already present, so baseline 3 is appropriate. It could have mentioned how to obtain the id (e.g., from matches endpoint), but that is not required.

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 clear verb ('get') and resource ('match events') with specific content examples ('goals, cards, substitutions'), and the 'commentary timeline' distinguishes it from sibling tools like lineups or xG. It is unambiguous and specific.

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 provides a context hint ('For live matches this is the polling-heavy endpoint') but does not explicitly state when to use this tool versus alternatives, nor when not to use it. No alternatives are named, so an agent must infer that this is the events timeline tool among the siblings.

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

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

With no annotations provided, the description carries the full burden of behavioral disclosure. It mentions the output content and a paid plan requirement, but does not disclose error handling, read-only nature, rate limits, or response format. The payment note is useful but limited.

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

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

The description is a single, compact sentence that front-loads the core output ('Starting XI, bench and tactical formation') and immediately notes the payment constraint. It contains no redundant information and is appropriately concise.

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

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

The description is minimal for a tool with one parameter, but it lacks essential context about how this tool fits with siblings (e.g., when to use lineups vs. events vs. xG). It also does not describe the response structure or any limitations. The absence of usage guidance makes it incomplete for correct tool selection.

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% (the 'id' parameter is described as 'Match id'), so the schema already documents the parameter. The description does not add any additional meaning about the parameter beyond what the schema provides, so a baseline score of 3 is appropriate.

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

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

The description clearly states the tool returns the Starting XI, bench, and tactical formation for one match, which is specific and informative. It mentions 'for one match' which helps distinguish it from list-type tools like matches, but does not explicitly contrast with other match-specific siblings like match_events or match_xg.

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 no guidance on when to use this tool versus alternatives. It only mentions a payment requirement, which is a constraint but not a usage directive. There is no mention of scenarios where this tool is preferred over sibling tools such as match_events or match_xg.

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?

No annotations are provided, so the description carries the full burden of behavioral disclosure. It describes the output structure (one entry per shot with pitch coordinates and xG) but does not mention whether the operation is read-only, any authentication requirements, rate limits, or side effects. While safety may be implicitly obvious for a data retrieval tool, the description fails to disclose any behavioral traits beyond the data content.

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, tightly written sentence that front-loads the core purpose ('Shot-level Expected Goals for one match') and then adds a useful clarification about the output and use case. Every clause earns its place, with no redundancy or filler.

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

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

For a simple one-parameter tool with no output schema, the description sufficiently conveys what the tool returns and why it is useful. It mentions the essential fields (pitch coordinates and xG) and the intended use. It does not cover potential edge cases like matches with no shots, but that is minor given the tool's simplicity and the clarity of the primary purpose.

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%, with the single parameter 'id' described as 'Match id'. The description does not add extra meaning beyond what the schema already provides, such as the format or source of the id. Since the schema fully documents the parameter, the baseline of 3 applies without additional context.

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

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

The description states a specific verb ('Shot-level Expected Goals') with a precise resource ('for one match') and the purpose ('draw a shot map or model finishing quality'). It clearly distinguishes from siblings like footballstack_league_xg by explicitly scoping to a single match, so an agent can tell it apart without opening the schema.

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

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

The description provides clear context by specifying 'for one match', which implies it is not for league-level aggregates. However, it does not explicitly name alternative tools (e.g., footballstack_league_xg for league xG) or state when not to use it. The context is sufficient for a straightforward choice, but it lacks explicit exclusions or alternative routing.

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?

No annotations are present, so the description carries the full burden of behavioral disclosure. It does not state whether the operation is read-only, whether it requires authentication, or what side effects (if any) exist. The 'Informational only' phrase hints at a read operation, but it is framed as a disclaimer, not a behavioral guarantee. Since nothing is disclosed beyond the data being informational, the transparency is inadequate.

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, front-loaded sentence that clearly states the core function and includes the necessary disclaimer. Every word serves a purpose; there is no fluff or repetition. It is concise and structurally 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?

The tool is simple (one parameter, no output schema), and the description conveys the essential purpose. However, it omits any detail about the return format (e.g., what odds are included, how probabilities are presented) or preconditions (e.g., whether the match must be completed). For a synthetic-odds tool, this is a notable gap, but given the simplicity, a minimum-viable score of 3 is fair.

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 has one parameter, matchId, with 100% schema description coverage ('Match id'). The tool description does not add any extra meaning about matchId's format, source, or how it relates to the output. Given full schema coverage, a baseline of 3 is appropriate, but the description offers no added semantic value.

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

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

The description states a specific verb+resource: it 'gets odds and fair probabilities for one match.' The 'for one match' scoping differentiates it from sibling tools like footballstack_matches or footballstack_match_xg, which cover broader or different data. There is no ambiguity about what the tool does.

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 no guidance on when to use this tool versus alternatives. It only mentions 'Informational only — not betting advice,' which is a disclaimer, not a usage condition. There is no explicit context about when a user should select this over, say, footballstack_match_xg or footballstack_league_xg.

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?

With no annotations, the description carries the full burden. It discloses the key behavioral trait: it does not consume a request. This is important for a quota checker. It could also mention what happens when quota is exceeded (e.g., returns remaining quota), but the essential behavior is covered.

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, each information-dense. The purpose and usage trigger are front-loaded. No wasted words or repetition of schema content.

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

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

For a zero-parameter, no-output-schema tool, the description covers everything an agent needs: what it does, when to call it, and its side-effect-free nature. Nothing is missing for correct invocation.

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

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

The tool has zero parameters, so the schema is trivially complete. Baseline 4 applies because there are no parameters to document. The description adds no parameter-level detail, but none is needed.

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: to inspect the monthly request quota without consuming a request. The verb 'inspect' and resource 'quota' are specific. It also differentiates itself from the data-related sibling tools (e.g., matches, standings) by focusing on quota.

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

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

Explicitly states the condition for use: 'Call this when a tool returns quota_or_rate_limit.' This gives a precise trigger and implicitly distinguishes it from tools that fetch data. No exclusions are needed for a zero-parameter utility.

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?

With no annotations provided, the description must carry the full behavioral burden. It does not explicitly state that this is a read-only, non-destructive operation, nor does it disclose how matches are returned (e.g., list vs. single result, behavior on no match, potential multiple candidates). The phrase 'resolve into stable IDs' implies output is IDs, but lacks explicit safety or result 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.

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

Two sentences, zero fluff. The primary purpose is front-loaded, and the usage guidance follows immediately. Every word earns its place; it is concise without sacrificing critical 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 one-parameter search tool, the description covers the core purpose and usage direction. However, without an output schema, it should clarify the response format (e.g., whether it returns a list of candidate IDs with names or a single exact match) and handle edge cases like no results. It implicitly promises IDs but leaves the agent guessing about how to select from potential matches.

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 has 100% coverage for the single parameter 'q' with a clear description and examples. The tool description adds the context of 'free-text' resolution but does not add meaning beyond what the schema provides. Baseline 3 is appropriate because the schema already documents the parameter adequately.

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

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

The description clearly states the verb 'Resolve' and the resource 'free-text team or competition name' into 'stable FootballStack IDs'. It differentiates itself from sibling tools by explicitly positioning itself as a prerequisite ('Use this before any tool that takes a competition or team'), so an agent understands its unique role versus data-returning siblings like footballstack_matches or footballstack_standings.

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 direct usage timing: 'Use this before any tool that takes a competition or team, instead of guessing an ID.' This explicitly states when to use the tool and warns against the alternative (guessing IDs), which is a clear exclusion. No ambiguity about its role in the workflow.

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?

With no annotations provided, the description must carry the full behavioral burden. It only states that it returns a standings table, with no details on read-only nature, data structure, pagination, or potential errors. This is insufficient for an agent to understand side effects or constraints.

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, front-loaded sentence with no superfluous words. It efficiently conveys the core action and scope, achieving high conciseness.

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 tool with two parameters and no output schema, the description is adequate but not comprehensive. It does not mention what the standings table contains (e.g., points, ranks) or ordering, leaving some ambiguity. However, the concept of 'standings' is common enough that an agent may infer it; a bit more detail would raise the score.

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%, as both parameters already have descriptions. The description adds the notion that season is optional, but that is already evident from the schema (season not required). Thus, it adds minimal semantic value beyond the schema, aligning with the baseline of 3.

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 returns a standings table for a competition, optionally filtered by season. It specifies the resource (standings) and scope (one competition), but does not explicitly differentiate from sibling tools like 'matches' or 'search,' which is a minor gap.

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

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

No guidance is given on when to use this tool versus alternatives such as footballstack_matches or footballstack_search. The description implies its use for standings data, but does not mention exclusion criteria or alternatives.

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