udansa

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

Annotations already cover read-only, idempotent, and non-open-world, so the bar is lower; the description still adds real behavioral context the annotations don't carry, notably that booking gaps are explained via booking.reason with booking.book_at as the redirect and that udansa provides no external booking links. It does not say what happens with an unknown id, but the added semantics are substantive.

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 that front-loads the core purpose and then packs the field list. Every clause earns its place as a payload inventory, though the parenthetical caveats make it slightly run-on.

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?

There is no output schema, so the description carries the return-shape burden and does so thoroughly: description, styles, level, provider, instructor, venue address, schedule details, pricing, free places, age limits, waitlist, trial lesson, and booking status. Only error/not-found behavior and pagination are unaddressed, which is minor for a single-record lookup.

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 100% schema description coverage the baseline is 3; both parameters are already documented in the schema. The description names 'Link: url' and 'styles'/'style names', which loosely connects to the language parameter's effect, but it never explains the language parameter's impact on the link and style rendering itself.

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 ('Full public details of one dance course on udansa') and immediately enumerates the returned payload, making it unmistakably distinct from the sibling search tools that return course ids. An agent can tell this is the detail-expansion counterpart to search_dance_courses.

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: 'one dance course' plus the schema note that the id comes from search_dance_courses tells the agent the search-then-details flow, but the description never states when to use this versus get_event_details or read_page_text, nor any exclusions.

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 cover the read-only and idempotent profile, but the description adds genuinely non-obvious behavior: organizer is null for udansa-curated events, booking.reason explains why purchase is unavailable, and udansa supplies no external ticket links. Those are exactly the runtime surprises an agent would otherwise misread.

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?

It is front-loaded correctly, but everything after the colon is one unbroken run-on enumeration of return fields with no grouping. Since there is no output schema the enumeration carries real information, yet the wall-of-text form makes it hard to scan.

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 must disclose what comes back, and it does so comprehensively: venue, organizer, artists, programme, ticket categories with price and remaining count, add-ons, series, waitlist, and booking. What is missing is only shape-level detail, which the flat sentence cannot convey anyway.

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 both parameters are already documented, including the default 'de' language and the id source. The description only echoes the language behavior ('title and description in the requested language') and adds nothing about format, fallback, or invalid ids, 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?

Opens with a specific verb-plus-resource: 'Full public details of one dance event on udansa'. The word 'one' implicitly separates it from the sibling search_dance_events, but the description never names that sibling, so an agent must rely on the schema note to see the routing.

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 reader infers this is the detail follow-up to a search result because the schema says the id comes from search_dance_events. There is no explicit 'use this after searching' or 'do not use to list/browse events' statement in the description itself.

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 openWorldHint=false, so safety is covered. The description adds meaningful behavioral context beyond that: the results are constrained to values that 'currently have' courses or events, i.e. the list is dynamic and availability-driven, and style names are localized to the requested language.

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 what is returned and followed by how to use it. No filler or repetition of structured fields.

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 does state what comes back (cities and styles). It leaves slight ambiguity about the return shape (two separate lists vs. a combined structure) and about localization falling back when a language is unsupported, but for a two-parameter read-only lookup this is nearly complete.

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?

At 50% schema coverage the description compensates: it names the two kind values ('courses', 'events') and explains that language controls the language of style names, matching the schema's own note. Both parameters are meaningful without inspecting the schema, though the default behaviors (kind='courses', language='de') are left to the schema.

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 (list) and resources (cities and dance styles) plus the scope qualifier 'currently has courses or events'. Combined with the closing sentence steering to search_dance_courses/search_dance_events, an agent can distinguish this filter-options tool from the search siblings 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?

Explicitly says to use the returned values as city/style filters in search_dance_courses and search_dance_events, which gives clear usage context and names the alternatives. It stops short of a direct 'call this before searching to discover valid filter values' instruction or any when-not-to-use note.

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, and closed-world, so the safety profile is covered. The description adds one genuinely useful behavioral fact — the response is "plain sections plus its FAQ" — but says nothing about failure modes for malformed/off-domain URLs, truncation of long pages, or locale fallback when a path language is unavailable.

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, each doing distinct work: what is read, where the URL comes from with an example, and which sibling to use instead. Nothing is repeated and the scope statement 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 single-parameter read tool with annotations covering safety and no output schema, the description supplies purpose, valid input provenance, return shape, and sibling routing. An agent has everything needed to select and 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 coverage is 100% and the schema already supplies the path example, so the schema carries the parameter burden. The description usefully ties valid values to search_guide_articles output, but adds no format or language-path rules beyond what the schema shows; baseline 3 fits.

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?

Specific verb+resource ("read the text of a udansa content page") with an explicit enumeration of what counts as a content page (guide article, city/style page, terms, privacy, cancellation, about us). It also names the sibling tools for the cases it does not cover, so an agent can distinguish it from get_course_details/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?

States where valid input comes from ("a URL or path from search_guide_articles") and explicitly routes non-content pages elsewhere: "For courses and events use get_course_details / get_event_details." Both the use case and the exclusion with named alternatives are present.

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 openWorldHint=false, so safety is covered. The description adds genuinely new behavior: the exact result field set (id, title, style, level, city, venue, weekday, start/end, ongoing, price, free places, URL), the extra filter_options facet payload with counts, and a deep link to the same search. Pagination limits and total-count behavior are left to 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 filter list and the sibling pointer are front-loaded, and the closing sentence on get_course_details and booking is well placed. The middle sentence runs long by packing thirteen return fields into one clause, but each element is load-bearing given there is no output 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?

With 12 parameters and no output schema, the description carries the return-shape burden well by enumerating result fields and the filter_options facet with counts. What is missing is pagination context (page/limit interaction, ordering default) and the course-vs-events distinction, both of which matter for correct invocation.

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 75%, so most parameters are already self-documenting; the description's list of filter dimensions largely restates them. Its real additions are that style accepts any language (also in the schema) and that price is a filterable dimension, which partially compensates for the undocumented price_min/price_max. Sort, page and limit get no help beyond the schema.

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?

Specific verb + resource ("search public dance courses on udansa") with the scope pinned to "the same results as the course search page" and an explicit enumeration of filter dimensions. An agent can distinguish it from search_dance_events and get_course_details 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?

Explicitly routes single-course lookups to get_course_details and tells the agent that booking happens on the course page (i.e., this tool is discovery-only). It gives clear usage context but never addresses search_dance_events, the closest sibling, so the agent must infer courses vs events from the name alone.

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 read-only/idempotent annotations, the description discloses important behavior: recurring events are deduplicated and shown once with their next date, and price_from has nuanced null vs 'free' semantics. It also describes ticket-sale modes and the result fields, which is valuable because no output schema exists.

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 front-loaded with the core purpose, then adds filtering, recurring-event behavior, result shape, and sibling routing. Although it is fairly long, every part carries useful information for a 13-parameter search tool with no output 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?

Given the absence of an output schema and the presence of 13 optional filters, the description is complete enough to call the tool correctly. It covers the main filter concepts, result fields, recurrence behavior, and the alternative for ticket/programme details, while schema-level pagination and sorting details are handled by the input 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?

Schema description coverage is 77%, and the schema already documents most filter parameters. The description groups the filter dimensions and notes organizer and price filtering, but adds little syntax or constraint detail beyond the schema, and price_min/price_max still lack richer semantics in both places.

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: search upcoming dance events on udansa, with concrete event types. It also distinguishes this from get_event_details by routing detail requests to that sibling, so an agent can tell what this tool is for and what it is not.

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 filtering dimensions and explicitly points to get_event_details for tickets and programme. It does not explicitly route users to get_search_filter_options or say when not to use this tool, but the main alternative is named and the usage context is clear.

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 openWorldHint=false, so safety is covered. The description adds real context beyond that: corpus size (~1,400 articles), topic coverage, language breadth, and the exact return shape (titles, short summaries, page URLs).

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 tight sentences, no filler. The corpus scope is front-loaded and the follow-up hint lands at the end where the agent needs it.

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 read-only search with no output schema, the description covers corpus, return format and next step, which is nearly everything an agent needs. Minor gap: no mention of pagination or how limit behaves when results are broader than expected.

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 75%, so the baseline is near 3, but the description adds meaning: the '40 languages' claim gives context for the language param and the enumerated content types map onto the section enum, helping the agent pick a value. It still doesn't explain limit (default 10, max 25).

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?

Specific verb (Search) plus a precisely scoped resource (udansa editorial content: ~1,400 guide articles, city guides, dance style pages, 40 languages). The scope cleanly separates it from siblings like search_dance_courses, search_dance_events and read_page_text.

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 states the follow-up path explicitly ('read one with read_page_text'), which is genuine routing guidance, and the content scope implies when this tool applies versus the course/event search siblings. However, it never states an explicit when-not or a direct comparison to the other search tools.

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