London Tourist Map

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

Annotations already declare readOnlyHint, idempotentHint, non-destructive and closed-world, so safety is covered. The description adds genuinely useful behavior beyond that: the corpus size (463 places), that hours are checked against official websites, that prices are current, and that results are capped ('up to 15 places, each with a link to it on the map'). It does not spell out ranking or relevance ordering, which would have earned a 5.

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

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

Front-loaded with the capability and scope, then a compact clause of usage examples, then the return-shape sentence. Every sentence carries information, though the example clause is long enough to be slightly dense; a small trim would improve it.

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

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

With no output schema, the description correctly compensates by stating the result cardinality and that each place carries a map link and enrichment (hours, prices, Tube). Coverage of the 8 parameters is delegated to the schema, which is complete. Only the ordering of results remains unexplained.

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 includes the enum definitions and default for limit, so the schema does the heavy lifting. The description only loosely reinforces parameters through natural-language examples ('free things to do', 'step-free museums', 'what's open on Sunday') without adding syntax or semantics like date format or how 'near' resolves. 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 verb and resource ('Search 463 London sights, museums, parks, markets, hidden gems and day trips') plus the data source (London Tourist Map) and what makes the results distinctive (opening hours, ticket prices, nearest Tube with step-free access). It is easy to distinguish from siblings like london_place_info (detail lookup) and plan_london_trip (itinerary planning).

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 provides explicit triggering examples ('free things to do in London', 'rainy day ideas', 'hidden gems near Covent Garden', 'step-free museums', 'what's open on Sunday') that map cleanly onto parameters. It does not explicitly say when to prefer a sibling tool (e.g. london_place_info for a single place's details), so it stops short of full alternative 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 readOnlyHint, idempotentHint and openWorldHint=false, so the safety profile is covered. The description adds meaningful context beyond that: facts are 'checked' and hours carry the date they were checked, which tells the agent how much to trust freshness. It doesn't say what happens when a place is unknown or hours are unavailable, keeping it below 5.

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

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

Front-loaded with the payload inventory, then a single usage sentence with examples; no filler. The field list is dense but each item is a distinct returned fact, so it earns its space.

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 the returned fields, and with annotations covering safety the remaining need is freshness, which is addressed. Minor gap: no mention of behavior for unknown/nonexistent places, which an agent would want before calling.

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 both 'name' (nicknames like V&A) and 'date' (YYYY-MM-DD) already documented, so the baseline is 3. The description's examples reinforce that 'name' accepts casual forms and that 'date' answers open/closed questions, but add no format or error-handling 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?

The description enumerates exactly what is returned (hours per day, last entry, seasonal closures, ticket price, visit duration, nearest station and step-free access, accessibility, address) and scopes it to a single London sight. It implicitly separates itself from find_london_places ('one sight' vs discovery) but never names the siblings, so it stops 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?

Three concrete example questions ('is the Tower of London open on Monday?', 'how much is St Paul's?', 'nearest Tube to the Shard') map directly onto legitimate use cases and show the date parameter in action. There is no explicit when-not guidance or named alternative for place discovery, which would be needed for 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 (readOnly, idempotent, non-destructive, closed-world), and the description adds real value beyond them by describing the return payload: the day groupings plus a map link, opening hours for the trip dates, lunch stops, a booking checklist and a PDF. It also implies closed-day avoidance, which explains why start_date matters. It stops short of stating pagination/size limits or what happens when requested places don't fit the itinerary.

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 before the input instruction and the return description. The parenthetical feature list is dense but each item is informative; it could be trimmed slightly without loss.

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?

Sibling tool: with no output schema, the description carries the burden of explaining what comes back, and it does — itinerary days plus accompanying plan artifacts. Combined with the read-only annotations and full schema coverage, an agent has everything needed 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?

With 100% schema description coverage the schema already documents every parameter, including the day range, the pace enum and the interest vocabulary, so the baseline of 3 applies. The description reinforces the days range and the places-or-interests choice but adds no constraint, format or default information that isn't already in 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?

Names a specific verb (plan), a specific resource (a 1-7 day London sightseeing itinerary) and the exact output shape: places grouped into days by area, in walking order, with visit durations and transit legs. That input contract (accepts place names or interest themes) already separates it from the two siblings, which are lookup-style tools, without needing to name them.

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 context is stated clearly: planning a multi-day trip, with the agent explicitly told to supply either the places the person wants or interests from which to pick. No exclusions or prerequisites are given, though — nothing tells the agent what to do when place names are unknown (i.e., call find_london_places first) or when a single place's details are needed (london_place_info).

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