Duoly

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

Annotations already declare readOnlyHint, idempotentHint, and destructiveHint=false, so the safety profile is covered by structured data. The description still earns credit by pre-empting the biggest misinterpretation of the name "create_booking_link" — it explicitly states that no order is created, no capacity is reserved, and no money is charged, which an agent would otherwise assume from "create" + "booking".

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 zero padding; the positive purpose comes first and the disambiguation caveat immediately follows. Nothing could be removed without losing signal.

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

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

With an output schema present the return value need not be explained, and the schema fully documents both parameters. The description covers purpose and the key non-effects; the only minor gaps are link lifespan/expiry and any prerequisites around the referenced game and service, which would help the agent 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 both parameters already carry clear descriptions (game id/slug from list_games, service id from list_services). The description adds no meaning beyond the schema — no mention of how the two parameters interact or whether service is required for certain games — 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 gives a specific verb ("Build") and an artifact ("website selection link"), which tells the agent it generates a URL rather than performing a transaction. The negative clause further separates it from get_quote/get_availability, though "website selection link" is slightly less crisp than the tool name's "booking link" and the two framings must be reconciled by the reader.

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 only implied: the agent can infer this is for handing a customer a link to pick a slot themselves. There is no explicit when-to-use statement, no mention of what must exist first (a game and optionally a service id), and no routing to siblings such as get_quote for a priced offer.

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 non-destructive, so safety is covered. The description adds genuinely useful context beyond that: counts are 'cached' and 'public', and there is a 'sitewide historical median' alongside them, which tells the agent the data may be stale and non-specific. It doesn't state staleness windows or that an absent game yields sitewide results.

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 no filler, and the caveat is placed last where it belongs. However, front-loading is weak: the operative object ('counts') is buried and the tool's subject (a game) never appears.

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

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

An output schema exists, so return values needn't be explained, and annotations cover the safety profile. What remains missing is minor but real: the behavior when game is omitted, and the distinction from get_quote for an agent choosing between them.

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 param already references list_games for id resolution. The description adds nothing about the game parameter — notably it never clarifies what happens when game is omitted, despite the param being optional (0 required).

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

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

The description names the resource ('cached public online counts' and 'sitewide historical median') but the verb is implicit — 'Read' appears only in the title. It doesn't mention the required game parameter or clarify how this differs from get_quote, which is the closest sibling and might also be assumed to return availability.

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 guidance and no mention of alternatives. The caveat 'Counts do not guarantee a match' hints at a caveat-usage context but never says to prefer get_quote for a firm quote or list_games to resolve ids.

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, so the safety profile is covered. The description adds meaningful context that no reservation or payment side effect occurs, which is the key behavioral fact an agent needs. It does not mention pricing volatility, rate limits, or error conditions such as invalid game/service pairs.

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 zero filler, and the primary purpose is front-loaded in the first clause. It is perhaps terse to the point of under-specification rather than verbose, so structure is good but content could be expanded.

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

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

An output schema exists, so return-value explanation is not required, and annotations cover the read-only/idempotent profile. But with 7 parameters, 5 required, and only 43% schema coverage, the description leaves an agent guessing about rank, edition, and quantity semantics and about which sibling to call first to obtain valid game/service ids.

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

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

With schema description coverage at 43%, several parameters (rank, edition, currency, quantity) carry no description, so the description could compensate but does not mention any parameter at all. It does add the framing of 'base price before account perks', which implies pricing depends on the supplied service/quantity/currency combination, but gives no detail on rank, edition, or the currency enum's effect.

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+resource ('Calculate a base price preview') and immediately scopes it ('before account perks'), which distinguishes it from create_booking_link. It does not explicitly name or contrast with siblings like get_availability, leaving sibling differentiation implicit rather than stated.

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 by 'preview before account perks' and the negative constraint that it does not reserve a teammate or start payment — an agent can infer this is a pre-purchase estimate step. However, there is no explicit guidance on when to prefer it over get_availability or create_booking_link, nor on prerequisite calls to list_games/list_services beyond what the schema hints.

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, destructiveHint=false and openWorldHint=false, so the safety profile is fully covered. The description adds one piece of real behavioral context beyond that: social sessions are filtered out of the results, plus the note that entries carry canonical page links. It says nothing about ordering, pagination, or result volume.

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 no filler, and the scope exclusion is stated up front. It is efficiently sized, though slightly over-terse for a listing tool whose result set is otherwise uncharacterized.

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

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

An output schema exists, so the description need not explain return values, and zero parameters means no input burden. Still, for a listing tool it leaves gaps that matter operationally: no sense of ordering, pagination, or how 'games' relates to the booking siblings it will usually be called alongside.

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 of 4 applies. The description correctly makes no attempt to describe inputs and instead spends its words on result scope.

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

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

States a clear verb and resource ('List Duoly games') and adds scope detail via 'canonical page links' and the exclusion of social sessions. However, 'games' is never defined and the description does nothing to distinguish it from the sibling list_services, so an agent cannot tell from the text alone which listing it should call.

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 when-to-use guidance, no mention of the sibling tools (create_booking_link, get_availability, get_quote, list_services), and no stated conditions for choosing this listing over list_services. The only routing hint is a negative scope constraint ('social sessions are excluded'), which is not usage 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 cover the safety profile (readOnly, idempotent, non-destructive, closed world), so the description adds only modest context: 'static' tells the caller these are not live availability results, and 'quote requirements' hints at a downstream get_quote step. It says nothing about result size, pagination, or what happens with an invalid game id.

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 front-loaded sentence with no filler, and the scope constraint ('for one game') appears before the return-content clause. The packed list 'exact rank and region tokens and quote requirements' is slightly dense but each 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?

With an output schema present, the description needn't explain return values, and it correctly focuses on scope and the nature of the response. What remains thin is workflow guidance about using the returned tokens with get_quote, but that is a minor omission for a simple single-parameter read 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?

Only one parameter and the schema fully documents it ('Game id or slug from list_games'), so the schema carries the semantics. The description's 'for one game' is consistent but adds no new meaning; baseline for a single fully-described param 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 and resource ('List static bookable services') plus the scope constraint ('for one game') and names the payload the caller gets back (rank/region tokens, quote requirements). An agent can distinguish this from get_availability because 'static' signals catalog data rather than live slots, though no sibling is named explicitly.

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 only implied: 'for one game' signals that a game id must be obtained first, and the schema note points at list_games. There is no explicit when-to-use versus get_availability/get_quote routing, and no statement of what to do with the returned tokens.

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