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

With no annotations and no output schema, the description carries the full burden. It usefully discloses the verbatim-title rule, the personal-calendar default, and the NO_REPLY output convention — which is the only hint about return behavior — but says nothing about error handling, duplicate events, date validation, or what a successful result looks like beyond the NO_REPLY special case.

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 front-loaded sentences with no filler: scope and exclusion first, then the output-handling rule. Every sentence changes what the agent does.

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 five-optional-parameter creation tool with no output schema, the description covers the two things the schema cannot: sibling disambiguation and the NO_REPLY response protocol. Failure/validation behavior is the main remaining 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 description coverage is 100%, so the schema already defines all five parameters in detail, including the verbatim-title instruction and the empty-means-personal default. The description restates the title-preservation and personal-calendar semantics but adds no format, ordering, or interaction details 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?

States a specific verb and resource (add event), narrows the scope to plain/non-concert events, and names the sibling that handles the excluded case (concert_add). An agent can route between calendar_add and concert_add without opening either schema.

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

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

Explicit exclusion with a named alternative: 'For a concert ticket use concert_add instead.' The positive case is only implied by 'plain (non-concert) event', and no guidance is given relative to the other siblings (event_delete, queue_status), but the key routing decision is unambiguous.

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

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

With no annotations the description carries the full burden, and it discloses the non-obvious side effects an agent could not infer: playlist creation, an external setlist.fm lookup, and a chat reply. It also reveals the NO_REPLY sentinel output. It doesn't address re-run/duplicate behavior beyond "once per ticket" or permission needs, so not a 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?

Three tight sentences, front-loaded with the action and its effects, then the call contract, then the sentinel rule. Every sentence changes agent behavior and nothing is decorative.

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 5-param, zero-required, side-effect-heavy tool, the description covers inputs, call cadence, and the NO_REPLY outcome. With no output schema, it could say more about what a successful result looks like, which is the one meaningful 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 already 100%, so the baseline is 3; the description still adds value by naming which fields to prioritize (artist, start, venue) and by telling the agent to pass whole unedited ticket text into source_text, which the schema alone frames less directive.

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?

A specific verb+resource (add a concert to the calendar) followed by an enumeration of bundled side effects (teaser playlist, setlist.fm lookup, chat reply) that makes the composite nature unmistakable. It doesn't name a sibling, but the side-effect list implicitly separates it from plain calendar_add.

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?

"Call once per ticket" and "as read from the ticket" give explicit invocation guidance, plus the NO_REPLY handling rule. It stops short of saying when to prefer calendar_add or how to handle non-ticket events, so no real exclusion criteria.

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

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

destructiveHint=true already flags the write; the description adds behavior annotations can't express — the multi-turn disambiguation loop and the contract that a NO_REPLY-prefixed result must be answered exactly NO_REPLY. It doesn't state whether deletion is permanent or requires confirmation, which is the remaining gap.

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

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

Three sentences, zero filler, with the core action front-loaded and the flow and sentinel rules following in priority order.

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?

No output schema exists, and the description covers the two result shapes that matter (numbered match listing and NO_REPLY sentinel). It leaves unstated what a successful deletion returns, a minor omission for a 3-param tool.

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

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

Schema coverage is 100%, so the baseline is 3, but the description adds workflow meaning the schema lacks: pick only makes sense on a re-invocation after a numbered listing. That relational timing is the real added value.

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

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

Uses a specific verb and resource ("Delete one calendar event") and states the lookup key (artist or title). An agent can distinguish it from calendar_add and concert_add without reading any schema.

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

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

Gives an explicit procedural condition: when several matches exist the tool lists them numbered and asks the user, and the follow-up call must pass that number as pick. It doesn't name alternatives or say when not to use it, which keeps it short of a 5.

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

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

readOnlyHint=true already signals a safe read, and the description adds genuinely new behavioral context: the response includes both presence status and per-item remediation, and the call is explicitly side-effect-free in scope (no parameters). It stops short of describing output shape or freshness of the checks.

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 covering scope and return value, followed by a short parameter note. No filler, nothing that could be cut.

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 zero-argument read-only probe with no output schema, the description covers what is checked and that fixes are returned. A brief word on result format or whether checks are live vs cached would close the remaining 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?

Zero-parameter tool, so the baseline is 4; the description reinforces this with an explicit 'Takes no parameters', removing any doubt the agent might have about needing input.

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 (report) and resource (credentials and tools present for four named services), plus the added value of remediation guidance. None of the siblings (teaser_playlist, setlist_find, queue_status, etc.) do this, so the agent can distinguish it immediately.

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 'what fixes each missing one' phrasing implies a diagnostic/setup-check use case, but the description never says when to call it (e.g., before attempting Spotify or Calendar operations) and names no alternatives or exclusions. Usage is inferable rather than stated.

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, so safety is covered; the description adds the one non-obvious behavior, that an empty queue yields NO_REPLY. It says nothing about ordering, whether results are counts or full concert records, or freshness of the queue.

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, front-loaded with the purpose. The NO_REPLY instruction is compressed to the point of being cryptic about what triggers it, but nothing is padded.

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 no-param, read-only, no-output-schema tool this is nearly sufficient; the remaining gap is the exact semantics of NO_REPLY (when it is returned and why it must be echoed verbatim), which is stated as a rule without explanation.

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?

Zero parameters, which is the baseline-4 case; the description correctly confirms 'Takes no parameters', matching the empty schema and preventing an agent from inventing filter arguments.

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: lists concerts awaiting the weekly setlist.fm check, which distinguishes it from setlist_find and the other siblings. The name queue_status alone is vague, but the description resolves that.

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 context of the weekly setlist.fm check implies this is the 'what's pending' query, but it never says when to call it versus setlist_find or teaser_playlist, nor any exclusions. Usage must be inferred.

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?

readOnlyHint=true is consistent with 'look up', and the description adds the external source (setlist.fm), the single-record scope, and a fallback ('NO_REPLY'). The fallback phrasing is cryptic — it doesn't say whether the tool returns NO_REPLY or the agent should emit it, nor what happens when no match exists — so it stops short of full 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?

Three short sentences, front-loaded with purpose and followed by routing and fallback. The final NO_REPLY sentence is compact but under-explained rather than wasteful.

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?

Read-only annotations and full schema coverage carry most of the burden, and no output schema exists to require return-value docs. However, all three parameters are optional with empty defaults and the description never says what a call with missing artist/date does, nor what 'one show' contains.

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 artist, date (YYYY-MM-DD) and venue tie-breaker are already documented in the schema. The description names artist and date but adds nothing about the venue tie-breaker or the meaning of empty defaults, 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 and resource ('Look up one show on setlist.fm by artist and date') and explicitly contrasts itself with the sibling concert_add. An agent can distinguish it from every listed sibling without opening a schema.

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

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

Gives an explicit when-not rule ('concert_add already does this') and the narrow condition that selects this tool ('call only when asked about a setlist alone'). Alternatives and exclusions are both named.

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

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

With no annotations, the description must carry behavioral disclosure. It usefully signals create-or-update semantics ('make or top up'), playlist contents, ordering, and naming, but does not mention Spotify auth requirements, side effects on an existing playlist, failure behavior, or rate limits.

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 compact sentences, front-loaded with the core action and followed by the alternative and special-case instruction. No wasted text.

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

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

For a two-parameter tool with a fully described schema and no annotations, the definition covers purpose, filtering, ordering, naming, the sibling alternative, and the NO_REPLY special case. It does not describe what the tool returns, but the gap is modest given the tool's simplicity.

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

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

Schema coverage is 100%, so the baseline would be 3, but the description adds meaning by showing that date and artist drive both the playlist name ('YYYY-MM-DD | Artist') and the song selection ('liked by the artist'). That is useful semantics beyond the schema's field-level descriptions.

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

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

The description states a specific verb and resource: make or top up a Spotify teaser playlist for one concert. It defines the exact contents, ordering, and naming convention, and explicitly distinguishes itself from concert_add.

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 routing rule: concert_add already does this, so call teaser_playlist only when the playlist alone is requested. The NO_REPLY instruction further disambiguates expected behavior.

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