Zakazat Zvezdu — book pop stars

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

Annotations already declare readOnly, idempotent, non-destructive and closed-world, so the safety profile is covered. The description adds genuinely non-obvious behavior: contact data is deliberately withheld, and the fee shown is only an approximate guideline ('ориентир гонорара') rather than a quote — both prevent wrong agent conclusions. It does not cover not-found/error behavior, which keeps it from 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?

Two sentences, no filler, with the payload contents front-loaded and the constraint/redirect second. The field enumeration is dense but earns its place because no output schema exists; a lighter touch on the list would have been marginally cleaner.

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

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

With no output schema, the description correctly compensates by describing the returned fields, and it closes the obvious user-intent trap (contact/price requests) by pointing to the request form. Remaining gaps are minor: no statement about which parameter wins when both are passed, and no not-found behavior.

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

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

Schema coverage is 100% and both parameters are optional with their own descriptions, so the schema carries the semantics. The description adds nothing about url vs slug, such as which takes precedence when both are supplied or that either alone is sufficient; 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 names the resource (artist card) and enumerates exactly what the card contains — description, genre, lineup, repertoire/skills, tags, photo, video flag, fee guideline, link — so an agent knows the shape of the result without opening a schema. It does not explicitly contrast itself with search_artists or list_categories, but the slug parameter and the 'detailed card' framing make the distinction inferable.

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 when-not and a redirect: contacts are not returned, and for price and available dates the agent must use the request form on the card page. That is a concrete exclusion plus an alternative channel, which is more than most definitions offer; the only gap is that it never says to call this after search_artists to resolve a slug.

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, non-destructive and closed-world, so the safety profile is fully covered by structured data. The description's only addition is enumerating the returned fields, and it says nothing about freshness, size, or stability of the category set. Adequate but not rich, hence 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?

A single front-loaded sentence that names the resource first and the consuming tool last. Dense but every clause carries information; no filler 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?

With no parameters, no output schema, and annotations covering the safety profile, the description supplies what is missing: the returned field names and the purpose (search_artists filters). Complete enough for an agent to invoke it correctly, though it could note how often the catalog changes.

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 per the baseline for parameterless tools a 4 applies. The description does not need to explain any parameter syntax and correctly does not attempt to.

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 resource and its two halves: catalog genres (with returned fields slug/name/artist count/link) and collection-tags (repertoire, languages, event types). An agent can tell it apart from search_artists (consumer of this data) and get_artist. It is not explicitly differentiated from list_cities, the other list_* sibling, which keeps it from 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?

It gives a clear purpose: the output feeds the filters of search_artists, which effectively tells the agent when to call it. There is no explicit when-not or stated alternative, but the context 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?

The annotations already declare readOnly/idempotent/non-destructive/closed-world, so the safety profile is covered. The description adds genuinely useful behavior: the exact card fields returned, the cap of 10 results, and the ordering rule (catalog recommendations, then popularity) — none of which appears in structured fields. It omits how the q field matches across name/genre/description.

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 short sentences: purpose, return shape, ordering, and a routing pointer to get_artist. Nothing is redundant and the search capability is front-loaded before the return 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?

With no output schema, the description correctly compensates by enumerating the returned card fields and ordering, and annotations cover the safety profile. The remaining gap — how filters combine and where slugs come from (list_categories) — is documented in the schema but not echoed here.

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 enums and per-parameter descriptions, so the schema already carries the parameter semantics. The description only restates 'по словам и фильтрам' and the 10-card cap, adding little syntax or matching behavior 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?

The description gives a clear verb (поиск) and resource (каталог «Заказать звезду»), then says what the tool returns (up to 10 artist cards) and which sibling to use for more detail (get_artist). An agent can tell this apart from get_artist without opening anything.

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 establishes the search-by-words-and-filters use case and routes deeper lookups to get_artist. It lacks explicit guidance on when not to use it and does not mention list_categories as the source of category/tag slugs, which the schema hints at but the description does not reinforce.

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