Webtic

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

Annotations already declare readOnly, idempotent, closed-world and non-destructive, so the safety profile is covered. The description adds genuinely non-obvious behavior: only fields present in the data are returned and missing information must never be filled in, plus the temporal limitation that this reflects what is on sale, not when. It stops short of describing pagination or error behavior, which keeps it off 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?

Front-loads the return contents, then usage triggers, then the caveats about missing fields and absent schedule data — a sensible ordering with no filler. The opening field enumeration is long but every item maps to real returned content, so little could be cut without losing routing 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?

An output schema exists, so return shape needs no explanation, yet the description helpfully flags the sparsity caveat and the sale-vs-schedule distinction that the schema cannot express. With one required parameter fully documented and annotations covering safety, the only minor gap is how to obtain a valid eventId when it is unknown.

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 eventId parameter is already documented as coming from search_events, so the schema does the work. The description adds no format, validation or example detail about eventId, which is acceptable at baseline but not above it.

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 ('Returns the full information sheet of an event on sale on Webtic') and enumerates exactly what the sheet contains: plot, genre, year, duration, director, cast, author, company, trailer, poster, and scheduled provinces with venue counts. The scope boundary against get_event_venues and against schedule data is legible without opening 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?

Supplies concrete trigger questions ('what is X about', 'who is in X', 'how long is X', 'where is X showing') and an explicit exclusion: dates, showtimes and prices are not available here and live on the webtic.it links. It does not name sibling tools such as search_events for obtaining the eventId, so routing to alternatives is clear only for the schedule case.

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 readOnly/idempotent annotations, it discloses the fallback behavior when the event is not scheduled at the given venue (response says so and lists other venues in the province) and the data-freshness boundary (no dates, showtimes, or prices; those live on the webtic.it links). These are exactly the traits an agent could not infer from structured fields.

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 sentences, front-loaded with what is returned before use cases and caveats. Every sentence carries distinct information; nothing restates the tool name or the schema.

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, yet the description still summarizes the meaningful response shape (venues, versions, per-venue link, not-found fallback with alternatives), which is what an agent needs to plan a multi-step answer. Nothing required for correct invocation 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%, so baseline is 3; the description earns above that by explaining what venueId changes functionally — it switches to single-venue mode and makes the response contain the direct webtic.it link to hand to the user. The province/venueId precedence is already in the schema, so no extra credit there.

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 the venues ... where an event is currently scheduled') and names exactly what comes back: available versions and a link per venue. The closing sentence scopes it against adjacent data ('what is currently on sale, not when'), so an agent can tell it apart from get_venue_program or get_event_details without opening the 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 two concrete invocation patterns with quoted user intents ('where can I see X in Milan' and, with venueId, 'I want to see X at cinema Y') plus the negative case handled by the fallback clause. There is no ambiguity about when to call it or which parameter selects which mode.

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 readOnly/idempotent/no-destruction, and the description adds the single most important behavioral caveat: dates, showtimes and prices are absent and must be retrieved via the returned webtic.it links. That prevents a very plausible misuse of the 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?

Three sentences: purpose and payload first, use cases second, scope limitation last. No filler and nothing buried.

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 covers return values and annotations cover safety, so the remaining burden on the description is scope and data limitations, both of which are stated. An agent has everything needed to call it correctly and to know what it will not get back.

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 and schema description coverage is 100%, with venueId already documented as 'id as returned by search_venues'. The description implies the parameter means a cinema or theatre but adds no syntax or format detail beyond the schema, 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 and resource ('returns everything currently on sale at a specific cinema or theatre') and enumerates the payload: events, their versions, per-item links, and the venue program link. An agent can distinguish this from search_events and get_event_details 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 concrete usage phrasings ('what's on at cinema X', 'what does theatre Y have') and draws a hard boundary around the data ('currently on sale, not when'). It does not explicitly name the sibling to use for showtimes/prices beyond pointing at webtic.it links, so the alternative routing is only partial.

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 readOnly/idempotent annotations, it discloses non-obvious behavior: the corpus is Italian-language, results reflect what is currently on sale only, and dates, showtimes and prices are deliberately absent (available on the webtic.it links). The Italian-keyword retry strategy is exactly the kind of operational context annotations cannot carry.

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 purpose and the sibling handoff, then the example queries, then the language/limitation caveats. The example-question list is slightly long, but every sentence still carries routing or behavioral information rather than filler.

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 doesn't. Combined with 100% schema coverage and full annotations, the only things an agent needs to call this well — language of the corpus, filter combinability, and the absence of date/price data — are all stated.

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; the description earns a bump by telling the agent to use short, distinctive Italian words for text and by implying the geographic filter is province-scoped rather than town. It doesn't restate the two-letter province code format, which the schema already handles.

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 (searches) and resource (films, theatre plays, concerts, musicals and other events currently on sale on Webtic), plus the platform and its market. It also distinguishes itself from siblings by naming get_event_details and get_event_venues as the consumers of the returned event id.

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 concrete when-to-use examples ('what's on in Milan', 'is Dune showing?') and states that all filters are optional and combinable. It also routes explicitly: the event id is what get_event_details and get_event_venues need, and if nothing is found, retry with fewer words.

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, idempotent, non-destructive and closed-world, so the safety profile is covered. The description adds that results include an event count and a program link, but that overlaps with the existing output schema, and it says nothing about behavior when both filters are omitted (return everything, or empty).

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-loaded with the core capability, followed by usage exemplars and the sibling link. Nothing is padded or redundant.

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 annotations, a full output schema and fully documented parameters, the remaining gap is narrow: a zero-required-parameter search does not say what it returns when no filters are supplied, which matters for anticipating broad result sets.

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. The description goes slightly beyond it by establishing that the two filters are optional and combinable ('by province and/or by name or town'), clarifying conjoint use of text and province.

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?

Names a specific verb and resource ('Searches the cinemas, theatres and other venues') and scopes it to the Webtic domain, with the two filter axes (province, name/town) stated up front. This is clearly distinguishable from sibling search_events and from the get_venue_* retrieval tools.

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 concrete natural-language use cases ('which cinemas are there in Bergamo') and explicitly states the downstream purpose: obtaining the venue id required by get_venue_program and get_event_venues. That is an explicit when-to-use plus a named alternative, which is exactly what routing guidance should look like.

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