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

Annotations already declare the tool as read-only, idempotent, and open-world. The description adds valuable context by stating 'Auth: none needed' and specifying the exact return structure, which goes beyond the provided annotations. It does not mention pagination behavior or rate limits, but the added context is substantial.

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 exceptionally concise: one sentence for purpose, one for return format, and one for auth. It is front-loaded with the core action and includes only essential information, with clear line breaks separating sections for readability.

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 list tool with two pagination parameters and no output schema, the description covers the essential elements: purpose, return structure, and authentication. The schema and annotations fill in most remaining gaps, making the description sufficiently complete for an agent to invoke the 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 description coverage is 100%, with both parameters (page and pageSize) having descriptive details. The tool description does not add any additional parameter semantics beyond what the schema provides, so the 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 action 'List' and the resource 'broadcast channels', with additional details about media types (VIDEO/AUDIO/TEXT) and the count of 272. This unambiguously identifies the tool's purpose and distinguishes it from related broadcast tools such as regions or 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?

The purpose is stated clearly enough that usage is implied (to list broadcast channels). However, there is no explicit guidance on when to prefer this over sibling tools or any exclusions, leaving room for ambiguity in edge cases.

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, idempotent, and open-world behavior. The description adds value by noting auth is not needed and specifying the exact return shape (pageInfo + content array with fields). It does not discuss pagination or restrictedCountries semantics, but the annotations reduce the burden.

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 extremely concise: a one-sentence purpose with examples, a return type line, and an auth line. Every part earns its place and the key 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 simple list tool with one optional parameter and no output schema, the description covers purpose, return format, and auth. It omits pagination behavior and the meaning of restrictedCountries, but these are minor given the tool's simplicity and the schema's coverage.

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 pageSize, which is described as 'Rows per page.' The description does not add further parameter details, but the schema already carries the meaning, so a 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 clearly states 'List broadcasters' with specific examples (Foxtel, Channel 7, BBC, ESPN) and shows the return structure, making it distinct from sibling tools that handle regions, channels, or 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?

No guidance is provided on when to use this tool versus alternatives like afl_broadcast_channels or afl_broadcast_events. The description only states what it does, without any context for selection.

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

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

Annotations already declare readOnlyHint, openWorldHint, and idempotentHint, so the safety profile is covered. The description adds a return shape ({id, name, startDateTime, channels:[...], contentReference}) and explicitly states 'Auth: none needed', which are behavioral details beyond the annotations. No contradictions, and the description does not repeat annotation data. A solid contribution given the low complexity.

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 extremely compact: one main sentence for the action, plus two short lines for return shape and auth. Every sentence provides necessary information, and the primary purpose is front-loaded. There is zero 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 single-get tool with one parameter and rich annotations, the description covers the return fields and auth, which are the main operational details. It does not mention error handling (e.g., what happens if eventId not found) but that is not essential for a straightforward get-by-id. The low complexity and annotation coverage keep this adequate.

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 fully documents the single parameter 'eventId' with a description including that it is required and part of the URL path. The description only says 'by id', which adds nothing beyond the schema. With 100% schema coverage, 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 'Get a single broadcast event by id' with a specific verb and resource, clearly distinguishing it from the sibling list tool 'afl_broadcast_events' and 'afl_broadcast_match_events'. The singular 'by id' makes the tool's scope unambiguous, so an agent can pick it apart from alternatives even without seeing sibling descriptions.

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

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

The description gives no explicit guidance on when to use this tool versus alternatives. It implies usage through the phrase 'single ... by id' (suggesting you use it when you have a specific eventId), but it does not mention alternatives like afl_broadcast_events or any conditions for selection. This falls under 'implied usage' at best.

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

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

Annotations already declare readOnlyHint=true, openWorldHint=true, and idempotentHint=true, so the safety profile is covered. The description adds value by disclosing 'Auth: none needed' and documenting the exact return shape, including lazy fields like pageInfo and the nested channels/contentReference arrays — useful context the annotations don't provide.

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

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

Compact and well-structured: a one-line purpose, a precise return-type sketch, and an auth note. The main intent is front-loaded and every sentence earns its place. Slightly trimmed from a 5 only because the return shape could be one line tighter.

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?

There is no output schema, so the description correctly carries return-type documentation, and it covers auth. But it does not explain the semantics of the contentReference object or the relationship to sibling broadcast tools, which an agent needs to fully interpret results or choose this tool. Adequate but with clear gaps.

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 all five parameters individually documented in the input schema (round, toDate, fromDate, pageSize, compseason with defaults and ISO 8601 notes). The description adds no parameter-level meaning beyond that, 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 states a clear verb+resource ('Broadcast schedule') and adds a distinguishing detail ('one entry per match per channel') that explains the data granularity. However, it does not explicitly differentiate itself from closely-named siblings like afl_broadcast_match_events or afl_broadcast_event_get, which remain ambiguous in scope.

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 on when to use this tool versus the sibling broadcast tools: afl_broadcast_match_events, afl_broadcast_event_get, afl_broadcast_channels, or afl_broadcast_regions. The description provides no exclusions or selection context (e.g., 'use this for schedule-level queries, use X for match-level details'), leaving an agent to guess which sibling fits.

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, and idempotentHint, so the safety profile is covered. The description adds 'Auth: none needed' and the return structure, which is useful but does not disclose any other behavioral nuances (e.g., pagination behavior, data freshness). It adds moderate value 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 extremely concise: one short sentence plus a return structure and auth note. It front-loads the essential scope and provides the key information without fluff. Every element 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 simple read-only list tool with rich annotations, the description is sufficient. It provides the return schema, auth requirement, and scoping parameters. It could mention the source of compseason IDs (already in schema) or pagination behavior, but these are either covered elsewhere or minor. Overall, an agent can call it correctly.

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

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

Schema description coverage is 100%, and all parameters (compseason, round, pageSize) are already described in the schema. The description adds no extra parameter meaning; it only repeats 'compseason, round' in the first sentence, which is redundant with 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 verb (broadcast) and resource (match events) scoped to a compseason and round. It clearly conveys the tool's function, but does not differentiate it from sibling tools like afl_broadcast_events or afl_broadcast_event_get, leaving some ambiguity about when to choose this one.

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 provided on when to use this tool versus alternatives such as afl_broadcast_events (which may cover broader scopes) or afl_broadcast_event_get. The description simply states what it does without context on selection criteria or exclusions.

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

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

Annotations already declare readOnlyHint, idempotentHint, and openWorldHint, so the safe read-only nature is covered. The description adds behavioral context beyond annotations by specifying the return fields ('Returns: {id, name, timezone}') and explicitly stating 'Auth: none needed', which are not in the annotations or schema.

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

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

The description is extremely concise: two short sentences and a return line. Every piece of information (verb, resource, return shape, auth) 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 one-parameter read-only tool with strong annotations, the description is complete. It states what is returned, mentions auth requirements, and the schema provides the parameter source. No output schema exists, but the return format is explicitly listed, covering the essential 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?

Schema coverage is 100%, so the single parameter 'regionId' is fully documented in the input schema. The description only says 'by id', which adds no new meaning beyond the schema. Baseline of 3 is appropriate since the schema handles the semantics.

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

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

The description clearly states a specific action ('Get a single broadcast region by id') and the resource ('broadcast region'). It distinguishes itself from the list sibling tool (afl_broadcast_regions) by emphasizing 'single' and 'by id'.

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?

Clear context: it is used to fetch a specific broadcast region by its ID. The ID source is described in the schema ('from the broadcasting region list'), which implies the workflow of listing first then getting. No explicit alternatives or exclusions, but enough context for a simple get-by-id tool.

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

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

Annotations already declare readOnlyHint, idempotentHint, and openWorldHint, so the safety profile is covered. The description adds useful behavioral details by specifying the return structure and that authentication is not required, which goes beyond the annotation fields and helps the agent understand side effects (none) and access requirements.

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 very concise: one line for the main action, one for the return shape, and one for auth. Every sentence adds value and the structure is front-loaded with the primary purpose.

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 list tool with optional pagination, the description covers the core functionality, return format, auth requirement, and the fact that there are exactly 26 regions. The absence of an output schema is compensated by the explicit return shape. Only minor gaps exist, such as whether pageSize has a maximum or how pagination works, but the schema and pageInfo hint are sufficient.

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 documents both 'page' and 'pageSize' with descriptions, achieving 100% coverage. The description does not add additional parameter semantics beyond what the schema already provides, so it matches the baseline of 3 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 it lists broadcast regions and includes the count (26) and that each region has a timezone. The verb 'list' plus resource 'broadcast regions' distinguishes it from sibling tools like afl_broadcast_region_get (single region) and afl_broadcasters_list (broadcasters, not regions).

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 explicit when-to-use or alternative exclusions are provided. However, as a list endpoint, it's implied that this is the right tool when you need all regions, while a specific region would use afl_broadcast_region_get. But this is not stated in the description, so guidance is only implied.

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 valuable behavioral context beyond the annotations: the automatic minting of the anonymous x-media-mis-token, the pattern of provider IDs (CD_M*/CD_R*/...), and the need to map integer IDs. It also explicitly states 'Auth: none needed,' aligning with the readOnlyHint and idempotentHint annotations without contradiction.

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 with the core purpose. It uses four short sentences to convey scope, token behavior, ID mapping, and reference to the operations list. The 'Returns:' and 'Auth:' lines are terse but informative, with no wasted words.

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 generic call tool with no output schema, the description covers the essentials: what it calls, how to discover operations, how to handle path params, and the token requirement. It stops short of explaining error cases or return structure beyond 'JSON object,' but given the openWorldHint and reference to the catalogue, it is adequate.

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?

While the schema already documents the three parameters (operation, path_params, query_params) with 100% coverage, the description enriches them by explaining that operation names come from the catalogue resource, path_params use provider IDs, and query_params are documented in the catalogue. This adds practical meaning beyond the dry schema text.

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

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

The description clearly states the tool's function: 'Call any of the AFL CFS premium operations' with a specific URL base. It distinguishes itself from sibling tools by being a generic call tool for premium operations, while siblings like afl_competitions_list or afl_match_get target specific AFL resources.

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 concrete guidance: 'Read afl://cfs/operations for the full op list' and explains how to map integer IDs via idmap endpoints. However, it does not explicitly say when to prefer this tool over the dedicated AFL sibling tools, though the 'premium operations' scope implies it.

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 and idempotent, so the description only needs to add extra context; it does so by specifying the return shape and that no auth is required. It does not contradict 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?

Three short, front-loaded sentences: purpose, return shape, and auth. No filler or repetition; every line 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 simple get-by-id tool with no output schema, the description covers the return fields and auth requirement, and the schema covers the id source. It is nearly complete, though it omits error/not-found behavior.

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

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

The single parameter is fully documented in the schema (clubId, required, from afl_clubs_list, URL path), so the description need not repeat it. The description adds no parameter details beyond 'by id', so 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 clearly states 'Get a single club by id', identifying the action, resource, and scope. It distinguishes itself from sibling tools like afl_clubs_list, which lists clubs.

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 usage when a club id is known, but does not explicitly contrast with list/idmap tools or mention when not to use it. The schema notes the id comes from afl_clubs_list, but the description itself offers no alternatives or exclusions.

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

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

Annotations already declare readOnlyHint, openWorldHint, and idempotentHint, so the safety profile is covered. The description adds context beyond annotations by specifying the return shape ({clubs:[...]}) and auth requirement (none needed), which is useful for invocation.

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 extremely concise, delivering purpose, return structure, and auth in three short lines. It is front-loaded and contains no filler or 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?

For a simple list tool, the description is nearly complete: it covers what, returns, and auth. The schema handles pagination parameters, and annotations cover safety. The only missing piece is explicit guidance on when to use this over sibling tools, but that is not critical given the low 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 coverage is 100% with descriptive parameter names and clear descriptions (page: 'Zero-based page number.', pageSize: 'Rows per page.'). The tool description adds no additional parameter meaning, so 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 clearly states the tool lists AFL/AFLW clubs with a specific resource and a count of 32. It does not explicitly differentiate from the sibling afl_teams_list, which could be similar, but the core purpose 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?

The description provides no guidance on when to use this tool versus alternatives such as afl_teams_list or afl_club_get, and no exclusions are mentioned. For a simple read-only list, this is a gap but not fatal given the name implies its scope.

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, and idempotentHint, so the safety profile is covered. The description adds value by specifying the return structure ({meta, compSeasons:[...]}) and clarifying that no authentication is needed. This goes 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 concise and front-loaded with the main purpose, followed by return format and auth requirement. Every sentence provides useful information with no redundancy. Three short lines cover what is needed.

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 a simple list operation with two parameters, full schema coverage, and beneficial annotations. The description includes the return shape and auth requirement, making it largely complete. It does not explain pagination behavior, but pageSize parameter implies this and is documented in the schema. Overall, it is sufficiently complete for its complexity.

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

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

Schema description coverage is 100%: competitionId and pageSize both have descriptions. The tool description does not add meaningful extra context beyond the schema; it only restates the resource. With full schema coverage, 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 uses a specific verb 'List' and resource 'comp seasons within one competition', clearly scoping the tool to a single competition. This inherently distinguishes it from sibling tools like afl_compseasons_list, which likely lists all comp seasons. The purpose 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?

The description implies usage when you need comp seasons for a specific competition and notes that competitionId comes from afl_competitions_list, providing a prerequisite. However, it does not explicitly state when to use this tool over alternatives like afl_compseasons_list, nor does it provide exclusion criteria. Usage is implied rather than explicit.

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, and idempotentHint, but the description adds valuable behavioral context: it specifies the return format ('{meta, competitions:[...]}') and explicitly states 'Auth: none needed', which is not covered by the annotations. This goes beyond the minimum and provides useful operational 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?

The description is compact and front-loaded with the core purpose in the first line. The return type and auth requirement are each given in a short, distinct line, making it highly scannable. Every sentence contributes meaningful information 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?

For a simple single-ID lookup tool, the description is nearly complete: it covers the purpose, return structure, and authentication. The schema fully documents the parameter. Minor gaps include potential error behavior (e.g., when ID not found) and the contents of 'meta', but these are not critical given the simplicity and the presence of sibling tools for broader 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 input schema already documents the single parameter 'competitionId' with a description and example. The tool description only repeats that it uses an integer id, adding no new meaning beyond the schema. With 100% schema coverage, a baseline of 3 is appropriate, and the description does not compensate further.

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 'Get a single competition by integer id' uses a specific verb (get) with a clear resource and scope (single by integer id), which clearly distinguishes it from the sibling 'afl_competitions_list'. It also provides the expected return shape, removing any ambiguity about what the tool retrieves.

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 usage: you need an integer competition ID, and it returns a single competition. However, it does not explicitly mention when to use this tool over alternatives like 'afl_competitions_list' or any exclusions. Guidance is only implicit through the word 'single', so it falls short of explicit 'when to use vs when not to use'.

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

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

Annotations already declare readOnlyHint=true and idempotentHint=true, covering safety and idempotency. The description adds useful behavioral context by showing the return structure ({meta, competitions}), stating 'Auth: none needed' and giving a concrete example, which goes beyond 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: one sentence for purpose, a single line for return shape, an example, and auth note. Every part earns its place with no redundancy or 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 simple paginated list tool, the description is complete enough. It provides the return shape, an example invocation, and auth requirements. The schema and annotations cover safety and parameters, leaving no significant gaps for an agent to invoke 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% with both page and pageSize having descriptions, defaults, and constraints, so the schema already handles parameter semantics. The description's example with pageSize adds minimal value beyond what the schema provides.

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 starts with 'List all AFL competitions', which is a specific verb and resource, and gives concrete examples (AFL, AFLW, VFL, SANFL). This clearly distinguishes it from sibling tools like afl_competition_get and similar lists from other sports.

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 clearly states what the tool does ('List all AFL competitions') and provides an example with pageSize, making the context obvious. However, it does not explicitly mention when to use this vs. alternatives like afl_competition_get, so it lacks explicit exclusions.

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

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

Beyond the annotations (readOnly, idempotent, openWorld), the description adds 'Auth: none needed' and the exact return shape, which is valuable for an agent to anticipate the response. This goes well beyond the structured data.

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

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

The description is compact and front-loaded with the main action. The return block and auth note are directly useful and contain no redundancy. 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 simple nature of the tool (single parameter, read-only, getter), the description is complete: it covers the return structure, auth requirement, and the distinguishing 'embeds full rounds array'. No output schema exists, so the described return shape helps fill that gap.

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

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

The input schema already provides a complete description for compSeasonId, including an example and note that it's part of the URL path. The tool description adds no additional parameter semantics, so the baseline 3 is appropriate given full 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 uses a specific verb ('Get') and specific resource ('single comp season'), and clearly differentiates from siblings by noting it embeds the full rounds array and currentRoundNumber. This distinguishes it from list-style tools like afl_compseasons_list or afl_rounds_list.

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 clearly conveys that this tool is for retrieving a specific comp season by ID, and the mention of embedded rounds implies use cases where round data is needed. It does not explicitly name alternative tools or state exclusions, but the context is clear enough for an agent to select it appropriately.

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 value beyond annotations by disclosing the return shape (meta.pagination and compSeasons fields) and stating 'Auth: none needed'. It also specifies the data range 2012–present. These details complement the readOnlyHint and idempotentHint 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 extremely concise: one purpose sentence, one return-shape line, and one auth line. Every part is essential and there is no filler.

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

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

For a simple list tool with two optional parameters and rich annotations, the description covers purpose, scope, date range, return structure, and auth. No output schema exists, but the description compensates by listing the return fields.

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?

Input schema provides 100% coverage with descriptions for both page and pageSize, including defaults. The description adds no extra parameter-level information, so 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 clearly states 'List comp seasons across all competitions' with a specific verb and resource, and adds a date range (2012–present). This distinguishes it from siblings like afl_compseason_get and afl_competition_compseasons.

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 clearly implies this is the global listing tool by saying 'across all competitions'. However, it does not explicitly mention alternatives (e.g., afl_competition_compseasons for a single competition) or exclusion criteria, so it stops short of a full 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 declare readOnlyHint=true and idempotentHint=true, indicating a safe read operation. The description adds value beyond this by specifying the return shape '{id, type:'photo', title}' and stating 'Auth: none needed.' These details help the agent anticipate the response and confirm no authentication barriers, complementing the annotation-provided safety profile.

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 extremely concise—two short sentences plus a return line—with no wasted words. The key action is front-loaded, and every line adds relevant information: what it does, what it returns, and auth requirement.

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 getter with one parameter and no output schema, the description is sufficiently complete. It provides the return format and auth status, which partially compensates for lacking an output schema. It does not describe error behavior or edge cases, but these are less critical for a read-only fetch by id. Sibling tools exist, but the core purpose and call pattern are clear.

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 'Content item id. Required — part of the URL path.' The description does not add further meaning beyond what the schema already states; it only repeats 'by id.' Since the schema fully documents the parameter, 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 is specific: 'Get a single photo content item by id.' It clearly identifies the resource (photo content item) and the verb (get). It distinguishes from sibling tools like afl_content_photo_list (list vs single) and afl_content_video_get/text_get by the explicit 'photo' type.

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 usage: call this when you have a content id and need a single photo item. However, it does not explicitly state when to use this versus alternatives, nor does it mention any exclusions or prerequisites beyond having an id. There is no direct guidance about selecting this over list or other content getter tools.

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, and idempotentHint, covering the safety profile. The description adds valuable context beyond that by specifying 'Auth: none needed' and outlining the response shape ({pageInfo, content:[{id, type:'photo', title, leadMedia}]}), which is especially useful since no output schema exists. 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?

The description is extremely concise and front-loaded: a single action sentence plus a compact return structure and auth note. Every line provides useful information with zero waste, making it efficient for an agent to parse.

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 5 optional parameters, the schema fully documents the parameters and annotations cover safety, while the description fills gaps with auth requirements and return format since no output schema exists. The only missing element is explicit guidance on when to choose this over the photo 'get' sibling, but overall the description is sufficiently complete for a well-scoped 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 covers 100% of parameters with detailed descriptions (e.g., 'Rows to skip — this CMS surface pages with offset/limit, not page/pageSize'), so the baseline is 3. The description itself adds no parameter information, leaving semantics entirely to the schema, which is adequate but not enhanced.

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 action ('List') and resource ('photo content'), making the tool's purpose unambiguous. It distinguishes from sibling tools like afl_content_text_list and afl_content_video_list by specifying the photo content type, and also provides the return structure.

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 implied usage context by naming the operation ('List photo content') but does not explicitly state when to use this tool versus alternatives, such as afl_content_photo_get for fetching a single photo. It does not mention exclusions or prerequisites, relying on the tool name and sibling list for differentiation.

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

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

Annotations already declare readOnly, openWorld, and idempotent hints, so the description supplements this by specifying the return shape and confirming no authentication is required. It does not detail error handling or pagination, but the annotation coverage reduces the burden.

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 concise lines: purpose, return shape, and auth requirement. It is front-loaded and contains 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 getter with rich annotations and full schema coverage, the description is complete. It adds return structure (not available via output schema) and auth requirements, making it adequate for an agent to invoke 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 has 100% coverage with descriptions for both parameters. The description only echoes 'by id' and adds no extra meaning beyond what the schema already provides, so the 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 states 'Get a single promo content item by id' with a specific verb and resource, clearly distinguishing it from the sibling list tool. It precisely scopes the operation to a single item retrieval.

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

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

The phrase 'by id' implies the condition for use, and 'Auth: none needed' gives clear context. However, it does not explicitly mention that afl_content_promo_list should be used for fetching multiple promos or provide exclusions.

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

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

Annotations already declare readOnlyHint, openWorldHint, and idempotentHint, so the description doesn't need to re-state safety. It adds valuable context by specifying the exact return shape ({pageInfo, content:[{id, type:'promo', title, links:[{promoUrl, linkText}]}]}) and explicitly noting that authentication is not required ('Auth: none needed'). This goes beyond the annotations by describing the response structure and access requirements.

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 well-structured: one clarifying sentence about the resource, a returns block, and an auth note. Every sentence adds value without redundancy. It is fully front-loaded with the purpose and gives essential technical details in a scannable format.

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 list tool with 3 optional parameters and no output schema, the description provides enough context: purpose, return shape, and auth. The schema covers the parameters, so the description completes the picture by telling the caller what to expect in the response and that no auth is needed.

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: all three parameters (limit, tagNames, referenceExpression) have descriptions. The tool description does not add extra parameter context, but the schema already provides sufficient meaning. Therefore, 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 clearly identifies the resource as 'promo / marketing cards' and the action as 'List', which is specific and distinct from sibling tools like afl_content_promo_get, afl_content_text_list, and afl_content_video_list. The added detail about embedded CTAs (links[]) further clarifies what these cards contain.

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 usage for retrieving promo/marketing content, but does not explicitly state when to prefer it over alternatives or provide exclusions. There is no mention of when NOT to use this tool or what other tools might be better suited for different scenarios.

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

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

Annotations already declare readOnly, idempotent, and open world, covering safety. The description adds useful behavioral context by specifying the return shape (id, type, title, body, author, references, tags) and explicitly stating no authentication is needed. This goes beyond what annotations provide.

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

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

The description is two short lines plus a return line, front-loaded with the purpose, and every sentence adds value. No unnecessary words 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?

For a simple single-get tool with one parameter, the description covers purpose, return format, and auth requirements. Since there is no output schema, explaining the returned fields is essential and done. Nothing meaningful 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 input schema already describes the id parameter with clear semantics (Content item id, required, part of URL path) at 100% coverage. The description adds no further parameter detail, so 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 starts with 'Get a single text article by id,' which uses a specific verb (get) and resource (text article) and clearly distinguishes from sibling list/photo/video tools. It is unambiguous 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 phrase 'single ... by id' clearly implies this is for fetching one specific article when you have its id, distinguishing from list/collection tools. It gives clear context for when to use it, though it does not explicitly name alternatives or exclusion criteria.

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

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

Annotations already declare readOnlyHint, openWorldHint, and idempotentHint. The description adds valuable context beyond this by detailing the return structure, noting auth is not required, and giving an example request. Such details help the agent understand expected behavior.

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

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

The description is well-structured and concise: purpose, return format, example, and auth note. Each sentence contributes meaningful information without 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?

With no output schema, the description compensates by specifying the return shape. It covers purpose, example, and auth. However, it could further clarify pagination semantics (e.g., offset/limit vs page/pageSize) beyond the schema, though the schema already documents this. Overall, it is adequate for a list tool.

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

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

Schema coverage is 100%, providing baseline. The description adds value by illustrating how to use referenceExpression and tagExpression in a realistic example, clarifying which parameters are primary for filtering. This goes beyond the schema's per-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 clearly states the tool lists text articles (news) with reference/tag filters. It distinguishes itself from siblings like afl_content_video_list (video) and afl_content_text_get (single item retrieval) by specifying the resource type and filter options.

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 context for use (listing news articles with filters) and provides a concrete example with AFL/AFLW news. However, it does not explicitly name alternatives or state when not to use this tool, which would be needed for 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 declare readOnlyHint=true and idempotentHint=true, so the description adds value by specifying 'Auth: none needed' and detailing the exact return fields. This goes beyond the structured hints and provides practical invocation context.

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

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

The description is extremely concise with three short sentences, each serving a purpose: action, return shape, and auth. It is front-loaded and free of 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 single-id get operation with rich annotations, the description is sufficient: it names the resource, return format, and auth. It lacks error-handling notes, but these are not essential for this low-complexity tool.

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

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

Schema coverage is 100% and the single 'id' parameter is already well-documented in the schema. The description adds no additional parameter semantics beyond the verb 'by id', so it does not go beyond the baseline.

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

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

The description clearly states the action ('Get a single video content item by id') with a specific verb and resource. It distinguishes from siblings like afl_content_video_list and other content-type get tools by explicitly scoping to a single video item.

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 conveys when to use the tool (when you have an id and need a specific video item). It does not explicitly mention when not to use or name alternatives, but the context is clear given the sibling list tool and the id parameter requirement.

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

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

Annotations already declare readOnlyHint=true, openWorldHint=true, and idempotentHint=true, and the description does not contradict them. It adds beyond-annotation value by stating 'Auth: none needed' and disclosing the exact return shape ({pageInfo, content:[...]}), which helps the agent set expectations. Rate limits or result caps are not mentioned, but the added context is adequate for a simple list 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 is three terse, front-loaded segments: purpose, return shape, and auth. Every sentence earns its place with no filler, repetition of schema data, or redundant annotation restating.

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

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

With no output schema, the description properly takes on return-value disclosure ('Returns: {pageInfo, content:[{id, type:'video', title, duration, onDemandUrl, additionalInfo}]}'). Combined with 100% schema coverage and strong annotations, the tool is mostly complete for a list operation; only usage guidance versus sibling content/live-video tools is left underspecified.

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 of 3 applies — the schema already documents all six optional parameters with clear descriptions and examples (e.g., 'Rows to skip — this CMS surface pages with offset/limit, not page/pageSize'). The tool description itself adds no parameter-level meaning, relying entirely on the rich 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+resource: 'List video content (highlights, replays, press conferences).' It enumerates concrete content types and shows the return shape, clearly distinguishing it from sibling list tools like afl_content_text_list, afl_content_photo_list, and afl_content_promo_list.

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 usage by enumerating the covered content types (highlights, replays, press conferences) but never explicitly states when to use this tool versus alternatives such as afl_content_video_get, afl_live_video, or entain_video_channels. No exclusions or preferred-alternative guidance is provided, which is a gap given the large sibling set.

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 beyond that: it mentions the return value {signedUrl}, potential 401 error for anonymous tokens, and explicitly states 'Auth: none needed.' This clearly discloses behavioral traits and failure modes.

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 includes useful return/auth info, but the line 'Also answers this: ...' is cryptic and not immediately clear, reducing overall conciseness. It could be tightened by removing or explaining that note.

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 covers the main functionality, return value, auth requirements, and an error case. It is mostly complete, though it could benefit from explicit guidance on when to use it instead of sibling streaming tools.

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

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

The input schema already fully describes the single 'url' parameter as 'The unsigned HLS .m3u8 URL to sign.' The description adds minimal extra meaning (e.g., 'AFL HLS video URL'), so it does not significantly improve parameter semantics beyond the schema baseline.

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

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

The description clearly states the action ('Sign an AFL HLS video URL for playback') and the resource (AFL HLS video URL), with a specific result (token-signed CDN URL). This distinguishes it from sibling streaming tools by focusing on the URL signing function.

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

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

Usage is implied: use when an unsigned HLS URL needs signing for playback. However, there is no explicit when-to-use vs alternatives, and the line 'Also answers this: cricketaustralia_streams, entain_video_channels, pointsbet_inplay_streaming' is vague and does not clarify selection criteria.

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

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

Annotations already declare readOnlyHint, openWorldHint, and idempotentHint, so the safety profile is known. The description adds 'Auth: none needed' and the return format, which are useful behavioral context beyond the annotations. It does not contradict annotations, and it clarifies that the data reflects up to the current round (i.e., changes over time).

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 concise and well-structured: a one-sentence purpose, a return type line, a concrete example, and an auth note. Every sentence adds value and there is no redundant fluff. The example is particularly useful for demonstrating the parameter usage.

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 tool with one parameter, the description is complete: it explains the purpose, provides the return shape, shows an example call, and states auth requirements. Given the strong annotations and schema coverage, no additional context is necessary. It fully equips an agent to invoke the 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 has 100% coverage for the single parameter compSeasonId, with a thorough explanation (competition-season id, not calendar year, required). The description only shows an example value (85) without adding new semantics. Since the schema carries the full burden, 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 a competition ladder for a specific AFL competition season up to the current round. It uses a specific verb+resource, and the return structure is explicitly outlined. It distinguishes itself from sibling AFL tools by focusing on ladder data as opposed to matches, teams, or seasons.

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 when to use the tool: when you need the current or in-progress ladder for a competition season. It does not explicitly list alternatives or exclusions, but it provides clear context through the example and the 'up to a comp season's current round' qualifier. No misleading guidance is present.

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 discloses important behaviors beyond the annotations: empty when no game is live, return structure with pageInfo and content containing id/name/channels, and no auth needed. This complements the readOnlyHint/idempotentHint annotations without contradiction.

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 with the primary purpose, followed by return format and auth. It avoids unnecessary detail, though the 'Also answers this: openf1_team_radio' line is an odd addition that somewhat disrupts the clean structure.

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, the description provides essential context: live-only availability, empty result condition, return shape, and auth requirements. It doesn't explain the channels array contents, but the schema and return structure make it largely self-explanatory.

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 covers all three parameters (round, pageSize, compseason) with 100% description coverage, so the baseline of 3 applies. The tool description itself adds no additional parameter semantics beyond what's already in the schema.

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

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

The description clearly identifies the tool as providing live AFL audio streams and notes that it returns empty when no game is live. This distinguishes it from siblings like afl_live_video (video vs audio), though it lacks an explicit verb and the 'Also answers this: openf1_team_radio' note adds a confusing cross-domain capability.

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

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

Usage is implied: it's for live AFL audio, with the caveat that it's empty when no game is live. However, there is no explicit 'when to use vs alternatives' guidance, and the note about openf1_team_radio is a routing hint rather than a clear usage policy.

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 readOnlyHint/idempotentHint annotations, the description discloses that no authentication is needed, returns empty when no game is live, and provides the exact return structure. These are valuable behavioral facts not covered by annotations or schema.

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

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

The description is concise and front-loaded: the first sentence states the core purpose, followed by return structure, auth, and sibling alternatives. Every sentence adds value and there is no wasted text.

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 tool with well-documented parameters, the description covers all essential context: return shape, auth, empty behavior, and related tools. It is complete without needing an output schema.

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

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

Schema coverage is 100% with descriptive parameter names and descriptions for round, pageSize, and compseason. The tool description does not add extra parameter semantics, so it stays at 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 the tool provides live AFL video streams, with the key behavior of returning empty when no game is live. It distinguishes itself from siblings like afl_live_audio by specifying video, and it even names alternative tools it can answer for (cricketaustralia_streams, entain_video_channels, pointsbet_inplay_streaming).

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 this tool (needing live AFL video streams) and notes the 'Also answers this' alternatives, which helps route mental queries. It does not explicitly state when not to use it, but the context is sufficient given the tool's simplicity.

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, and idempotentHint, so the safety profile is covered. The description adds useful context beyond those hints: the payload size (~48 KB), the exact return structure, and the fact that no authentication is required. This is meaningful additional behavioral disclosure that helps set expectations for a read-only mapping operation.

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 extremely concise, leading with the core purpose in the first line, then providing a clear return example and an auth note. Every sentence carries information, and the format is well-structured with 'Returns:' and 'Auth:' labels. There is 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 zero-parameter, read-only mapping tool, the description is fully sufficient. It explains exactly what data is returned (including an example entry), the approximate size, and that no auth is needed. Combined with the annotations, the agent has all necessary context to invoke the tool correctly without an output schema.

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

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

The input schema has zero parameters, so the description is not required to explain parameter meanings. With no parameters, a baseline of 4 is appropriate. The description does refer to 'every match providerId', which clarifies the scope of the mapping and the format of the keys (CD_M*), effectively adding semantic clarity that the schema cannot provide.

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 maps every match providerId (CD_M*) to its integer id, which is a specific verb (map), specific resource (match providerIds), and the target distinction from sibling idmap tools like afl_teams_idmap and afl_players_idmap. The return format is also illustrated with a concrete example.

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?

Although the description implies the tool should be used when a match providerId (CD_M*) needs to be converted to an integer id, it does not explicitly state when to use this versus alternative tools like afl_teams_idmap or afl_players_idmap, nor does it give any exclusions or prerequisite conditions. There is no direct usage guidance beyond the obvious mapping purpose.

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, and idempotentHint, so the safety profile is covered. The description adds useful behavioral details: 'Auth: none needed', the exact return shape (meta.pagination and matches array with key fields), and an example combining status, startDate, and competitionId. These go beyond the annotations and schema.

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

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

The description is compact and well-organized: a one-sentence function overview, a return shape, a concrete example, and an auth note. Every line earns its place with no redundancy or vague 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 tool has 10 optional parameters and no output schema, the description compensates well by documenting the return shape, providing a realistic example, and stating auth requirements. It doesn't explain pagination defaults or sort behavior, but those are adequately covered by the schema descriptions.

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 provides descriptions for all 10 parameters (100% coverage), so the description does not need to explain each parameter. The example shows a practical combination of status, startDate, and competitionId, which adds some usage context, but it does not add semantic meaning beyond what the schema already offers.

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 starts with 'List matches with filters' which is a specific verb+resource and clearly indicates the tool's list/filter purpose. It distinguishes itself from siblings like afl_match_get (singular match) and afl_matches_idmap (id mapping) by emphasizing filters and listing the filter dimensions (competition, season, round, team, status, date).

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 example 'Live + upcoming AFL matches from a date' provides concrete context for a common use case, implying when to use this tool (filtering matches by status/date). However, there is no explicit mention of alternatives or when not to use it, which keeps it just shy 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 declare readOnlyHint, openWorldHint, and idempotentHint. The description adds useful behavioral context: score is only included 'when started', auth is 'none needed', and the matchId is explicitly 'NOT providerId'. These enrich understanding 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 compact and front-loaded with the verb+resource in the first sentence. It includes a clear return structure and auth note in two additional lines, with no unnecessary words.

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 simple single-parameter tool, the description is fully complete: it explains the return payload, conditional score field, auth requirements, and the ID type distinction. The annotations cover safety and idempotency, so no additional context is needed.

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 description already explains that matchId is the required URL path parameter and not providerId. The tool description adds no additional parameter semantics beyond restating 'integer id'.

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

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

The description clearly states 'Get a single match by integer id' with specific contents (teams, venue, time, score). This distinguishes it from sibling list tools like afl_matches_list and afl_matches_idmap, and the return shape is explicitly outlined.

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 tool implies use when you have an integer match ID and need one match, but it does not explicitly contrast with alternatives such as afl_matches_list or afl_matches_idmap. No when-not-to-use guidance is provided.

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 provide readOnlyHint, openWorldHint, and idempotentHint. The description adds valuable behavioral context: 'Auth: none needed' and the exact return structure, which is not included in structured fields. No contradictions.

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 extremely concise, with just two sentences covering purpose, return format, and auth. Every element is useful and there is no filler.

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

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

For a simple single-parameter lookup tool, the description covers essential aspects: what it does, the return shape, and authentication requirements. No output schema exists, but the inline return format compensates. The description is 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 description coverage is 100%, and the parameter schema fully explains playerId's source and requirement. The tool description adds no additional parameter semantics beyond the schema, so baseline 3 applies.

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

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

The description clearly states the tool's function: 'Get a single player by id' and specifies the content areas (bio, draft, height/weight). This distinguishes it from sibling tools like afl_players_list, which are for bulk retrieval.

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 usage context for fetching a single player, and the parameter schema mentions 'from afl_players_list', indicating a prerequisite. However, it does not explicitly state when to use this tool over alternatives or provide exclusionary 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 disclose readOnlyHint, openWorldHint, and idempotentHint, so the description's additional details—payload size (~98 KB), auth requirement (none), and the exact return structure—are valuable. This goes beyond the annotations and helps the agent anticipate a potentially large response.

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

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

The description is concise and front-loaded with the main purpose, followed by concise Returns and Auth lines. Every sentence serves a purpose without unnecessary detail, making it easy to scan and understand.

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 no parameters and no output schema, the description provides purpose, scale, return format, and auth. It is nearly complete, though it could mention whether the map is exhaustive or if there are any caveats about coverage of historical players. The 'every player' wording implies completeness, so this is a minor gap.

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

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

There are zero parameters, so schema coverage is 100% vacuously. The description adds meaning by specifying the output shape (`{entityType:'player', idMapResponse:{ids:{...}}}`), which is useful for parsing the response, even though no parameter semantics are 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 maps every player providerId (CD_I*) to its integer id, using a specific verb ('Map') and resource ('every player providerId'). This distinguishes it from sibling tools like afl_players_list or afl_player_get, which likely provide player details rather than an ID mapping. The scale (~98 KB, 17k+) also adds precise context.

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 translating CD_I* provider IDs to integer IDs, which is clear from the context of sibling idmap tools (afl_teams_idmap, afl_matches_idmap). However, it does not explicitly state when to prefer this over alternatives or when not to use it, so it falls 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 declare read-only, idempotent, and open-world hints. The description adds useful context beyond annotations: 'Auth: none needed' and a concrete return structure. This gives agents confidence about access and expected response shape.

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

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

The description is extremely concise and well-structured: a one-line purpose statement, a return format block, and an auth note. Every sentence adds value with no 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?

The tool is simple, and the description covers purpose, return shape, and auth. The '17k+ all-time catalogue' note hints at the need for pagination, and the schema provides the necessary parameters. It lacks explicit mention of ordering or limits, but these are not critical for a basic list tool.

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

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

Schema coverage is 100% with clear parameter descriptions for 'page' and 'pageSize'. The description adds no additional parameter guidance, but does not need to since the schema already documents them fully.

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 'List players', a specific verb with the resource, and adds '17k+ all-time catalogue' to specify scope. This distinguishes it from single-player tools like afl_player_get and mapping tools like afl_players_idmap.

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 usage is implied by the name and description: use this to get a bulk list of players. However, it does not explicitly mention when to use this over alternatives like afl_player_get or how to navigate pagination beyond the schema.

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

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

The annotations already declare readOnlyHint, openWorldHint, and idempotentHint, so the safety profile is covered. The description adds value by specifying the exact return fields (including byes and times) and stating 'Auth: none needed,' which gives useful context beyond the annotations. It does not describe pagination behavior, but the schema covers pageSize.

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 concise and front-loaded with the primary action, followed by the return format and auth note. Every sentence provides useful information without redundancy, making it easy to scan and process.

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, combined with the annotations and schema, gives an agent enough context to invoke the tool correctly. It includes the return shape and a clear statement of what is returned, while safety and idempotency are covered by annotations. Minor gaps like pagination defaults are handled in the schema, making this a well-rounded description.

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 covers all three parameters with clear descriptions at 100% coverage, so the baseline is 3. The tool description adds no additional parameter meaning beyond the schema; it simply references 'a comp season,' which is already captured in the compSeasonId parameter description.

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 rounds for a comp season, including byes and start/end times. It uses a specific verb and resource, and the name aligns. However, it does not explicitly distinguish it from sibling tools like afl_compseason_get, so it falls short of a 5.

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

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

The description implies usage by identifying the resource ('rounds for a comp season') but provides no guidance on when to prefer it over alternatives, nor any exclusions. The note about auth is minor and does not help with tool selection. It is adequate but not explicit.

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

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

Annotations already declare readOnly, idempotent, and openWorld hints. The description adds valuable context beyond annotations by specifying the return shape ('{meta, seasons:[{id, year}]}') and auth requirements ('Auth: none needed'). This is helpful and consistent 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?

The description is extremely concise: three short sentences covering purpose, return value, and auth. Every sentence adds essential information with no filler.

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

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

For a simple get-by-id tool with one parameter, the description is fully complete. It explains the resource, the return shape, and auth. The rich annotations and schema cover the remaining 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 schema has 100% coverage for the single parameter, including a clear description and provenance ('from afl_seasons_list'). The tool description itself adds no additional parameter semantics, 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 clearly states the tool's function: 'Get a single calendar-year season by id.' It uses a specific verb and resource, and distinguishes from siblings like afl_seasons_list (which lists all seasons) and afl_compseason_get (which gets competition seasons) by focusing on a calendar-year season.

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 usage context through the parameter description 'Season id (from afl_seasons_list)', indicating a workflow of listing seasons first. It clearly identifies the tool as a single-item fetch but does not explicitly mention when NOT to use it or name 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, openWorldHint, and idempotentHint, covering safety and idempotency. The description adds the return format and the fact that no auth is needed, which is useful but does not elaborate on pagination behavior or the contents of 'meta'. It does not contradict 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 extremely concise, with the core purpose in the first line and return/auth details in two short lines. Every sentence provides useful information, with no 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?

For a simple list tool with no output schema, the description adequately covers the return shape and auth requirements. However, it leaves 'meta' undefined and does not mention any ordering or default behaviors, which are minor gaps given the low complexity and rich annotations.

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 'page' and 'pageSize' both described clearly. The description adds no additional parameter information, 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 the specific verb 'List' with resource 'calendar-year season records', and defines the return shape as {meta, seasons:[{id, year}]}. This clearly states what the tool does, though it does not explicitly contrast with sibling tools like afl_compseasons_list or afl_season_get.

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

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

There is no guidance on when to use this tool versus alternatives (e.g., afl_compseasons_list for competition-specific seasons or afl_season_get for a single season). The phrase 'calendar-year season records' provides an implicit hint, but no explicit usage context or exclusions are given.

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

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

With annotations already indicating readOnlyHint, idempotentHint, and openWorldHint, the description adds useful context: the anonymous x-media-mis-token is minted automatically, path params use provider IDs (CD_S*/CD_R*/CD_I*), and it points to a catalogue resource. This goes 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 compact and front-loaded with the core purpose. Every sentence provides distinct value: the API base path, token requirement, provider ID convention, catalogue pointer, and return type. 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 generic dispatcher tool with high complexity, the description covers the essentials: what it calls, where to find the operation list, token requirements, and path parameter conventions. It does not describe error behavior or response schema, but the input schema and catalogue resource fill those gaps, and no output schema exists to require more detail.

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 baseline is 3. The description adds specific guidance that path params use provider ID formats (CD_S*/CD_R*/CD_I*), and references the catalogue resource for discovering valid operation names, which enriches the parameter understanding beyond the schema's own 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 clearly states it calls 'any of the AFL StatsPro operations' with the specific API base path, making the verb and resource explicit. It distinguishes itself from dedicated AFL tools (like afl_competition_get) by being a generic dispatcher, and directs users to a catalogue resource for operation names.

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 implies usage through 'Call any of the AFL StatsPro operations' and 'Read afl://statspro/operations for the list,' giving context on how to discover operations. However, it does not explicitly say when to use this tool instead of the many dedicated AFL sibling tools, nor does it mention exclusions or preferred 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, openWorldHint, and idempotentHint. The description adds valuable context beyond those flags: 'Auth: none needed' and a concrete return shape '{teams:[...]}', which help the agent understand what to expect without contradicting 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 compact and well-structured: one sentence for purpose, one for return format, one for auth. Every sentence earns its place with 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?

For a simple get-by-id tool with one parameter, strong annotations, and no output schema, the description covers the essential aspects: purpose, return shape, and auth. It lacks explicit error behavior or field-level explanations, but these are not critical for basic selection and 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%, and the teamId parameter is already well described with an example ('e.g. 1 = Adelaide Crows') and a URL path note. The description only echoes 'by id' without adding new meaning, so the 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 clearly states the tool fetches a single team by id, with a specific verb ('Get') and resource ('a single team by id'). It adds 'incl. social/home-venue metadata' to differentiate from list/mapping siblings like afl_teams_list and afl_teams_idmap.

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 establishes clear context: use when you have a specific teamId and need a single team's details, including metadata. However, it does not explicitly name alternatives or exclusion cases (e.g., use afl_teams_list for multiple teams), so it stops short of full guidance.

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

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

Annotations already declare readOnlyHint, openWorldHint, and idempotentHint, covering safety and side effects. The description adds useful behavioral context beyond these annotations, including the return shape ('Returns: {entityType:'team', idMapResponse:{ids:{'CD_T10':1, ...}}}') and authentication requirements ('Auth: none needed'). This enriches the agent's understanding without contradicting 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 concise and front-loaded: the main purpose is stated in the first sentence, followed by the return format and auth note. Every sentence provides distinct value with no redundant fluff, making it efficiently structured.

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

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

For a simple parameterless ID mapping tool, the description is complete. It explains the bidirectional mapping, provides an example return structure, and states authentication requirements. The annotations and schema cover the rest, making the description sufficient for an agent to know when and how to 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 input schema has zero parameters, and the description correctly implies no inputs are required. With no parameters to document, the baseline of 4 is appropriate; the description adds value by noting the tool takes no arguments, which is consistent with 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: 'Map CD_T* team providerIds to integer aflapi ids (and vice versa).' This identifies the specific resource (team provider IDs) and the operation (mapping to integer AFL API IDs), distinguishing it from sibling ID mapping tools like afl_matches_idmap and afl_players_idmap.

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 usage when a user needs to convert between CD_T* team provider IDs and integer aflapi IDs, but it does not explicitly state when to use this tool over alternatives or provide exclusion criteria. The intended use is clear from the purpose, but no explicit guidance is given.

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

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

Annotations already declare readOnlyHint and idempotentHint, so the description does not need to repeat that. It adds useful context by stating 'Auth: none needed' and providing the return structure, which goes 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 extremely concise, covering purpose, scope, return shape, and auth in just two short sections. Every sentence earns its place with no filler.

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

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

For a simple list tool, the description is complete: the schema documents pagination, annotations cover safety, and the description provides return shape and auth. No additional context is needed.

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 fully describes both parameters (page and pageSize) with defaults and descriptions at 100% coverage. The description adds no extra parameter semantics beyond what the schema already provides.

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 'List teams' with a specific scope (150 incl. AFL men, AFLW, state leagues, historical), which distinguishes it from related team tools like afl_teams_idmap or afl_clubs_list.

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 provided about when to use this tool versus alternatives such as afl_teams_idmap or afl_clubs_list. The description only lists what the tool does and auth requirements, not when to select it.

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