Cork & Curve wine travel

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

Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the safety profile is covered. The description adds meaningful behavioral context: one entry per partner, pickup facts we checked, tracked booking link, and empty list when no partner covers the city. This goes beyond the annotations without contradicting them.

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 a single, dense sentence that front-loads the core purpose and then adds the key behavioral details. Every clause earns its place, and the empty-list note is a valuable edge-case disclosure.

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 list tool with an output schema and full schema coverage, the description is nearly complete. It explains the result shape (one entry per partner, empty list) and the verification aspect. It does not detail pagination or sorting, but those are minor given the output schema and annotations.

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 both parameters. The description adds the notion of 'city coverage' but does not add new parameter-level meaning 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 states a specific verb ('cover'), a resource ('car hire partners'), and a clear scope ('per city'), and it distinguishes itself from siblings by emphasizing verified coverage and tracked booking links. It also clarifies the empty-list behavior, which is a useful semantic detail.

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 when to use it: when you need car hire partners that verifiably cover a city, and it notes the read-only nature. It does not explicitly name alternatives or exclusions, but the sibling list and the 'read-only' qualifier give enough context for an agent to select it appropriately.

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, and non-destructive behavior. The description adds value beyond those annotations by clarifying that the returned slugs are the ones other tools accept, which is important integration context not present 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 short, purposeful sentences with no filler. The tool's purpose, return contents, and usage hint are all front-loaded and immediately actionable.

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 low-complexity tool with one optional parameter, rich annotations, and an output schema, the description covers the essential operational guidance: what it returns and when to call it. Nothing critical 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%, and the schema already explains the optional country filter with an example. The description adds minor context by mentioning country and city slugs, but the schema carries the parameter-documentation 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?

The description clearly identifies this as the list of every city the site covers, and specifies that it returns the country slug, city slug, and hub page URL used by other tools. It is not a tautology and is clearly distinct from the sibling tools, which operate on specific content types rather than city coverage.

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 explicit directive 'Call first when unsure of coverage' tells the agent exactly when to use this tool, positioning it as the discovery/reference step before using other tools. This is strong usage guidance for a simple list tool.

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 description's '(read-only)' adds nothing. The remaining content ('each item has a description... ranked by editorial score') describes return structure, which the existing output schema already covers. No behavioral trait beyond the annotations is disclosed.

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 leads with the core scope and follows with the item structure. It is efficient, though the packed delivery and the name/description mismatch slightly reduce clarity.

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 parameters are fully documented in the schema. However, it omits any guidance on combining query/city/country, and the mismatch between the name 'dishes' and the wine-focused description leaves the tool's actual domain uncertain.

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 city, query, country, and limit are all self-documented (including the did_you_mean behavior and city/country relationship). The description adds no parameter meaning beyond the schema, so the baseline of 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 identifies a specific resource — 'signature wines of a region and the producer to visit' — which tells the agent what content to expect, but it does so with a noun phrase rather than a clear verb. It also clashes with the tool name 'dishes', which implies food rather than wine, creating real ambiguity about what the tool actually returns. No sibling differentiation is offered.

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?

There is no indication of when to use this tool versus siblings like place, experiences, or cities, nor any exclusions or prerequisites. The only hint of usage context is the parenthetical '(read-only)'. The agent is left to infer the scenario from the resource description 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?

Annotations already declare readOnlyHint=true and destructiveHint=false, so the safety profile is covered. The description adds real value beyond them: the sort order (relevance to query, else popularity) and the fields each item carries including a tracked book link, which is non-obvious 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, front-loaded with what the tool returns and followed by the safety and ranking notes. No filler and every sentence carries information an agent needs.

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 detail return values, yet it summarizes them anyway alongside ranking behavior. Missing only pagination/limit behavior detail for a 5-param, list-returning tool.

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

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

Schema description coverage is 100%, so city, limit, query, country and food_only are already documented in the schema. The description only reinforces query-based ranking and adds no syntax or default nuance 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-resource pair with concrete scope: bookable wine tours, tastings, cellar visits and tickets for a region. It is clearly distinguishable from stays, car_hire and place, though it never names a sibling or an explicit boundary against generic search_places.

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 'region/city' framing implies when this tool fits, and the ranking note gives some invocation context, but there is no explicit when-to-use versus alternatives and no stated exclusions. It also never says to reach for search_places for non-bookable results.

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, destructiveHint=false, idempotentHint=true and openWorldHint=false, so the safety profile is fully covered and the description's 'read-only' merely restates it. It does add some useful behavioral context about the data shape ('next resolved dates', item carries starts_on/ends_on, organiser source URL, citable page), but the presence of an output schema lowers the bar for return-value disclosure.

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

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

Two tight sentences, front-loaded with the resource and scope, followed by the filtering and item-shape details. There is no filler, hedging, 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?

For a read-only, six-parameter search tool with a full output schema and complete annotations, the description covers purpose, filters and what each item contains without needing to explain return formatting. The only shortfall is the absence of explicit routing guidance against similarly search-oriented siblings.

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%: the six parameters already document slugs, ISO date semantics, the date_from default of today, and the did_you_mean behavior for unknown cities. The description merely lists the filter categories, adding no syntax, format, or interaction detail beyond the schema, 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 resource (wine festivals) with a scoping qualifier ('next resolved dates') and explicitly flags the operation as read-only. It is clearly distinct from siblings like cities, dishes, stays and experiences, though it does not name a sibling or contrast itself with one.

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 names the available filter dimensions (city, country, date window, text), which implies how the tool is meant to be used. However it gives no explicit when-to-use guidance, no prerequisite conditions, and no routing advice relative to sibling tools such as place or search_places.

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 and idempotentHint, so the description's 'read-only' is consistent; it adds useful behavior beyond annotations: itineraries are editorial, day-by-day, each venue is resolved to structured fields, and an empty list is returned when a city has none. No contradiction.

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 front-loads the core purpose and then packs in the resolved venue fields and empty-list behavior. 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?

With an output schema present, the description does not need to explain return values; it covers the city-scoped behavior, what a venue entry contains, and the empty-case semantics. No essential behavior 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 both city and country are already documented; the description adds no parameter-level detail beyond saying the tool is city-scoped. Baseline 3 applies because the schema handles the parameter documentation 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?

The description identifies a specific resource – editorial day-by-day wine itineraries for a city – and specifies that venues are resolved to id, address, hours and page URL. It is distinguishable from siblings like plan_day or search_places, though it lacks an explicit verb like 'returns'.

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 tool is used when a user wants curated wine itineraries for a city, and notes when the list is empty. It does not explicitly name alternatives or state when not to use this tool, leaving route selection 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 read-only, idempotent, non-destructive. The description adds error behavior (returns {error: ...} for malformed/unknown id) and enumerates return content, which is useful beyond annotations. No contradiction; adds context on failure modes.

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 purpose and enumerates key return fields and error case. Zero fluff; 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?

With no output schema, the description compensates by listing the expected return fields and the error format. For a simple id-based lookup, it covers all needed operational details. Sibling tools are distinct and the description fully equips an agent to 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%, so the description need not explain the id parameter further. The description mentions 'by id' but adds no semantic detail beyond the schema's example. Baseline 3 is appropriate since the schema fully documents the parameter.

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 clearly states the tool's function: retrieving one venue in full by id, read-only. It enumerates the specific content (fields, provenance, hours, open_now_utc, booking link, nearby venues) which distinguishes it from sibling tools like search_places (list) or cities/dishes (other resources).

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 usage when you have an id and need full venue details, and the schema explicitly ties id to 'search_places returned'. However, it does not explicitly state alternatives or conditions when not to use this tool, though the sibling list and schema hint at the lookup workflow. Lacks explicit when-not guidance.

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, and destructiveHint=false Brief: description adds valuable behavioral context: stops are checked open on the given date, only best-scored venues are selected, and editorial itinerary titles are included. It does not contradict the annotations, and while it doesn't discuss rate limits or error behavior, the safety profile is well covered by 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 dense sentences carry all relevant information without filler. The first sentence front-loads the core operation and read-only nature, then lists filters and output. The second sentence adds an actionable alternative. 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?

Given there is no output schema, the description adequately conveys the shape of returned data (venues per slot, bookable experience, editorial itinerary titles) and the key validation rule (venues open on the date). Minor gaps like explicit slot definitions or exact return structure prevent a 5, but the tool is callable from this description alone.

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 are already documented. The description adds marginal value by naming which parameters act as filters ('neighbourhood, dietary need and price tier') and by tying `date` to the open-check behavior, but it does not introduce new semantic details 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?

The description identifies a specific verb and resource: 'Compose a wine day for one city', and details the output: one best-scored open venue per slot, filtered by neighbourhood, dietary need and price tier, plus a bookable experience. It also clearly separates itself from the sibling `itineraries` by saying editorial itineraries are 'the better plan' when one exists.

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 explicitly tells the agent when to prefer an alternative: 'which are the better plan when one exists (fetch them with `itineraries`)'. It also states the tool is read-only alerts to side-effect-free use operationally. This gives concrete routing guidance beyond a generic 'use this to plan'.

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 the description goes well beyond them: it discloses the ranking order (relevance then editorial score), the provenance payload (source URL, checked_on, open_status), hours, a citable page URL and tracked booking link, the `limit` cap, and the degraded `{did_you_mean: [...]}` response for unknown cities. That is unusually rich behavior for a search 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, front-loaded with the core verb and the read-only caveat before the filter enumeration. The long filter list is dense but purposeful; the only mild redundancy is restating filterable fields that the schema already names.

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 12-parameter, zero-required search tool with an output schema, the description covers everything an agent needs: scope, filter vocabulary, ranking, pagination cap, and the error-shape fallback. The output schema handles return structure, so nothing material 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 the schema carries the parameter definitions and a baseline of 3 applies. The description adds genuine semantic value on top: it clarifies that `kind` accepts either topic slugs or the groups visit/drink/buy/do, and that `near` implies distance sorting, both of which go beyond the raw field descriptions.

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

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

States a specific verb+resource ('Search verified venues') and immediately scopes it as read-only, then enumerates the filterable dimensions (text, city, kind, cuisine, dietary, price tier, opening time, coordinates). This distinguishes it from detail-oriented siblings like `place` and the narrower `cities`/`dishes` tools without needing to open 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?

The filter list makes the intended use case (faceted venue discovery) clear, and the did_you_mean fallback tells the agent how to react to a bad city input. However, no sibling is named as an alternative for single-venue lookups (e.g. `place`), so the routing guidance is implicit rather than explicit.

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 the safety profile (readOnly, idempotent, non-destructive, closed-world), so the bar is lower. The description still adds real value beyond them: it discloses that each listing carries a tracked booking link and that prices are deliberately omitted and live on the partner page.

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 the tool returns, then a clipped note on what it does not return. The parenthetical marker is redundant with annotations but costs almost nothing.

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 carries the burden of describing returns, and it does so well (listings, tracked booking links, partner search links, no prices). It stops short of mentioning the did_you_mean fallback behavior for unknown cities, though the schema covers that.

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 documents city slugs, the limit range (1-50), and country optionality. The description adds no additional parameter semantics, so the baseline of 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+resource combination: returns hotel listings/partner links for a city, explicitly read-only. The scope ('hotels and stay partners for a city') clearly separates it from siblings like car_hire, experiences, and festivals.

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 implied by the content description (an agent knows to call it when it needs lodging for a city), but there is no explicit when-to-use/when-not guidance and no sibling alternatives named to route between, e.g., experiences vs. stays.

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