kicksmash

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

Annotations already indicate readOnly, idempotent, and non-destructive behavior, so the description does not need to repeat those. The description adds useful context about the tool's content coverage, including the API and expectations for assistants, which goes beyond structured annotations.

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

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

The description is a single, compact sentence that front-loads the purpose and immediately gives an actionable instruction. It lists the covered topics efficiently without wasting 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 zero-parameter informational tool, the description is complete: it states what the tool is, what topics it covers, and how the assistant should use it. No output schema or parameter fields create additional requirements, and the annotations already cover the safety profile.

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

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

The tool has zero parameters and 100% schema description coverage, so there is no parameter burden for the description to carry. Baseline for zero-parameter tools is 4, and the description appropriately avoids inventing unnecessary parameter details.

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 an informational onboarding resource: 'What Kicksmash is and how to use it' with a concrete list of covered topics. It is immediately distinguishable from the action-oriented sibling tools like create_match or find_matches.

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

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

It gives an explicit usage instruction: 'Read this once before acting,' which tells the agent when to invoke it relative to other operations. It does not explicitly name alternatives or conditions to skip it, but its role as a prerequisite resource is strongly 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?

Description reveals the key is shown once and is free, adding context beyond the annotations; there is no contradiction with readOnlyHint false.

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 terse sentences deliver the purpose and key caveats without 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?

Provides enough context to call the tool, including the one-time display caveat, though no output schema or error/usage limits are specified.

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 covers 2 of 3 parameters with meaningful descriptions, but the description adds no parameter guidance and the email parameter lacks a 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?

Title and description clearly state the tool creates/gets a free API key, distinct from sibling tools focused on matches, clubs, and schedules.

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 a key is unnecessary for read-only or light write usage and is intended for higher limits and webhooks, though it does not name alternative 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?

Beyond the annotations, the description discloses meaningful behavior: it returns a share link plus private organizer links, and it warns to keep personalToken and manageUrl private. The consent requirement is also important because this is a creating action. It could add more about side-effect scope, but it already goes beyond the structured hints.

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

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

Two sentences carry the purpose, output behavior, privacy instructions, and the one-request rule. Every clause earns its place, and critical guidance 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 19-parameter creator with no output schema, the description adequately states what is returned and what safety behavior is expected. Optional settings are left to the input schema, which is acceptable, though a bit more detail about the created object's lifecycle would improve completeness.

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 many parameters, and the description adds only a little semantic value, such as 'match means 4 players' and 'tournament means americano.' With 68% schema coverage, some parameters like note, title, venueMapUrl, and levelMax remain undocumented in both the schema and description, so the description does not fully compensate.

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 ('Create') and names the two resource types: a padel match (4 players) or an americano tournament. It also states the return artifact, clearly distinguishing this from sibling read/join tools like get_match and join_match.

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 useful guardrails ('Ask before creating; one request, one match') and clarifies the creation context. However, it never explicitly contrasts this tool with alternatives like join_match or generate_schedule, so the agent must largely infer when to choose this over siblings.

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

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

Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the safety profile is covered. The description adds useful behavioral context about the data source ('club pages that clubs manage themselves') and conditional availability ('today's free courts when the club shares its calendar'), which goes beyond the 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 a single, dense sentence that front-loads the key content and then states the two filter options. Every word earns its place; there is 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 read-only lookup with two optional parameters and no output schema, the description provides enough content for correct invocation. The only minor gap is that it does not explicitly state the behavior when neither filter is provided, but the filter language implies both are optional.

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 both parameters. The description restates that city and name are the two filter modes but adds no new detail beyond what the schema provides. 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 ('find') and resource ('clubs'), then details what club pages contain (booking link and platform, courts, today's free courts, founding status). This clearly distinguishes it from sibling tools like find_matches, which target matches rather than 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 gives clear usage context: filter by city (phuket, singapore) or query a single club by name. It does not explicitly name alternatives or say when not to use this tool, but the context is strong 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?

Annotations already declare readOnlyHint, idempotentHint, and destructiveHint, so the safety profile is covered. The description adds useful behavioral context beyond those annotations: matches are organizer-listed, the board is public, results include spots left and level ranges, and the slug is derived from the venue name.

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

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

The description is a single compact sentence that front-loads the core purpose, states the key output fields, and gives the input convention. It contains no filler and does not repeat what the annotations or schema already say.

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

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

For a single-parameter, read-only tool with no output schema, the description supplies the essential return information (open matches, spots left, level ranges) and the input derivation rule. An agent has enough context to select and invoke the tool correctly without obvious 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 coverage is 100%, so the schema already documents the venue parameter well. The description adds value by explaining that a venue name is sufficient because the slug is derived, which is not explicit in the schema and helps the agent construct a correct call.

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 title and description together identify a specific operation (find) on a specific resource (open, organizer-listed matches at a venue), and the public-board wording distinguishes it from sibling tools like find_clubs and get_match. The mention of spots left and level ranges further clarifies what kind of match listing this returns.

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

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

The description clearly scopes the tool to a venue's public match board and instructs the user to provide the venue name, but it does not explicitly state when to prefer this over find_clubs, get_match, or join_match. The usage context is implied rather than stated with exclusions or alternatives.

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

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

Annotations already declare readOnlyHint and idempotentHint, so the description does not need to restate those. It adds valuable behavioral context by stating 'Nothing is stored' and by specifying exactness conditions for fields in fours versus 'fair sit-outs otherwise.'

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

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

Three short sentences deliver the core purpose, behavioral guarantees, and persistence semantics with no filler. The most important information is front-loaded before the fairness details.

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 stateless, read-only generator with optional parameters, the description covers purpose, player range, schedule properties, and non-persistence. It does not explicitly describe the output format, but the phrase 'rounds of rotating-partner doubles' strongly implies the return value, and the schema covers the remaining parameter details.

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

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

The schema already documents seed, courts, rounds, and players, while the description adds context about 'players−1 rounds' and fairness behavior linked to player count. However, it does not clarify the meaning of names, format, or courts beyond what the schema provides, and schema coverage is only 67%.

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 title supplies the verb 'Generate' and the description names the resource: 'rounds of rotating-partner doubles for 4 to 64 players.' This clearly identifies what the tool produces and is not confusable with the listed siblings, none of which involve schedule generation.

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 explains what the tool does but gives no guidance on when to choose it over alternatives, nor any explicit context such as prerequisites or exclusions. The only usage signal is the implicit one from the title, which is weak.

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 useful context about what kind of data is included (members, levels, weekly slot, upcoming matches, calendar feed), but it does not disclose error behavior, authentication needs, or response shape beyond these contents.

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 short and mostly to the point, but the opening phrase 'A crew that plays together' is decorative and adds little operational meaning. The useful content appears after the colon, making it less front-loaded than it could be.

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 read tool with strong annotations, the description gives a reasonable sense of what the response contains. However, it lacks explicit usage context, does not state that this is a direct lookup by code, and provides no detail about failure behavior or returned data structure, which an agent might need since there is 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?

The input schema fully documents the only parameter 'code' with type, length constraints, and the description 'The code from the link.' Since schema coverage is 100%, the description does not need to add parameter details; 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 title 'Get a group' and description 'A crew that plays together: members with levels, weekly slot, upcoming matches, calendar feed' make it clear this tool returns group details by code. It is distinguishable from sibling get_match by focusing on group/crew contents rather than match data, though the description never explicitly states the retrieval 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 gives no guidance on when to use this tool versus siblings like get_match, find_clubs, or join_match. The only contextual clue is the parameter description 'The code from the link,' implying a direct lookup by code, but no alternatives or exclusions are mentioned.

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 the tool read-only, idempotent, and non-destructive. The description adds that the operation is public, which signals no special auth is needed, and enumerates the returned data (players, spots left, venue, time, level range, result), which is valuable since there is no output schema. No contradiction with annotations.

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

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

A single dense sentence front-loads the resource and key, then lists the returned fields with no redundant wording. Every clause contributes information.

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

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

For a one-parameter, read-only getter with annotations covering safety, the description is complete: it states the input, the data scope, and the relevant output fields. Since there is no output schema, the explicit field list is especially important and is present.

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 'code' as 'The code from the link' with 100% coverage, so the description adds little. The claim of a '4-character code' is slightly inconsistent with the schema's minLength 4 / maxLength 6, creating minor ambiguity. No enum or nested structure to explain.

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 (a match or tournament) and the lookup mechanism (4-character code), and lists the fields returned. However, it is phrased as a noun phrase rather than an explicit verb-led statement such as 'Retrieves...', and it doesn't explicitly differentiate itself from sibling lookup tools beyond the code-based access.

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 right use case: use this when you already have a match/tournament code and need its details. It does not explicitly name alternatives like find_matches or state exclusion criteria, but 'by its 4-character code' and 'public data only' provide clear context.

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

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

Annotations only mark this as non-read-only, so the description adds value by disclosing waitlist handling, level-range behavior, and organizer approval when the level is out of range. It does not cover every side effect, but the key non-obvious behaviors are surfaced.

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

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

Two sentences front-load the main action and then add the two important edge behaviors (waitlists and approval). There is no redundant or filler content.

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

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

Together with a fully descriptive schema, the definition gives an agent the essential call context: required code, person identification by name or token, optional email, and level behavior with approval. It lacks an explicit note about success/response, but no output schema exists and the invocation path is otherwise well specified.

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 schema already explains code, the name/token condition, optional email, and level. The description reinforces the name-vs-token choice and level-range context but does not add 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?

The description states a specific action ('Put a person into a match'), identifies the resource (a match by code, person by name/token), and distinguishes it from siblings like create_match and find_matches. The waitlist/level-range behavior adds further specificity.

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

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

It clearly indicates this is for adding an existing person to an existing match using a match code, with token as the alternative for known players. It does not explicitly contrast with siblings such as create_match, but the intended context is clear.

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