Whistle.day - Tournament organizer

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

Annotations declare readOnlyHint=false, destructiveHint=false, and idempotentHint=false. The description adds that courts are needed for organization but doesn't disclose side effects, permission requirements, or idempotency behavior beyond what annotations state.

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?

Single sentence with no waste, front-loading the purpose and then the domain rationale. Efficient and clear.

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 create tool with full schema coverage and annotations, the description provides adequate context about why courts matter. Missing only minor details like whether it returns an ID or what constraints exist, but complete enough for correct invocation.

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

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

Schema coverage is 100%, so the schema already documents all three parameters. The description mentions 'update_fixture's court argument' but doesn't add syntax or format details beyond the schema. Baseline 3 is appropriate.

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

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

States a specific verb+resource ('Add a court, pitch or table') and clarifies with domain context that this is what the schedule and projector organize matches by. Clearly distinguishes from siblings like add_entry or create_display.

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?

Explains the consequence of not adding courts and implies usage through the dependency on update_fixture. Doesn't name explicit alternatives (e.g., list_courts) but provides clear context for when it's needed.

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

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

Annotations declare a non-read, non-idempotent, non-destructive write (readOnlyHint=false, idempotentHint=false, destructiveHint=false). The description adds no behavioral context beyond that: it does not state that the tournament must exist, whether duplicate entries/seeds are rejected, or anything about the response. The one-word 'add' carries no extra disclosure.

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

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

A single short sentence, front-loaded with the action. 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?

For a non-idempotent write with no output schema and no annotations covering error/idempotency semantics, the description is too thin. It never says what happens on repeat calls or invalid tournaments, leaving the agent to guess.

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 per-parameter descriptions (name, seed, tournament_id), so the schema does the heavy lifting. The description adds nothing about parameter formats or constraints, which is acceptable at full 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?

Specific verb (add) and resource (team/participant to a tournament), so the purpose is clear at a glance. It does not differentiate itself from siblings like create_tournament or add_court, but no sibling overlaps directly with adding an entry.

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

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

No when-to-use guidance, prerequisites, or alternatives. Nothing tells the agent that a tournament must already exist, or that list_entries is the read-side counterpart.

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 is consistent with annotations (readOnlyHint=false confirms creation). It adds the useful prerequisite that the tournament must be published, which is behavioral context beyond the annotations. But it does not disclose mutation side effects, permission requirements, or token/name handling beyond what the schema already provides.

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?

A single front-loaded sentence with no wasted words. It communicates the action, resource, and key condition efficiently.

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 a simple 3-parameter create operation with full schema coverage and informative annotations, the description covers the core purpose and a key prerequisite. It omits any mention of what is returned or how the created display is used, which is a minor but real gap for a creation tool with no 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 description coverage is 100%, so the schema already documents all three parameters including defaults for name and token. The description adds no parameter-level detail beyond referencing the published tournament, matching the baseline when the schema does the heavy lifting.

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

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

The description states a specific verb and resource: 'Create a projector display screen.' It also scopes the operation to a published tournament, which distinguishes it from generic create tools. It does not explicitly name or differentiate against sibling tools, so it lands just below the top score.

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 'for a published tournament' implies a prerequisite condition, giving some usage context. However, it does not state when to use this tool versus alternatives or when not to use it, leaving guidance at an implicit level.

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

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

Annotations declare destructive/non-idempotent, and the description goes well beyond them: single use, expiry, and the critical consequence that the connection loses the ability to change the tournament afterward. That irreversible hand-off consequence is exactly the context an agent needs before invoking a destructive 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?

Front-loads the action and outcome, then layers precondition and consequence. Every sentence carries information, though phrasing like 'which is the point' is mildly conversational and could be tightened.

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 destructive tool with no output schema, the description covers what is produced (a link), how it is consumed, its lifetime, and the loss of control afterward. Nothing needed to invoke it correctly is missing.

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

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

Schema coverage is 100% for the single tournament_id parameter, so the schema already documents it. The description adds no format or selection guidance for the ID itself, 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?

States a specific verb (make a link) and the resource/outcome (hands this tournament to a person), and the mechanism (recipient sets email/password, the session's account becomes theirs). This is clearly distinguishable from siblings like publish_tournament or create_tournament.

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

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

Explicit timing guidance ('hand it over when the tournament is ready rather than when you are still building it') and an explicit precondition ('Only for a tournament made without signing in'), plus the reason a signed-in account doesn't need it. When/when-not and the implicit alternative are all covered.

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

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

Annotations declare readOnlyHint=false, idempotentHint=false, destructiveHint=false, giving the agent the safety profile. The description adds no behavioral context: it doesn't say what happens to existing stages, whether the tournament must be unpublished, or how position conflicts are handled. For a mutation tool, more is expected.

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?

A single front-loaded sentence with an illustrative example. No wasted words, though the example could be seen as slightly redundant with the schema's own example.

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

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

For a mutation tool with no output schema and no annotations beyond safety hints, the description is thin. It omits required context: tournament state prerequisites, position conflict handling, and what is returned. An agent would have to infer or guess these aspects.

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 all 5 parameters are documented in the schema with formats and examples. The description repeats the format example '(e.g. round_robin group)' but adds no syntax or constraint detail beyond the schema. Baseline 3 is appropriate.

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

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

Clear verb+resource: 'Create a stage in a tournament', with a format example. Distinguishes from siblings like get_stage/list_stages by naming the creation verb, but does not explicitly differentiate from other creation siblings like create_tournament or generate_stage beyond the resource noun.

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 alternatives. It's unclear whether create_stage is preferred over generate_stage, or what prerequisites exist (e.g., tournament must exist, must be in draft). The parenthetical example is illustrative, not prescriptive.

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 state it's not read-only, not idempotent, and not destructive. The description adds valuable context about temporary accounts tied to the connection and the persistence of the created resource, which goes beyond the annotations. It does not cover permissions or error conditions, so a 4 is appropriate.

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 core action, then explains the account behavior in a single sentence. No wasted words, though the sentence is slightly complex.

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

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

The description covers the creation behavior and account implications, which are the key points for an agent. With annotations covering safety hints and a complete schema, no output schema is needed. However, it could mention the draft status and typical next steps more explicitly.

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

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

Schema coverage is 100%, so the schema fully documents both parameters. The description adds no additional parameter semantics beyond what the schema provides. Baseline 3 is correct.

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?

Clearly states a specific verb+resource ('Create a draft tournament') and elaborates the account-scoping behavior. However, it does not differentiate from sibling tools like create_handoff or get_tournament beyond implicitly, 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 gives context about what happens when signed in vs not signed in, and mentions create_handoff as an alternative for ownership transfer, but does not explicitly say when to use this tool versus other sibling tools or when not to use it.

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

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

Annotations already disclose destructiveHint=true, idempotentHint=false, and readOnlyHint=false, so the safety profile is largely covered structurally. The description confirms that a non-dry-run call writes data, but it never states the key behavioral risk implied by destructiveHint: that regenerating overwrites or invalidates existing pools/slots/fixtures. With annotations carrying the baseline, this partial addition merits a 3.

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

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

Two short sentences with the core action front-loaded and no filler. The second sentence is somewhat redundant with the schema's dry_run description, which keeps it from being maximally economical.

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 two-parameter mutation tool with no output schema, the description omits what regeneration does to existing data and what a non-dry-run call produces. Annotations cover the safety flags, so the gap is not fatal, but a destructive generator should say more about its effects.

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% for both parameters, so the schema already documents stage_id and dry_run. The description's 'dry_run=true to preview without saving' merely restates the schema text, adding no format, constraint, or dependency information. 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?

States a specific verb (generate) and resource (pools, slots, fixtures for a stage), which is meaningful and distinct from a generic create. However, it does not differentiate itself from siblings such as resolve_stage, create_stage, or get_stage, so the agent must infer the boundary.

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

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

The only guidance is 'Use dry_run=true to preview without saving', which is a mechanic rather than a when-to-use rule. There is no statement of when this tool should be chosen over resolve_stage, create_stage, or update_fixture, and no prerequisites are given.

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

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

Annotations already declare readOnly, non-destructive, idempotent and closed-world, so the safety profile is covered. The description adds a hint that games are included in the result, but says nothing about pagination, missing-ID behavior, or payload size. With annotations doing most of the work, the added behavioral value is thin.

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?

A single seven-word clause with no filler, front-loaded with the verb and resource. It is efficient, though the phrase 'with games' is compressed to the point of being slightly ambiguous about whether games are always included.

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 tool with a full annotation set and complete schema coverage, the essentials are present. It lacks the minimal extras that would help an agent act confidently: what 'games' means in the response, and how to distinguish this from list_fixtures and the other get_* siblings.

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 single id parameter is documented as 'Fixture ID'), so the schema already carries the parameter contract. The description only restates 'by ID' without adding format, sourcing, or example values. 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?

States a specific verb (Get) and resource (fixture) and adds that it returns games along with the fixture. It doesn't differentiate itself from get_stage, get_stage_table, or get_tournament, which share the same 'get by ID' pattern, but the resource 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?

No guidance on when to use this versus list_fixtures or update_fixture, nor any precondition about what a fixture ID represents or where to obtain it. The agent must infer that this is a read-by-identifier lookup.

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

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

Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the safety profile is covered by structured data. The description adds the useful fact that pools are embedded in the response, but says nothing about behavior for missing IDs or error cases. With annotations carrying the safety burden, a 3 is appropriate.

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?

A single tight sentence that front-loads the operation and appends the key scope detail (pools). 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 simple single-resource read with full annotation coverage and full schema coverage, the description is nearly complete. It notes the notable payload extra (pools). No output schema exists, but for a trivial getter this is acceptable; only minor gaps around not-found behavior remain.

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 single id parameter is documented as 'Stage ID'. The description adds no format, validation, or sourcing detail beyond what the schema provides, so the baseline 3 applies.

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

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

States a specific verb (Get) and resource (stage by ID), and adds that pools are included. Clear enough to distinguish from list_stages and get_stage_table, though it doesn't explicitly name those siblings to sharpen the boundary.

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 – an agent can infer this is the fetch-single-stage tool versus list_stages or get_stage_table. No explicit when-to-use, when-not-to-use, or prerequisite 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 declare readOnlyHint, idempotentHint, and destructiveHint=false, so safety is covered. The description adds valuable behavioral context beyond that: the table is provisional and unseeded until every pool in the stage finishes, which is critical operational nuance an agent won't find in 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?

Front-loaded with the core operation, then supports it with the ranking structure and the provisional caveat. Two sentences, no waste, though the second sentence is slightly dense with embedded concepts.

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 read-only, idempotent, single-parameter tool with full schema coverage, the description is nearly complete. It covers what the tool returns, the ordering logic, and the provisional state. It does not explain return format in detail, but with no output schema that is a minor gap given the clear conceptual framing.

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 is only one parameter (stage_id), and schema description coverage is 100%. The description adds conceptual meaning by explaining what the stage-level table represents, though it does not clarify the parameter format. With a single fully-documented parameter, the baseline of 4 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 specific verb and resource ("Get a stage's cross-pool table") and explains the ranking structure. It distinguishes itself from generic siblings like list_standings and get_stage by defining exactly what ordering it returns, though it doesn't name those siblings directly.

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 through the conceptual explanation ("this is what 'the best third-placed teams' is decided on, and what a stage_rank slot reads"), but there is no explicit when-to-use versus get_stage, list_standings, or list_pools. An agent must infer that this is the right tool for cross-pool ranking.

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

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

Annotations already declare readOnlyHint=true, idempotentHint=true, destructiveHint=false, and openWorldHint=false, fully covering the safety and idempotency profile. The description adds no behavioral context beyond what annotations provide, so a 3 is appropriate given the lower bar 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 a single, concise sentence that front-loads the action and resource. It's efficient with no wasted words, though it's minimal rather than optimally structured for routing among many siblings.

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 read tool with full annotation coverage and schema documentation, the description is adequate. However, with many sibling tools (list_tournaments, get_stage, get_fixture), it doesn't help the agent disambiguate when to use this tool versus alternatives, leaving a contextual 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?

Schema coverage is 100% and the single 'id' parameter is fully documented in the schema as 'Tournament ID'. The description adds no meaning beyond what the schema already provides, so the baseline of 3 is correct.

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

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

The description states a specific verb ('Get') and resource ('a tournament by ID'), making the retrieval operation clear. It doesn't explicitly differentiate from the sibling list_tournaments, but the 'by ID' phrasing implies single-item retrieval versus listing, which provides some differentiation.

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

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

The description implies usage (fetch a single tournament when you have its ID) but doesn't specify when to use this versus list_tournaments or other get_* siblings. No explicit when/when-not guidance or alternative naming 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 declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, covering the safety profile. The description adds the contextual note that the ids serve as input for update_fixture, which is useful but not a rich behavioral trait. It does not describe return format, pagination, or error handling.

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

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

Two concise sentences: the first defines the resource, the second adds a critical integration point. No wasted words, and the key relational 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?

The tool is simple (one parameter, read-only) and annotations already cover its safety. The description explains the relationship to update_fixture but lacks details on return structure (no output schema) or pagination behavior. Given the simplicity, it is adequate but not fully complete.

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

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

Schema coverage is 100% with the single parameter tournament_id fully documented in the schema. The description does not provide additional semantics for this parameter, so the baseline score 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 what the tool returns ('the courts a tournament is played on') which implies a list operation, and connects its output to another tool. However, it does not begin with a clear verb like 'List' and relies on the name 'list_courts' to establish the action.

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

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

The description explicitly links to the sibling tool update_fixture by explaining that the returned ids are used as its court argument. This provides clear guidance on when to use this tool, but there is no mention of when not to use it or other 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 declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, fully covering the safety and side-effect profile. The description adds no behavioral context beyond what annotations provide—no pagination details, output format, or ordering information. With annotations doing the heavy lifting, this meets the minimum bar but adds little value.

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?

A single, front-loaded sentence that clearly states the tool's action and resource. No wasted words, though it is arguably under-specified rather than optimally concise for an agent needing to distinguish it from siblings.

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 read-only list tool with no output schema, the description is insufficient. It does not explain what an 'entry' contains, whether the list is paginated or complete, or how the result relates to tournaments. Given the rich set of sibling tools and potential for confusion, more context is needed to call this tool correctly.

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

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

Schema coverage is 100%, so the single parameter (tournament_id) is fully documented in the schema. The description adds no additional meaning about the parameter's expected format or constraints. Baseline 3 is appropriate when the schema already provides complete parameter documentation.

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

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

States a generic verb+resource ('List entries') with a parenthetical clarifying that entries are participants in a tournament. However, it does not distinguish this tool from its many siblings like list_courts, list_pools, list_stages, or list_tournaments. The scope is clear but lacks the specificity needed to confidently differentiate from similar list operations.

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 alternatives. The description provides no context about when listing entries is appropriate or how it relates to other tools like add_entry or list_standings. Without explicit usage conditions, the agent must infer intent.

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

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

Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the safety profile is covered. The description adds the filterable dimensions but says nothing about pagination, ordering, or result size, leaving modest gaps for a list 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?

A single front-loaded sentence naming the resource, scope, and filters with zero 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 simple filtered-list tool with full schema coverage, no nested objects, and annotations covering the safety profile, the description is nearly sufficient. Return shape and pagination are not addressed, but the operation's low complexity limits the impact.

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 round, status, pool_id, and stage_id each documented and the status enum values enumerated in the schema. The description only restates these filters, adding no syntax or format meaning beyond the schema, so the baseline 3 applies.

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

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

States a specific verb (List) and resource (fixtures), plus the scoping context (in a stage) and available filters. It does not, however, distinguish itself from siblings like get_fixture or list_standings, so an agent gets no explicit routing signal.

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 'in a stage' implies the usage context and the optional filters hint at narrowing scenarios, but there is no explicit when-to-use guidance and no mention of alternatives such as get_fixture for a single fixture.

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

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

Annotations declare readOnlyHint=true, idempotentHint=true, destructiveHint=false, and openWorldHint=false, fully covering the safety profile. The description adds no extra behavioral context like pagination, ordering, or rate limits. With annotations doing the work, this is adequate but minimal.

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

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

Four words, no waste. Front-loads the action and object. Very concise, perhaps too terse for completeness, but structurally sound.

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 operation with no output schema and no annotations explaining return shape, the description should ideally mention what a pool is or what the list contains. It's too sparse to be fully helpful.

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 a single well-described parameter 'stage_id'. The description references 'stage' but adds no format or constraints beyond the schema. Baseline 3 is appropriate.

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

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

States a specific verb 'List' and resource 'pools' scoped to a stage. However, it doesn't distinguish from siblings like list_courts, list_entries, list_fixtures, list_stages – all have the same pattern, though the resource nouns differ. A bit more specificity about what a 'pool' is could help, but purpose is clear enough.

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 alternatives. It doesn't say it returns all pools in a given stage, whether there are variants, or prerequisites. Just a bare statement.

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

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

Annotations already declare readOnlyHint, idempotentHint, openWorldHint false, and destructiveHint false, so safety and idempotency are covered. The description adds nothing beyond the name — no note on ordering, pagination, or what a stage contains.

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

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

Single short sentence, front-loaded and waste-free, though it is almost too terse to carry useful 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?

A simple read tool with full annotation coverage and a complete one-param schema; the description is minimally sufficient. It could mention ordering or the relationship to other stage-listing tools but does not.

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 parameter is documented in the schema. The description adds no semantics beyond what the schema provides, 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?

States a specific verb (List) and resource (stages) scoped to a tournament, which is clear. It does not differentiate from the sibling get_stage or list_standings/list_pools, which an agent might confuse when looking for stage-related data.

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

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

No when-to-use guidance, no mention of alternatives like get_stage (single stage) or list_pools/list_standings. The agent must infer that this lists all stages given a tournament.

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

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

Annotations declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, covering the safety profile. The description adds no behavioral context such as what 'standings' include, whether results are paginated, sorted, or if the pool must be published.

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?

A single, front-loaded sentence with zero waste. It is appropriately sized for the tool's simplicity.

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 22 sibling tools and no output schema, the description is too sparse. It doesn't explain what standings contain (e.g., rankings, points, wins/losses), whether the pool must be in a particular state, or how results are ordered.

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 pool_id fully documented in the schema. The description mentions 'pool' but adds no syntax or format details beyond what the schema already provides, 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 states a specific verb 'List' and resource 'standings', scoped to a pool. It is clear, but it does not distinguish this from sibling list tools like list_pools or list_entries beyond the resource name.

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 get_stage_table or other list tools. The description only states what it does, not when it is appropriate.

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

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

Annotations already declare readOnlyHint=true, idempotentHint=true, openWorldHint=false, and destructiveHint=false, so the safety profile is covered. The description adds that the result is scoped to tournaments the session can act on, which is useful authorization context, but it stops short of explaining what 'act on' means or what fields are returned.

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?

A single, front-loaded sentence with no filler. Every word carries meaning.

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 list tool with full annotation coverage and no output schema, the description is adequate but thin. The authorization scoping is mentioned but not defined, and the agent isn't told what the list contains or how it's ordered. Slightly more context would help routing against siblings.

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

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

The tool takes zero parameters, so the baseline is 4. The description correctly implies no filtering parameters, which matches the empty schema.

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

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

States a specific verb (list) and resource (tournaments), and qualifies scope with 'this session can act on' – which distinguishes it from get_tournament (fetch details) and create_tournament. It's clear but the scoping phrase is somewhat vague, and it doesn't explicitly differentiate from other list_* siblings like list_courts.

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 versus alternatives (e.g., get_tournament, list_entries). The phrase 'can act on' hints at an authorization filter, but it's not explained and there are no exclusions or prerequisites.

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

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

Annotations declare openWorldHint=true and idempotentHint=false, so the agent knows this is a non-idempotent, externally visible operation. The description adds that it changes status to 'live', which is mutation context beyond the annotations. However, it doesn't state whether this requires specific permissions, whether it can be undone, or what happens to already-live tournaments.

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

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

The description is a single, front-loaded clause with no wasted words, and it immediately delivers the action and its 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?

With one required parameter, an output schema absent, and annotations covering safety flags, the description is minimally complete: it tells the agent what the tool does and the key side effect. It omits workflow prerequisites and whether the operation can fail or be reversed, leaving gaps for an agent to fill.

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 there is only one parameter, so the schema fully documents 'tournament_id'. The description doesn't add format, source, or validation details beyond what the schema provides, making the baseline 3 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 clear verb ('Publish') and resource ('a tournament') and clarifies the effect ('set status to live'). It is distinguishable from siblings like create_tournament or update_fixture, though without naming an alternative it stops short of the sibling differentiation required for 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 phrase 'so the display works' implies when to use it (after creating a tournament, before showing it), but it doesn't explicitly state prerequisites, timing, or when not to use it. No alternative tool is named, leaving the agent to infer the workflow.

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

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

Annotations declare destructiveHint=true and readOnlyHint=false, so the agent already knows this mutates data. The description adds the key trigger context ('after correcting scores') that annotations can't convey. It doesn't disclose what specifically gets overwritten, which would raise this to 5.

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

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

Two short sentences, zero waste, with the action stated first and the usage trigger immediately after. Front-loaded and complete.

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

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

For a destructive, non-idempotent mutation on a single param, the description covers the trigger but omits what gets destroyed or whether the operation is safe to re-run. With no output schema and annotations only signaling destructiveness, a bit more disclosure would help.

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 one parameter (stage_id) already documented. The description adds no param syntax or format detail. Baseline 3 is appropriate when the schema does all the work.

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

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

States a specific verb (re-resolve) and resource (a stage's fixture propagation and standings), which is more specific than any sibling. It's not differentiated from siblings like generate_stage, but the purpose is clear.

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

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

Explicitly says 'Use after correcting scores,' giving a clear trigger condition. It doesn't name alternatives or exclusions, but the temporal guidance is concrete and actionable.

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

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

Annotations declare destructiveHint=true, non-idempotent, non-readonly, so the write/destructive profile is already known. The description adds that it settles matches via score/status, but says nothing about what gets overwritten, permission/auth needs, or irreversibility beyond the annotation. 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?

One short sentence, front-loaded with the verb and resource. Minimal but coherent; it earns its place without waste, though it is arguably too sparse given the tool's complexity.

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

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

A destructive, non-idempotent mutation with 6 params and no output schema needs more: it doesn't explain the optional params (court, winner, away_score/home_score) interaction, nor what happens on walkover vs finished status. Annotations cover safety but the description leaves meaningful behavioral gaps for an agent to 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%, so the schema already documents all 6 parameters including the enum-like status list. The description mentions only score and status, adding no syntax or format detail beyond the schema. 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?

Clear verb (Update) + resource (fixture) + fields (score, status), and parenthetical 'settle a match' adds domain context. It distinguishes from the read siblings get_fixture/list_fixtures, though it doesn't explicitly contrast with other mutation tools. Specific enough for an agent to select over reads.

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 parenthetical hints at settling a match, but there is no explicit when-to-use vs alternatives, no prerequisites (e.g., fixture must be live/ready), and no when-not-to-use. Sibling routing is left entirely to inference.

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