TableJourney food travel

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

Annotations already declare readOnlyHint, idempotentHint, destructiveHint=false and a closed-world scope, so the safety profile is covered. The description goes beyond that by disclosing the result granularity (one entry per partner), what each entry contains (verified pickup facts plus a tracked booking link), and the empty-list outcome for uncovered cities. It doesn't mention pagination or partner-coverage caveats, but it adds real behavioral 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?

Two compact sentences, both front-loaded with the essential scope and the failure mode. The '(read-only)' tag is redundant with the annotations, which is a minor waste, but nothing else is padding.

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-value documentation is not required, yet the description still characterizes each entry usefully. Combined with the empty-result behavior and 100% schema coverage, an agent has enough to invoke it correctly; only explicit usage guidance 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%, including the slug/name examples and the did_you_mean behavior for unknown cities, so the schema already carries parameter semantics. The description adds no extra syntax or constraint detail about country vs city usage beyond restating 'cover a city'. 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 names the resource precisely ('car hire partners that verifiably cover a city') and the shape of the result (one entry per partner with pickup facts and a booking link). The verb is implied rather than stated, but an agent can tell instantly this is a car-hire lookup and not a stays or experiences lookup. No sibling overlaps, so explicit differentiation isn't needed.

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 agent infers this is the tool for finding car hire in a given city. There is no explicit when-to-use statement, no guidance on city vs country combinations, and no routing to any alternative (e.g., when a city has no car-hire coverage, what to do instead). The 'empty list' note is behavioral rather than a usage instruction.

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, closed-world and non-destructive behavior, so safety is fully covered by structured data. The description's '(read-only)' restates the annotation, and the enumeration of returned fields overlaps the output schema, so it adds limited behavioral information beyond what is already given.

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 sentences with no filler: capability and payload first, the call-first directive last. Every clause 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?

The tool is simple and read-only, an output schema exists so return values need no prose explanation, and the annotations cover the safety profile. Nothing needed 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?

There is only one optional parameter (country) and schema description coverage is 100%, with an example value supplied in the schema. The description mentions the country slug as part of the return payload but adds no filtering syntax or semantics 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?

States a specific verb and resource ('every city the site covers') plus the payload contents (country/city slugs and hub page URL). The phrase 'the slugs the other tools accept' positions it in the toolset rather than as a search tool, so an agent can separate it from search_places or place 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?

'Call first when unsure of coverage' gives an explicit trigger condition and ordering advice versus the rest of the toolset. It stops short of naming a specific alternative for when coverage is already known, so it is clear context without full 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, so the '(read-only)' tag in the description earns no credit. The genuinely additive context is behavioral shape: items are ranked by editorial score and venues are resolved to ids plus page URLs, which tells the agent what it is getting. It does not disclose the did_you_mean failure path or the keyed/unkeyed limit difference.

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 with the selection trigger and examples before the functional definition, and nothing is padding. The middle sentence 'Signature dishes of a city and where to eat them' largely restates the title, a minor redundancy.

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 enumerate return fields, and it still usefully notes ranking and venue-id resolution. Combined with full annotation coverage and fully documented parameters, an agent has everything needed to select and call this tool 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 city, limit, query and country are all documented in the schema with formats, defaults and the did_you_mean behavior. The description adds no parameter-level meaning beyond that, 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?

The description states a specific resource and scope: 'Signature dishes of a city and where to eat them,' which is far more precise than a generic search. It never names a sibling (e.g. search_places, things_to_do) to draw the boundary, so it is clear but not sibling-differentiated.

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 explicit trigger phrasing plus three concrete user-utterance examples ('what should I eat in Naples?', 'where to get pastel de nata in Lisbon', 'local dishes in Hanoi') that make the intended invocation context unambiguous. It offers no exclusions or named alternative tool for overlapping cases, so it stops short of a 5.

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 (readOnlyHint, idempotentHint, destructiveHint false), and 'Read-only' simply restates that. The one genuinely new behavioral fact is ranking: relevance-ranked when query is supplied, otherwise popularity-ordered; the enumerated result fields (price, rating, review count, duration, book link) duplicate the output schema and earn no credit.

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?

Usage is front-loaded and the description is short and scannable. However, the second sentence ('Bookable food tours, cooking classes, tastings and tickets for a city') largely re-lists the first sentence's categories, and 'Read-only' repeats an annotation, so a little space is wasted.

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 correctly does not need to explain return values, and annotations carry the safety profile; it still supplies domain scope, example queries, ranking behavior, and the affiliate/book affordance. What is missing is guidance on the city/country pairing and the role of food_only relative to sibling 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 description coverage is 100%, so the baseline is 3; the description adds meaning by showing that query accepts full descriptive phrases ('a street food tour in Bangkok') and by explaining query's role in ranking. It does not clarify city vs. country precedence, which is 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?

The description names a concrete domain (food tours, cooking classes, tastings, market tours) with sample queries, so an agent can tell this apart from generic sightseeing or event-ticket lookups. It never names a sibling tool explicitly (e.g. things_to_do, tickets), so the differentiation is by domain scope rather than direct 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?

It opens with an explicit 'Use for ...' clause plus three natural-language examples, giving clear positive usage context. There is no 'when not to use' guidance or pointer to alternatives (things_to_do, tickets, festivals), so the agent must infer boundaries 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, destructiveHint=false and openWorldHint=false, so the safety profile is covered. The description adds genuinely new context: dates are 'resolved' to the next edition and each item carries starts_on/ends_on, an organiser source URL and a citation page. It does not mention rate limits or the unauthenticated 20-result ceiling, which the schema covers instead.

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

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

Front-loaded with the usage trigger, then the resource, then the return shape — good ordering. The four quoted example queries take real space but each demonstrates a distinct filter combination, and the 'Filter by city, country, a date window and text' sentence is largely redundant with the schema.

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

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

An output schema exists, so return values need not be enumerated, and annotations carry the safety profile. Combined with 100% schema coverage, the description supplies everything an agent needs to select and invoke this tool correctly, plus the extra 'resolved next edition' framing.

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 all six parameters including the ISO date semantics and the API-key result cap. The description's 'filter by city, country, a date window and text' restates the schema without adding format, precedence or combination rules, 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 (food festivals / food events / Christmas markets) with a specific behavioural detail — the next resolved edition dates — plus filtering dimensions. The example utterances ('when is the Alba truffle fair') make it unmistakable that this is the festival-lookup tool and not the generic things_to_do or experiences siblings.

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?

Opens with an explicit trigger ('Use when the user asks what food festivals, food events or Christmas markets are on, or when one is') and follows with four concrete user phrasings that map directly onto the tool's filters (country+month, city+week, country, named event). No alternatives are named, but the trigger conditions are stated positively and unambiguously enough that an agent can route correctly.

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

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

Annotations already declare readOnlyHint, idempotentHint, non-destructive and closed-world, so the safety profile is covered. The description adds useful behavior beyond that: what each venue is resolved to (id, address, hours, page URL) and the empty-list case when no itinerary exists for a city.

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 usage trigger is front-loaded, then output shape and the empty-result edge case. No filler.

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

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

With an output schema present, return values need not be explained, and annotations carry the safety profile. The description covers purpose, triggers and the empty-result behavior; it could still say whether results are ranked/capped or how many days are supported, but nothing essential to correct invocation is missing.

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

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

Schema description coverage is 100% and both parameters are documented there (slug-or-name forms, did_you_mean behavior). The description adds only the implicit 'city' scoping, 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+resource ('Editorial day-by-day food itineraries for a city') and distinguishes itself from siblings like things_to_do, plan_day and dishes by naming the content type. The parenthetical example queries make the scope unambiguous.

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 explicit trigger phrasing ('a two-day food itinerary for <city>', 'how to spend 48 hours eating in <city>') so an agent can route on natural user intent. It does not name the closest alternative (e.g. plan_day) or state exclusions, so routing against siblings still requires 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, destructiveHint=false and openWorldHint=false, so the safety profile is covered. The description adds genuinely new behavior: the error contract ({error: ...} for malformed or unknown ids) and the breadth of returned fields including open_now_utc and three nearby venues.

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

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

Front-loaded with the core action and resource, then a compact inventory of return contents and the error case. Every clause carries information; only the long field list pushes against the density limit.

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 return-value burden and does so partially, naming the key fields, nearby venues, and the error shape. It is complete enough to call correctly, though pagination or response envelope details are absent.

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 itself documents the id format with a concrete example ('italy/rome/restaurants/roscioli'), so the baseline is 3. The description only adds the failure mode for an invalid id, not additional syntax or format meaning.

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 action and resource: 'One venue in full by id', which plainly separates it from the plural search_places sibling. It also enumerates what 'in full' means (provenance, hours, booking link, nearby venues), so an agent knows exactly what comes back.

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 rather than stated: the id is described as the one 'search_places returned', which signals this is the detail-lookup follow-up to a search, and the malformed/unknown-id error case is disclosed. However, it never explicitly says when to use this instead of search_places or any other sibling.

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 the description reinforces 'read-only' while adding substantial context the annotations cannot: every stop is checked open at its slot time on the given date, filtering is by neighbourhood/dietary/price tier, and the result includes a bookable experience plus itinerary titles.

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

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

Front-loaded with the activation condition and examples, then the output contract and the sibling handoff. Dense but every clause carries a distinct fact; there is no filler or repetition.

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

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

With no output schema, the description carries the return contract and does so fully: per-slot venues, date-validity checking, one bookable experience, and the list of editorial itinerary titles. Nothing an agent needs to call or interpret this tool 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 baseline is 3. The description restates the filter concepts (neighbourhood, dietary need, price tier) but adds no syntax, format, or defaulting detail beyond what the schema fields already document.

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 ('Compose a food day for one city') and spells out the output shape: one best-scored open venue per slot from morning to evening, plus one bookable experience. It also distinguishes itself from the sibling `itineraries`, which an agent can route to 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?

Opens with an explicit trigger ('Use when the user wants a day planned') followed by two concrete user utterances. It goes further and names the alternative: editorial itineraries are 'the better plan when one exists', with the exact sibling to fetch them (`itineraries`).

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 only cover the read-only/idempotent safety profile; the description adds real behavioral context beyond them: ranking order (relevance then editorial score), the provenance fields returned, that venues with unparseable hours are returned last and flagged, the limit cap without an API key, and the did_you_mean fallback instead of a list for unknown cities. These are exactly the edge behaviors an agent needs to plan around.

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

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

Front-loaded with the trigger condition and user-utterance examples, then filters, then result shape — a sensible order with no filler sentences. The middle is dense, and the results paragraph is long, but nearly every clause carries information an agent can act 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?

With an output schema present the description need not explain returns, yet it still characterizes ranking and provenance, and it covers the tricky no-match path. For a 12-parameter, zero-required search tool, nothing material for correct invocation is missing (only the all-empty-arguments case is 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 every parameter's meaning, defaults, ranges and examples are already documented in structured data; the prose largely restates them (kind groups, dietary values, price tier, near coordinate). No additional syntax or interaction semantics (e.g. how city+country+near combine) are added 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 + resource ('Search verified venues') and pins the scope to dining/drinking venues with filters, ranking and provenance. An agent can immediately distinguish it from detail-oriented siblings like `place` or content siblings like `dishes`/`experiences`.

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 opening 'Use when the user asks where to eat or drink in a city' with five concrete example utterances gives superb intent-matching guidance, including the 'is this restaurant open now' case that maps to open_at. It never names an alternative tool (e.g. `place` for a single venue's detail, or `things_to_do` for activities), so routing between siblings is still inferred.

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

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

Annotations already cover readOnly, idempotent and destructive flags, so the description only needs to add behavior beyond that — and it does, disclosing that prices are not returned and that the partner page carries them, plus that each listing has a tracked booking link. It says nothing about result caps or empty/did_you_mean handling beyond what the schema notes.

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 user-facing intent and then the payload contents. Every clause earns its place, with no repetition of the title or 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?

With no output schema and no annotations on return shape, the description correctly compensates by describing what comes back (hotel listings with tracked links, partner search links) and what does not (prices). Missing only minor details such as result-count behavior when limit truncates the 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 the parameters (city, country, limit with default 10 and range 1-50) are fully documented in the schema already. The description adds no format or syntax detail for those arguments 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?

The description names a specific resource (hotel listings plus partner search links for a city) and states what is returned, so the agent knows this is the lodging tool rather than things_to_do or experiences. It never names a sibling tool to contrast against, which keeps it short of the top band.

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 two explicit trigger phrasings, 'where to stay in <city>' and 'hotels in <city>', which is actionable routing context. It stops short of stating when NOT to use it or pointing at an alternative sibling when a query is only tangentially lodging-related.

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/idempotent/destructive=false, so the safety profile is covered. The description adds genuine operational context beyond that: a single call aggregates many categories, each result carries its own page and a tracked booking link, and the agent must pass affiliate links through unchanged — a non-obvious obligation worth disclosing.

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

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

Front-loads the trigger ('Use when the user is planning a trip...') before the payload description, which is the right order. It is somewhat dense in the middle enumeration and the parenthetical '(read-only)' duplicates the annotation, but every sentence carries routing or behavioral value.

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 usefully enumerates what comes back and in what shape (each item has a page plus booking link), and the schema covers all inputs. Mild gaps remain about result count, pagination or how festivals are date-filtered.

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%, with city/country slugs, did_you_mean behavior and ISO date fields all documented in the schema. The description adds no parameter-level 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 verb+resource (returns things to do in a city) and enumerates the concrete payload: food tours, classes, tastings, attraction tickets, festivals, places to eat, stays, car hire. The 'START HERE for "what can I do in <city>?"' framing distinguishes it from narrow siblings like experiences, festivals, tickets and stays.

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 explicit trigger conditions with two realistic user utterances and marks itself as the entry point for city-activity questions, which routes the agent correctly. It stops short of naming when NOT to use it or which sibling to fall back to (e.g., car_hire alone, plan_day, itineraries).

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 '(read-only)' tag is largely redundant. What the description does add is beyond the structured data: the deduplicated per-partner granularity with a tracked booking link, and the explicit empty-list outcome when no partner covers the city. Return-format detail is lighter than it could be, but an 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?

Two sentences, front-loaded with the resource and scope, with the sibling relationship and the empty-result behaviour packed in without filler. Every clause 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 rich annotations, full schema coverage and an output schema, the description needs only to establish scope and routing, which it does. It could have stated the explicit this-vs-experiences rule, but nothing an agent needs to invoke the tool 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% — the schema already documents both city and country with slug/name formats and the did_you_mean fallback. The description adds nothing about parameter syntax or the optionality of country, 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 (attraction tickets, city passes, tour partners) with a scope qualifier ('verifiably cover a city') and the return granularity ('one entry per partner with a tracked booking link'). It also names the sibling `experiences` as the adjacent tool, so an agent can distinguish them 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?

Saying it 'Complements `experiences`' implies the division of labour but never states when to pick this over that sibling, nor any exclusion. 'Empty list when none covers the city' describes an outcome, not a usage rule. Usage is inferable but not spelled out.

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