TourismMCP

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

Annotations already cover safety (readOnly, non-destructive, openWorld), and the description still adds substantive behavior: accommodations are excluded backend-side, the tool fan-outs internally over containedInPlace entities, OSM-KG coverage is Germany-wide with variable tag density, and empty results must be reported as 'nothing retrievable' rather than fabricated. The attribution/ODbL obligation is also 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?

Front-loaded with purpose and differentiation, but the block is long, heavy on bold pseudo-headers and mixed German/English, and repeats points already in the schema (limit clamping, address default, types semantics). Several sentences could be trimmed without losing 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?

There is no output schema, yet the description discloses the full return shape (`place_osm_id`, `total_contained`, `tourism_candidates`, `returned`, `pois[]` fields, `attribution`), the anti-fabrication rule, and the empty-result behavior. That is complete for this complexity, though the return-shape prose is dense rather than structured.

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 baseline is 3; the description adds meaning beyond the schema by explaining where the `osm_id` comes from (`search_place`/`places` osmRel, node fallback) and clarifying that `indoor_only` is meaningful only with `family_only`, plus the practical consequence that a hotel `types` filter yields nothing.

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: expanding a city/region OSM ID into its tourism/attraction POIs from the OSM knowledge graph. It explicitly distinguishes itself from three siblings (`nearby` = vicinity, `search_place` = place disambiguation, `resolve_location` = transit stops), so an agent can pick it without opening other schemas.

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?

Provides explicit 'When to use' triggers in DE and EN with example phrasings, an explicit 'When NOT to use' section routing to `nearby`, `get_poi_details`, `search_place`, and weather/tide tools, plus a typical call chain (`search_place` → this tool → `get_poi_details`).

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 establish read-only, open-world, non-destructive behavior, but the description adds substantial context beyond them: an anti-fabrication rule (values only from tool output), the GeoNutzV attribution obligation that travels with the output, and one-call-per-location semantics. This is exactly the kind of disclosure structured fields cannot carry.

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?

Dense and long, but front-loaded and organized into bolded sections (When to use / When NOT / Required args / Typical chain / Anti-fab). A little redundancy between the required-args recap and the schema, but nearly every sentence carries routing or safety 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 still tells the agent what the return carries (the additive attribution object) and how to cite it, plus the chaining path through search_place. Complete for a read-only, coordinate-driven lookup.

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

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

Schema coverage is 100%, so lat/lon/units/lang are already documented, but the description adds a real constraint absent from the schema: coordinates must originate from search_place and never from estimation. That elevates it above the baseline 3, though it largely restates the unit/language defaults.

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 ('Aktuelles Wetter zu Koordinaten') and explicitly contrasts itself with get_weather_forecast and get_tide. An agent can distinguish it from all siblings 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?

Provides explicit 'When to use' and 'When NOT to use' sections with named alternative tools for each exclusion (forecast >1h, tides), plus multi-call and multi-day routing guidance. Nothing is left 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?

With readOnlyHint/openWorldHint already declared, the description still adds substantial behavior: multi-call bursts of 3-5 parallel calls, `sources: []` meaning 'nothing retrievable', absence of `facts` as an honest signal, ODbL attribution rules, and per-field provenance. It also flags OSM's variable tag coverage.

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?

Bold section headers and front-loaded purpose make a long description navigable, and each block (chains, shape, attribution) carries distinct information. It is verbose and repeats the no-prefix rule, but the density is justified by the tool's many edges.

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 fully specifies the response shape (`sources`/`subjects`/`properties`/`coord`, additive `facts`), the attribution envelope, and the anti-fabrication policy. An agent has everything needed to call and interpret it.

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 format is already documented, but the description adds the provenance of `osm_id` (comes from `nearby`/`resolve_location`/`search_place` output, prefix already stripped) which the schema only partially implies. That is genuine value beyond the schema, though the format itself is redundant.

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 opening states a specific verb+resource ('POI-Detail-Lookup per OSM-ID') and immediately scopes it to OpenStreetMap data. It explicitly distinguishes itself from siblings, e.g. 'für Stadt-/Region-IDs (nutze search_place)' and the curated 'get_tourism_details' source.

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 are explicit **When to use** and **When NOT to use** sections with concrete DE/EN trigger phrases, plus named alternatives for the excluded cases (search_place for region IDs, MobilityMCP for routing, get_tourism_details as curated priority).

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, openWorldHint=true and destructiveHint=false, so safety is covered externally. The description adds genuinely useful behavior beyond that: gauge-matching logic with matched_by/query_location/distance_km, a 30 km coastal cutoff, a ~6-day forecast horizon with prediction_note, local-time interpretation, wind-surge fields, and attribution. However it never describes the actual response structure or empty/no-gauge outcomes, so it sits at a solid but not exemplary level for a tool with annotations covering safety.

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 purpose and routing, then structured into labeled sections (When to use / NOT / Required args / chain / anti-fab). It is long, but nearly every sentence carries actionable information; a few clauses (e.g., the anti-fab note and chain restatement) slightly overlap with earlier content.

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 6-param open-world read with no output schema, the description covers invocation, location resolution, date defaults and horizon, and names key response fields (forecast_cm, forecast_deviation, attribution), which is nearly complete. The main remaining gap is that the returned structure (per-station grouping, tide event list) is only sketched, not described.

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 real semantics: city first matches a gauge name, otherwise the place is geocoded and the nearest gauge by distance and district is chosen; station_limit default 3 (1–10); date defaults to today and the next two days; either city OR lat+lon is required. That is meaningful glue beyond the schema text.

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 first sentence names a specific resource (high/low tide for a coastal location, official BSH data with wind-surge forecast), which is precise and distinct from weather or routing siblings. It also frames it as the answer to 'when is low tide in X', making the resource unmistakable.

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?

Explicit 'When to use' with concrete example questions and 'When NOT to use' with named alternatives (get_current_weather, MobilityMCP, resolve_location) plus inland-location exclusions. It also documents the typical chain (search_place → this tool) and that one call covers one location/date-range.

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 establish read-only, open-world, non-destructive behavior, and the description adds substantial context beyond that: source provenance, anti-fabrication rules, `sources: []` handling, optional `date` effects on `shade`, and the fact that `query` does not alter the answer. No annotation contradiction is present.

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 purpose and routing guidance are front-loaded, and much of the return documentation is necessary because there is no output schema. However, the description is extremely long, dense, and mixes usage, return fields, edge cases, and anti-fabrication warnings in a way that is harder to scan than it needs to be.

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 a complex response shape, the description comprehensively explains returned fields, tour-specific fields, `shade`, `facts`, `hub_detail_url`, and license handling. It also covers missing-data behavior and the required chaining from `search_tourism`, leaving little an agent needs 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%, so the baseline is 3, but the description adds meaningful semantics: `id` must come from a prior `search_tourism` hit and must not be guessed, `query` is accepted but inert, and `date` controls the tour `shade` calculation. This goes beyond the schema text enough to merit a 4.

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: fetch curated detail for ONE Niedersachsen hub hit by `id`, including description, opening hours, real price, address, and media. It explicitly distinguishes itself from `get_poi_details` and `search_tourism`, so an agent can route correctly without opening sibling schemas.

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 when-to-use conditions after `search_tourism` returns an `id`, and explicit when-not-to-use cases: no prior `id`, OSM POI detail via `get_poi_details`, or region search via `search_tourism`. The typical chain and multi-call guidance remove most ambiguity.

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 indicate read-only and non-destructive behavior. The description adds valuable context: omitting `tool` returns all tool sections at once, supplying `tool` returns one section, and the full retrieval is costly. No contradiction with annotations exists.

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

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

The description is dense and front-loaded with purpose, then explains parameter behavior and cost. Every sentence carries useful information, though it is slightly longer than strictly necessary.

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 guide tool with one optional parameter and no output schema, this description is complete: it explains purpose, when to use it, how the parameter behaves, what is returned, and cost implications. Nothing essential 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% and the parameter is already documented. The description adds decision guidance around when to supply `tool` versus omit it, including the cost trade-off, which goes beyond the schema. It does not enumerate valid tool names, but catalog context provides that.

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 the tool is the detailed guide to all catalog tools, covering purpose, delimitation, arguments, return values, and quotation rules. It clearly positions itself as a meta-tool distinct from the domain-data sibling tools.

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 explicitly says when to read a section (before setting filters or passing an empty result), when to omit the `tool` parameter, and when to set it. It also warns that calling without `tool` is expensive and should only be used for a full-catalog 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 declare readOnly/openWorld/non-destructive, and the description goes well beyond them: it mandates that `lat`/`lon` come from `search_place` rather than estimation, states one call per location, explains how multi-day queries map onto `limit`, and adds an anti-fabrication rule plus a legal attribution requirement (GeoNutzV/DWD).

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 one-line purpose before the bolded routing blocks, and every section earns its place. It is dense and mixes German and English, so it is longer than strictly necessary, but nothing is 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 no output schema and five parameters, the description still covers what matters: the top-level `attribution` object's shape, the source of forecast values, and the constraint that unlisted days have no value. An agent has everything needed to call and interpret the result.

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 defaults are already documented; the description still adds value by specifying the provenance of `lat`/`lon` and by characterizing `limit` semantically as forecast slots rather than just 'maximum entries'. It adds meaning, though it does not extend the schema substantially.

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 (weather forecast for coordinates) and explicitly differentiates from siblings: current conditions go to `get_current_weather`, tides to `get_tide`. An agent can route correctly without opening any schema.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

Contains explicit **When to use** and **When NOT to use** sections with concrete example queries in two languages, plus a typical call chain (`search_place` → this tool → optional POI tools). Alternatives are named by tool name, not 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?

Beyond the annotations, the description discloses that start and end are the same instant, that unresolvable phrases return an empty candidates array, that timezone handling is DST-aware with a Europe/Berlin default, and that fabricating dates/time is forbidden. These behaviors materially shape agent reasoning and are consistent with readOnlyHint, openWorldHint, and destructiveHint.

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 well-structured and front-loaded with the purpose and no-call condition, and it uses clear sections for parameters, return behavior, and anti-fabrication rules. It is somewhat long and repeats the return shape a few times, so it is not maximally concise, but each block earns its place for a tool this complex.

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 still explains the exact return shape (candidates[].datetime_range.{start,end}), clarifies the no-window behavior, specifies the empty-candidates failure mode, and delegates edge-case hour mapping to get_usage_guide. Nothing needed to invoke the tool or interpret its result 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?

The schema already provides rich, 100%-coverage parameter descriptions covering text, lang defaults, tz IANA/DST semantics, and the format serialization. The description mostly restates these—text as written by the user, optional lang, optional tz—adding only marginal emphasis on using the raw user wording. Therefore it stays at the high-coverage baseline of 3.

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 opens with a specific operation and resource: resolving a time mention into an absolute ISO-8601 timestamp, with concrete examples and a clear no-call condition for full ISO-8601 inputs with offset. However, it does not explicitly contrast itself with sibling tools such as link_dynamic, so sibling differentiation is implicit rather than explicit.

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 explicit when-to-use guidance (natural-language time mentions, 'jetzt'/'now' as canonical current time), when-not-to-use guidance (complete ISO-8601 with offset), and what to do on failure (ask the user rather than computing). It also directs the agent to get_usage_guide for nuanced cases like hour mapping for vague dayparts.

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, openWorldHint=true, and destructiveHint=false. The description adds meaningful behavioral detail: the anti-fab note that only candidates from the arg are matched (no implicit vocabulary expansion) and the explicit return format (candidates[].candidate, score, span). It also mentions the empty-candidate rejection, complementing the schema. No contradiction with 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?

The description is dense but well-organized with bold labels (When to use, When NOT to use, Required args, Typical chain, Multi-call, Anti-Fab note). Every sentence carries essential information; there is no filler. The core purpose is front-loaded, and the structure makes scanning easy for an agent.

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?

Despite having no output schema, the description supplies the return format. It covers prerequisites (candidates non-empty), the anti-fab constraint, multi-call behavior, and the intended chain. For a tool with two required parameters and a nuanced matching rule, this is a complete operational guide.

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% (both text and candidates have descriptions). The description adds semantic clarity: it explains that the candidate list IS the vocabulary and must be non-empty, and it outlines the candidate structure ({name, synonyms?, coord?}). This goes beyond the schema's basic property descriptions, justifying a score above the baseline 3.

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 opens with a precise verb+resource statement: 'Match-Mention gegen Caller-supplied Kandidaten-Vokabular' (match mention against caller-supplied candidate vocabulary). It explicitly contrasts with specialized link_* tools by naming the alternative family, making the tool's unique role unmistakable.

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 when-to-use (caller has custom vocabulary) and when-not-to-use (standard place/stop/time etc. go to specialized link_* tools). It also adds a typical chain, multi-call guidance, and a critical constraint (candidates must be non-empty), leaving no ambiguity about invocation context.

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/openWorld/destructive=false), but the description goes well beyond: it discloses the TOON text output format, the fact that opening hours and prices are absent, the fields a hit carries, and the special availability semantics (unknown availability is not treated as available). This is rich behavioral context an agent cannot get from the annotations alone.

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 purpose, then required/optional, then format, guide pointer and anti-fabrication rules, so the structure is easy to scan. It is long and partly duplicates the schema's own node_types enumeration, but nearly every sentence carries operational 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 and 8 parameters, the description covers what an agent needs: output format, what a result carries, availability caveats, and anti-fabrication rules, while delegating exhaustive detail to `get_usage_guide`. Nothing essential for a correct call 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 baseline is 3; the description nonetheless adds real meaning — required vs optional split, the comma-string form of `node_types`, the fact that `'any'` does NOT cover park_and_ride/charging_station/taxi, and the distinction between unknown and unavailable for `only_available`. It slightly repeats schema text, which keeps it from a 5.

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: finds stops, POIs and addresses within a radius of a coordinate, with two concrete example queries. It also distinguishes itself from siblings by routing name-only inputs to `search_place` (city/region) or the place resolution, so an agent can tell it apart without opening another 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?

Explicit when-to-use phrasing ("was ist in der Nähe von <lat,lon>") plus explicit alternatives (`search_place` for a city/region, otherwise the place resolution). It also directs the agent to `get_usage_guide` for the finer points and names the default serialisation, leaving little 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 only cover the safety profile (readOnly/openWorld/non-destructive). The description adds real behavioral context well beyond them: A→B needs two calls, every hit carries `type` and `location`, only a `stop` has a rideable DH-ID that must never be invented, `modes` reveals what stops there, and `name`/`localName` disambiguate language. It also states that an invalid kind is an argument error rather than a dropped filter.

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?

Purpose is front-loaded and the rest is chunked under bold labels (Pflicht, Optional, Art-Wort, A→B, Anleitung, Anti-Fab), which makes it scannable. It is nevertheless long and partly duplicates the schema's parameter prose, so it is efficient but not maximally tight.

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 (type, location, modes, localName vs name) plus an anti-fabrication rule. The remaining gap is what to do when nothing resolves — the no-match / empty-result behavior is not stated.

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 mandatory `query` hygiene rules and the `node_types`/`city_station` semantics, but these are already documented verbatim in the schema, so it adds little beyond the structured fields apart from emphasis.

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 opening sentence gives a precise verb+resource: it resolves free text into the ID that travel uses, and immediately names the situations (routing, departure board, POI profile). It explicitly differentiates from the sibling `search_place`, which handles an AREA (city/region) rather than a point. An agent can route between the two 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?

States when it is needed ('where routing, departures board or POI profile requires an ID'), names the alternative for areas (`search_place`), and routes shared-mobility kinds (rental station, taxi rank) to `nearby`. It also prescribes the calling pattern for A→B ('call twice') and points to `get_usage_guide` for further distinctions.

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 mark readOnlyHint=true and openWorldHint=true, so the description does not need to repeat basic safety. It adds genuinely non-obvious behavior: fallback to a coarser level when the requested level is missing and the result is recognizable via place_type, distance-0 inclusion in any radius, limit clamping, and the anti-hallucination instruction to use only returned names. Nothing in the description contradicts 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?

The description is dense but highly structured: purpose, boundary, required args, optional args, fallback behavior, instruction source, and anti-hallucination rule each get a clearly labeled section. Although it is longer than many descriptions, every sentence carries operational value; there is no filler or tautology.

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 6-parameter tool with no output schema, the description covers all parameters, defaults, edge cases, sibling-tool routing, and output interpretation (place_type fallback indicator). It also gives an anti-fabrication rule for returned names, which is critical practical guidance. The reference to get_usage_guide fills any remaining serialization detail without bloating the main description.

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, and the description goes beyond it by adding the one-spelling-per-call rule, explaining the nearest-hit behavior when radius_m is omitted, and clarifying that unknown level values behave like 'place'. It largely restates schema semantics for radius_m and limit, but it provides extra operational context that helps an agent invoke the tool correctly.

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: names what lies at a coordinate, optionally at a chosen level, including street-level reverse geocoding. The first sentence alone tells an agent not just what the tool returns but that it is the lookup for a GPS start position. It also distinguishes itself from nearby and search_place, making sibling confusion unlikely.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

Explicitly gives when-to-use guidance: reverse geocoding a coordinate, street labeling for GPS positions, and the distinction from search_place (name → coordinate), nearby (what lies around), and another resolution tool. It also states required parameters, the mandatory spelling consistency rule, and points to get_usage_guide for further detail.

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 cover the safety profile (readOnly, openWorld, non-destructive), and the description goes well beyond them: it discloses that a station name yields a same-named district (one in Potsdam) and that the returned id is an OSM id, not a drivable stop id. It also explains the score matching semantics (1 = exact, >=0.5 whole word) and adds an anti-fabrication instruction about only using returned names and 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?

Front-loaded with the core purpose, then the critical exclusion, then parameters, then the usage guide and anti-fabrication note, with bold markers making sections scannable. It is dense rather than padded, but the single block is long and some parenthetical examples could be trimmed 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?

For a read-only lookup with no output schema, it covers purpose, alternatives, required/optional params, matching behavior and what the returned id actually is. It stops short of describing the full response shape (e.g. whether coordinates and ids come as a list of candidates), so an agent still infers some of the return structure.

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 a 3 is the baseline. The description adds real signal on top: it restates name as mandatory and clarifies that lang has no current effect (the schema only says "advisory"), which is a genuine refinement. The format parameter is left to the schema and the reference to a `score` field is a bit ambiguous, keeping it from a full 5.

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 precise verb and resource: it resolves the NAME of a city, region or district into coordinates and OSM-Ids, and frames this as the first step for locating an area. It actively distinguishes itself from siblings by naming reverse_geocode and nearby for their respective jobs, so an agent can route without opening any schema.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

Gives explicit when-to-use (locating a region/city for questions like weather or activities) and explicit when-NOT-to-use (any request containing Bahnhof/Hbf/Bf or any stop/address/POI that could be a journey endpoint, which belongs to resolve_location). Concrete examples ("Köln Hauptbahnhof", "Hannover Bahnhof") show what goes wrong otherwise, and it points to get_usage_guide for deeper chaining.

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 say readOnly/openWorld/non-destructive, yet the description discloses the multi-source model (Niedersachsen hub vs. DZT vs. OSM), the de-duplication rule where the hub wins inside Niedersachsen, the fact that DZT carries no tours, and that OSM data is merged only in coord-vicinity mode with explicit exclusions. It further adds provenance semantics (`source`, `license` with mandatory attribution, `hub_detail_url`), an anti-fabrication contract for names/dates/prices, and the `note` / `returned: 0` honesty behavior — none of which the annotations carry.

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?

Bold section markers (Tool-Semantik-Abgrenzung, When NOT to use, Required args, Anti-Fab note, DZT-Bündelung) give it a usable skeleton and the scoping constraints are front-loaded. But it is a very long wall of text that restates much of the 100%-covered schema (type, timeframe, activity, shade, limit) and spends large stretches on per-field return-value documentation, so many sentences do not add new decision value for selection.

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 13 parameters, the description carries the full load and does: it documents the return envelope (`place`, `source`, `returned`, `mode`, `center`, `pois[]`, `events[]`), per-hit fields including `license`, `hub_detail_url` and `suitability`, and the `id`-to-`get_tourism_details` key. Mode branching (region search vs. coord-vicinity) and the availability/failure semantics are all covered, so nothing an agent needs to call or interpret the result 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 baseline is 3; the description nonetheless adds operational meaning the schema does not spell out as clearly — that `type=tour` is effectively required to ever see tours, that `activity` matches whole value families (8% of walked records lack a "Wandern" value), that `shade_tree_share` is not shade-per-hour and must not be embellished, and that `region`/`query` stop being required once `lat`+`lon` are set. Some parameter text is repeated near-verbatim from the schema, which limits it to a 4.

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 opening sentence names a specific verb and resource ("Kuratierte Tourismus-Suche des Niedersachsen-Hubs") and immediately enumerates the curated content it covers (events with dates, prices, media, opening hours, tours). A dedicated "Tool-Semantik-Abgrenzung" paragraph explicitly names siblings `expand_kg_pois`, `nearby`, `search_place`, `get_tourism_details` and states what each is for instead. An agent can distinguish this tool from every other one in the sibling list 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?

There are explicit, bilingual "When to use" examples ("was ist diese Woche in <Region> los", "hotels/restaurants in <Ort>"), an explicit "When NOT to use" block routing OSM sights, single-hit details, routing and weather/tide to named alternatives, plus a stated typical chain (`search_tourism` → `get_tourism_details`). Rules like "one call per region/type" and "for hotels explicitly type=accommodation" go beyond what any schema conveys.

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