Yenta Directory

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

Annotations already carry readOnly/idempotent/non-destructive/closed-world, so the bar is lower. The description adds real value beyond them: that a recurring event's dates represent the series span and the agent should read recurrence, plus what booking_url and canonical_url represent. This is useful behavioral context not in the annotations.

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, tightly written and front-loaded with the core purpose, with no wasted filler. The recurrence caveat and return-field notes are dense but earn their place; slightly compressed phrasing is the only knock.

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 rich annotations, a full output schema, and 100% parameter coverage, the description only needs to add the non-obvious semantics (recurrence span, return field meanings), which it does. The missing piece is explicit sibling routing, but that is a minor gap in an otherwise complete definition.

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 all eight parameters are fully documented in the schema, including the from_date/to_date defaults and cursor semantics. The description adds no parameter format or filtering 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 ('Find what is on in a named destination: events from today onwards') and implicitly contrasts with the venue-scoped sibling venue_events via the 'destination' framing. An agent can tell what it returns 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?

'Events from today onwards' implies the default temporal scope, and the note on reading recurrence gives usage context for recurring events. However, it never names the alternative (venue_events) or states when to prefer destination-level vs venue-level search, leaving selection to inference.

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 the safety profile is covered. The description adds only that results come from 'published FAQs'; it says nothing about pagination behavior, result limits, or what happens when a destination has no FAQ entry, which would be genuinely useful context.

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 tight sentence with the primary behavior first and the null-query special case second; no filler and nothing 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?

An output schema exists, so return values need not be explained, and the required destination parameter is described in-schema with a pointer to list_cities. The definition is nearly complete, missing only minor operational detail such as whether a query with no match returns an empty list.

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 limit/cursor/query/destination are all documented, and the schema already shows query defaults to null. The description's 'omit query' note restates the schema default rather than adding format or matching semantics, so 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?

States a specific verb and resource ('Answer a question about a named destination from its published FAQs') and explicitly covers the no-query case, which cleanly separates it from the sibling venue_faq and from destination_guide/overview.

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 'omit query to read them all' clause gives clear conditional usage for the query parameter. It stops short of naming the alternative sibling (venue_faq) or stating when a destination FAQ is preferable to destination_guide, so routing between siblings is left partly to inference.

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, openWorldHint=false, so the safety/idempotency profile is fully structured. The description adds useful interaction context (topic narrowing, cursor pagination), but does not disclose rate limits, auth requirements, or result-size behavior beyond what annotations and schema cover.

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 dense sentences, front-loaded with what the tool returns, then the optional topic filter and paging mechanics. No redundancy or filler; every clause 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?

The tool has an output schema, so return-value explanation is not required. The description covers purpose, the topic relationship to destination_overview, and pagination with cursor/next_cursor. Given five parameters and multiple sibling destination tools, it is nearly complete, though it could briefly note the default-limit behavior for an agent orchestrating pagination.

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 every parameter is already documented in the schema (topic enum, query, cursor, limit, destination). The description mentions topic and cursor usage but adds no format details beyond the schema; baseline 3 is appropriate when the schema carries the parameter semantics.

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 (Read) and resource (a named destination's travel guides), then enumerates the concrete content areas (weather, getting here, transport, entry requirements, safety). This distinguishes it from destination_overview, destination_events, destination_faq, and the other destination_* siblings by specifying it returns guide content, not events/FX/offers.

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 clear usage: pass topic (sourced from destination_overview guide_topics) to read one subject; page with cursor. It explains the relationship to destination_overview for topic discovery and how to paginate, but it does not state when NOT to use it or name a specific alternative for bulk guide listing.

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, so the safety profile is covered. The description adds genuinely non-obvious behavior: deduplication ('each business appears once (also_listed_as)'), what a result row contains (snippet, map_url), and that error responses enumerate valid filter values. It stops short of describing pagination or result-set size behavior.

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, no filler, and the core purpose plus match semantics are front-loaded before the follow-up-call and error notes. Every clause carries operational 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?

With an output schema present, the description needn't explain return values, yet it still sketches the row shape (snippet, map_url, also_listed_as). For an 11-parameter tool it covers search semantics, dedup, and error handling well; the remaining gap is sibling routing guidance, which matters given five overlapping search tools.

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 still adds real meaning the schema leaves ambiguous: 'Every query word matches, in any order' pins down AND semantics for the multi-word query, and the listing_id re-call path clarifies that this is a detail-retrieval mode rather than a filter combination.

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 with scope: 'Find places to stay, eat and visit in a named destination by text, category, area or tags.' An agent immediately knows this is a destination-scoped listing search. It does not, however, name or distinguish itself from plausible siblings like search_venues, search, or destination_overview, which an agent may hesitate between.

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 a clear follow-up path ('call it again with listing_id for the full text') and hints at error recovery ('an unknown filter value's reason lists the valid ones'). It does not say when this tool should be chosen over search_venues or destination_overview, nor what preconditions (e.g. needing a destination slug from list_cities) apply, so usage is only implied.

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 real behavioral detail beyond that: results are filtered to offers valid on valid_on (defaulting to today), and booking_url is only present for partners that have one, which warns the agent the field may be missing.

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 what is returned and immediately followed by the validity filter. The final sentence describing booking_url and canonical_url partially duplicates the output schema, keeping it just shy of a 5.

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 enumerate return values, and annotations plus full schema coverage handle safety and parameter detail. The remaining gap is routing guidance against the many destination_* siblings, which the description does not address.

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 all six parameters (including area/category slugs and cursor pagination) are already documented in the schema. The description restates the valid_on behavior but adds no syntax, format, or interaction detail beyond it, 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 ('Find a named destination's current deals and packages') plus the linkage to the partner booking link, which is enough to distinguish it from destination_events or destination_listings by resource type. It does not explicitly name a sibling or contrast scope, so it falls short of 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?

The description implies the use case (look up current deals for a destination) and notes the validity filter, but never says when to prefer this over destination_overview, destination_listings, or the venue_* siblings. No exclusions or prerequisites are given, so the agent must infer routing.

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/non-open-world, so safety is covered. The description adds genuinely new behavioral facts the annotations don't carry: results are a partial preview ('a few places'), and truncation is signalled through preview.complete being false when destination_listings/destination_events hold more. That truncation contract is the key thing an agent needs to know.

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 dense sentences with the capabilities front-loaded and zero boilerplate; the truncation caveat sits at the end where it belongs. The middle clause ('It counts offers, seasonality and FAQs too') is list-heavy and slightly redundant with the first sentence, which keeps it from a 5.

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, return values need no explanation, and annotations cover the safety profile. The description covers scope, contents, and the truncation signal — enough for an agent to call it correctly — with only the sibling-selection guidance left implicit.

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 schema coverage is 100%; the schema itself documents that it accepts a name or slug and points at list_cities for discovery. The description adds no syntax, format, or resolution-order detail beyond that, 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 says concretely what the call returns — counts, a few places, next events, guide topics, plus offer/seasonality/FAQ counts and the category/area facets listings, events and offers filter by. That content inventory implicitly distinguishes it from the single-facet siblings (destination_events, destination_offers, destination_seasonality). It never states the core verb+resource as plainly as the title does ('Overview of a destination'), so it lands just short of 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?

The line 'preview.complete is false when destination_listings / destination_events hold more' implies a routing rule: start here for a summary, go to those tools when the preview is truncated. But it's phrased as a return-value note rather than an explicit 'use this tool when…' instruction, and no sibling is named as an alternative for the common 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?

Annotations already declare readOnlyHint=true, idempotentHint=true, non-destructive and non-open-world, so the safety profile is covered. The description adds that results are month-by-month and cover weather and wildlife seasons, which is useful domain context. It doesn't disclose pagination, response completeness, or error behavior, but with an output schema present that burden is reduced.

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 with no waste. The key resource and scope (best time, weather, wildlife, month by month) are immediately clear.

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 lookup with an output schema and 100% param coverage, the description is largely sufficient. It could add explicit routing to sibling tools or note how interest interacts with month, but nothing critical is missing 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 description coverage is 100%, so the schema already documents destination, month, and interest with examples and semantics. The description adds little param-level detail beyond restating month-by-month behavior. Baseline 3 is appropriate when the schema does the heavy lifting.

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 (get) and resource (named destination's best time to visit, weather and wildlife seasons), and scopes it month by month. Among siblings like destination_events, destination_faq, destination_guide, it clearly carves out the seasonality/timing niche.

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?

Implies use when you want seasonal timing for a named destination, but gives no explicit when-to-use or when-not-to-use guidance, and doesn't route to alternatives like destination_overview or destination_guide. Usage is inferable but not 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 read-only, idempotent, non-destructive, closed-world behavior, so the description only needs to add context. It does so by disclosing the return medium (Markdown text) and that the page carries a citable URL, though it says nothing about error behavior for stale or malformed ids.

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 action and payload, followed by id formats. No filler or restatement of the tool name.

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 with 100% schema coverage, an output schema, and full safety annotations, the description supplies what is missing: what content the page contains and what id forms are valid. Only minor gaps remain (behavior on invalid/expired ids, content completeness).

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 says the id must match what search returned. The description still earns credit by showing the concrete id shapes ("venue:acme-bistro", "destination:los-cabos", "listing:los-cabos:1234"), which is genuinely useful formatting detail 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?

States a specific verb and resource ("Read a search result's full page") and enumerates the content types it yields (menu, dietary options, hours/events, destination page). It does not explicitly contrast itself with siblings like venue_menu or destination_overview, so the boundary is implied 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?

"A search result's full page" implies this is the follow-up step after search, but there is no explicit when-to-use/when-not guidance and no named alternative for structured sub-resources (e.g., venue_menu) that a caller might prefer.

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 establish readOnlyHint=true, idempotentHint=true, destructiveHint=false, and openWorldHint=false, so the safety profile is covered. The description adds meaningful behavioral context about data scope, namely that only cities with published restaurants and bars are included and travel destinations are excluded. It does not add pagination or auth details, but those are less critical given the annotations and output 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?

Two sentences, front-loaded with the core purpose and followed by the key exclusion rule. Every sentence earns its place with 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?

The tool is simple, the output schema exists, and the annotations cover safety and idempotency. The description supplies the scope and sibling-routing information an agent needs to call it correctly, so it is complete for this context.

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 limit and cursor are clearly documented in the input schema. The description adds no parameter-specific syntax or constraints beyond what the schema already provides. Baseline 3 is appropriate when the schema carries parameter semantics fully.

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: 'List the cities that have published restaurants and bars.' It also distinguishes this tool from destination-oriented siblings by explicitly excluding travel destinations and naming destination_overview as the alternative. An agent can tell what this tool returns 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?

It gives an explicit inclusion rule ('cities that have published restaurants and bars'), a clear exclusion ('Travel destinations such as Los Cabos are not cities here'), and a named alternative ('read one with destination_overview'). This is exactly the routing guidance needed to choose between list_cities and destination_overview.

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 safety (readOnly, idempotent, non-destructive) and closed-world semantics, so the description only needs to add operational context. It does add the return shape (id, title, url) and the next-step action (pass an id to fetch for the full page), which is genuinely useful beyond annotations. It does not mention result limits or ranking, a minor 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 tight sentences: scope, return/next-step, then alternative tools. Front-loaded with what it searches and zero filler; each sentence 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?

For a one-parameter search tool with an output schema (which handles return details), the description supplies scope, return summary, follow-up (fetch), and sibling routing. Nothing an agent needs to invoke it correctly 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 description coverage is 100%, so the single query parameter is already fully documented with examples. The description restates the name/keyword intent but adds no syntax, matching behavior, or formatting guidance beyond the schema. Baseline 3 applies when the schema carries the parameter burden.

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 (search) and resource scope (venues, travel destinations, places inside destinations), and explicitly distinguishes itself from the filtered siblings search_venues, search_menus, and destination_listings. An agent can select it without opening any other 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?

Clearly implies when to use by contrast: 'For filters use search_venues...', which routes filtering needs elsewhere. It does not explicitly state when-not or prerequisites, but the alternative routing is concrete enough to guide selection.

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 safety is covered. The description adds genuinely useful behavior beyond that: every returned item is tagged with its venue, which is what makes single-call cross-venue comparison valid. It stops short of describing ordering or pagination mechanics, which the schema partly covers via cursor/next_cursor.

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: the first states scope, the second states the comparison benefit and the alternative tool. No filler, and the differentiator 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?

With an output schema present, return values need not be explained, and all seven parameters are optional and fully documented in the schema. The description covers purpose and the sibling alternative adequately; the only mild gap is that it does not state what an unfiltered call returns.

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 baseline is 3. The description restates the main filter axes (text, city, dietary tags, allergens) but adds no syntax, matching semantics, or defaults beyond what the schema already documents (match-all-words, synonym handling, currency, max item counts).

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 (find) and resource (dishes across all venues) and enumerates the discovery axes (text, city, dietary tags, allergens). It also names the sibling it is not (venue_menu) and explains the cross-venue comparison intent, so an agent can distinguish it from venue_menu and search_venues 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?

It gives an explicit routing rule: multi-venue comparison here, "for one named venue use venue_menu." The city parameter description further points to list_cities for valid values, giving the agent a concrete dependency to resolve before calling.

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 safe read-only, idempotent behavior, so the bar is lower. The description adds useful behavioral context: HARD filters exclude, prefer_* and avoid only rank, query matches one keyword, and results include slug, capabilities, open_now, and distance_km.

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, front-loaded with the core purpose, then filter semantics, then result/scope context. Every sentence carries useful information without repetition or 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?

For an 18-parameter tool with full schema descriptions, rich annotations, and an output schema, the description is complete enough. It covers purpose, hard/soft filter semantics, query behavior, result fields, and the key routing exclusion to destination_listings.

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 schema already documents all 18 parameters. The description still adds a useful cross-parameter distinction by grouping filters as HARD versus prefer_*/avoid as SOFT and clarifying that query is a single keyword.

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: 'Find restaurants and bars' with city, cuisine, opening time, or features. It also explicitly distinguishes the tool from destination_listings for places inside a destination, so an agent can identify its scope 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?

It gives an explicit when-not-to-use case: places inside a destination belong to destination_listings. It also clarifies hard versus soft filter behavior and that query is one keyword, but it does not explicitly cover other sibling alternatives such as search_menus or search.

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 annotations (which only signal a non-destructive, non-idempotent write), it discloses the key traits an agent can't infer: the report is stored for Yenta's team, never shown publicly, and returns a reference. The "leave out personal details" instruction is genuine behavioral guidance. It does not say whether repeat submissions create duplicate reports or whether the report is ever answered conversationally.

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 compact sentences, front-loaded with what to report, then the privacy/visibility constraints. No filler, and the most decision-relevant content (what counts as a report) comes first.

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?

The output schema covers the reference returned, and the description still flags it; annotations cover the safety profile; the privacy note covers the main misuse risk for an 8-parameter write tool. Remaining gap is small: nothing about duplicate submissions or any rate/abuse limit on a non-idempotent mutation.

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 parameters are already fully documented, and the description's category list largely restates the `kind` enum. The one addition is the privacy constraint ("leave out personal details"), which shapes what goes into `message` beyond the schema's length limit – real but marginal added meaning, so 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?

The sentence pairs a specific verb ("Send ... a report") with the target (Yenta) and enumerates the exact report categories, which map cleanly onto the `kind` enum. The write nature makes it unmistakable against the read-only destination_*/venue_*/search_* siblings, 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?

"data that is missing or looks wrong, a tool that was hard to use, or anything else" gives concrete triggering conditions that align with the enum values. There are no exclusions, however – it never says what should NOT be reported here (e.g. ordinary search questions) or what the alternative channel is.

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 destructiveHint=false, so the safety profile is covered. The description adds genuinely useful behavior beyond that: results are bounded to the venue's local today onward, and event-type data may not exist for a given venue (partial-availability caveat).

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 purpose and scope, followed by the filter hint and the capability caveat. No padding 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?

An output schema exists, so return values need no explanation, and the description covers temporal scope, the event_type caveat, and the fallback to venue_profile. The only gap is that cross-tool routing (venue vs destination events) is left unaddressed.

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 all seven parameters are already documented, including the local-today default and cursor semantics. The description restates the event_type exactness and the temporal floor but adds no syntax or format detail 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 ("Find what is on at a named venue: dated events") plus a scope ("from its local today onwards"), so the agent knows exactly what is returned. It distinguishes itself from destination-level siblings implicitly via "a named venue" but never names destination_events as the contrasting alternative.

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 conditional guidance for the event_type filter and routes the agent to venue_profile to check whether the venue publishes event types. It does not, however, state when to prefer this tool over destination_events or other discovery tools like search_venues, leaving the primary selection question to inference.

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, so the safety profile is covered. The description adds meaningful context beyond that: omitting query changes behavior to a full read, and the venue may simply not publish this content, which sets expectations for empty 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 compact clauses, front-loaded with the primary action and then the fallback. No filler; every phrase carries 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?

With an output schema present, return values needn't be described, and the description covers the query-optional behavior and the unavailability fallback. It stops short of tying into the city/list_cities disambiguation flow that the schema mentions, but is otherwise sufficient 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 100%, so the baseline is 3, but the description adds semantics the schema alone doesn't convey: the absence of query is a deliberate read-all mode, and there is an explicit fallback path when the data isn't published.

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+resource: answering a question about a named venue from its published FAQs. The 'venue' scope distinguishes it from the similarly-shaped destination_faq, though the differentiation is implied by naming rather than stated outright.

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 clear conditional guidance: omit query to read all FAQs, and fall back to the venue_profile capabilities list if the FAQ isn't available. No explicit when-not or direct sibling comparison, but the operating 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 read-only, idempotent, non-destructive and closed-world, so safety is covered. The description adds real behavioral context beyond that: the default (unfiltered) response shape lists dietary tags, example dishes and allergen counts, and it discloses that a venue may simply not publish a menu. It stops short of describing pagination behavior, which the cursor param implies.

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, front-loaded with the core action and example, with no filler. The middle clause ('unfiltered, item lists its dietary tags, example dishes and allergen counts') is compressed to the point of being slightly telegraphic, costing a point.

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 need no explanation, and the description covers filters, the unfiltered default, and the unavailable-data case. The main residual gap is that it never distinguishes this from search_menus, leaving the agent to infer which lookup surface to choose.

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 baseline is 3 and the schema carries the parameter burden. The description restates the filter set and shows example values for venue/dietary_tags/allergens, which is mildly reinforcing but adds no syntax or semantics beyond what the schema already documents.

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 ('Find dishes at a named venue') and immediately grounds it with a concrete example call, which separates it from the cross-venue search_menus sibling. An agent can tell what this returns 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 a worked usage example and enumerates the filter axes (text, tags, allergens, max_price), plus a fallback path when data is unavailable ('check the capabilities venue_profile lists'). It does not explicitly contrast with search_menus or say when a broader search is preferable, so it falls short of a full when/when-not statement.

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 safety is covered. The description adds that hours_summary is 'ready to quote' and that capabilities point at sibling tools, which is useful, but it does not disclose lookup failure behavior (e.g. ambiguous name handling) beyond the schema's city note.

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 leads with the verb and resource before the field list. Dense but essentially waste-free, with only the tangled parenthetical slightly harming readability.

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 need not explain return values, and it still previews the payload and flags hours_summary as quotable. Combined with full annotation and parameter coverage, an agent has enough to invoke 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%, so both venue and city are already documented in the schema, including the city disambiguation and slug behavior. The description only echoes the name/slug input with an example, adding no semantics the schema lacks; 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?

Specific verb (Get) plus resource (venue profile) with an enumerated payload: hours, address, map, phone, booking, links. It partially differentiates from siblings by noting the venue_* tools 'that answer for it', though the relationship is stated cryptically rather than contrasted.

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 implies context (retrieve a known venue by name or slug) and parenthetically signals that other venue_* tools resolve against this entity, but it never states when to choose it over search_venues or the other venue_* siblings. The 'call search_venues to discover one' guidance lives in the schema, not the description.

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