TourismMCP

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

Beyond annotations (readOnlyHint/openWorldHint/destructiveHint=false), it discloses non-obvious behavior: accommodations are excluded server-side even when filtered for, empty results must be reported as such rather than invented, per-POI optional fields are tag-backed or absent (never guessed), and an ODbL attribution object appears once per non-empty response. This is genuinely useful context an agent could not derive from the structured fields.

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 before the routing apparatus, and the bold section headers make the long text navigable. It is nevertheless verbose, with repetitive capitalized emphasis (WELCHE/WELCHER/WELCHER) and some restatement of the when/when-not split, which costs it the top score.

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, no-output-schema tool this covers everything an agent needs: required vs optional args with defaults and clamps, the exclusion rule, error/empty-state handling, result field shape, attribution obligation, and OSM coverage caveats. Nothing material is left dangling.

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 meaning: it notes the hotel-type example in the schema yields nothing here (backend accommodation exclusion), states the osm_id provenance (osmRel ID from search_place, osmNode fallback), and flags that indoor_only is only meaningful together with family_only. It stops short of extending meaning for every parameter, so not 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: expands a city/region OSM ID into the tourism POIs contained in it, naming the OSM Knowledge Graph as the source. It explicitly distinguishes itself from three siblings (nearby, search_place, resolve_location) with a labelled 'Tool-Semantik-Abgrenzung' section, so an agent can position it 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?

Provides dedicated 'When to use' and 'When NOT to use' blocks with concrete German and English trigger phrases ('was kann ich in <REGION> unternehmen'), plus routing rules to nearby for radius queries, get_poi_details for one POI, and search_tourism for hotels. The Typical chain (search_place → this tool → get_poi_details) and multi-call guidance remove all 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 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 cover the safety profile (readOnlyHint, destructiveHint=false, openWorldHint). The description adds genuine behavioral context beyond that: the anti-fabrication note that tide times come only from this call's output, the one-call-per-location/day-range rule, and the argument-mode requirement. It stops short of describing output format or latency, so not 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?

The core purpose is front-loaded in the first sentence, followed by clearly labeled sections. It is dense with many query examples, which is slightly verbose, but each block (routing, required args, chain, anti-fab) earns its place.

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

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

With no output schema, the description carries the return-value burden and partially addresses it via the anti-fabrication caveat that tide times appear only in the output. For a read-only tool with 100% schema coverage and thorough usage guidance, this is nearly complete, though an explicit return-shape hint would raise it further.

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

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

Schema coverage is 100%, so the schema already documents all six parameters including the lat/lon pairing and the lat+lon-only constraint on date_start/date_end/station_limit. The description reinforces the either/or argument logic and gives city examples, but adds little beyond the schema — baseline 3 is appropriate.

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

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

The description states a specific verb+resource (retrieving low/high tide times for a coastal location) and explicitly distinguishes itself from siblings like get_current_weather, resolve_location, and a routing server. An agent can immediately tell what this tool returns and what it does not.

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' triggers with concrete DE/EN example queries, a 'When NOT to use' section naming the correct alternative tool for each excluded case, plus a typical chain and multi-call guidance. This is a textbook routing-oriented usage block.

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

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

Annotations already cover safety (readOnlyHint=true, openWorldHint=true, destructiveHint=false), but the description adds substantial operational context beyond them: honest-empty behavior when sources:[], the no-object-by-id re-search quirk, the license/attribution obligation (license.holder must be named), and the anti-fabrication rule for name/price/hours. It does not, however, discuss rate limits or failure modes beyond the empty case.

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 and sectioned with bold labels, but heavily over-long (~700 words) for a two-parameter read tool. Much of the text is return-value documentation that repeats the same honesty rule several times ('nie erfunden', 'noch nie eine geratene Vorgabe-Lizenz'), diluting the selection-critical guidance.

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?

No output schema exists, so the description carries the full burden and does so exhaustively: it enumerates the return shape (sources[].subjects[].properties), the additive facts block, tour-only fields (path_on_map, trail_shape, entries), and hub_detail_url/license placement. An agent knows both what it gets back and how to present 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 baseline is 3; the description earns extra by explaining provenance of `id` (id or global_id from a search_tourism hit, e.g. 'e_101102405') and the real role of `query` (the source has no object-by-id endpoint, so the detail re-searches that scope and matches the id). That rationale is more than the schema field descriptions give.

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: 'Kuratiertes Detail zu EINEM Niedersachsen-Hub-Treffer per id', and immediately delimits against siblings: NOT get_poi_details (OSM bridge), NOT search_tourism (the curated search). An agent can distinguish the three tools 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?

Explicit 'When to use' (after search_tourism returned a hit with an id, with quoted DE/EN example utterances) and 'When NOT to use' (no prior hit / no id guessing → search_tourism; OSM detail → get_poi_details). It also documents the typical call chain and parallel multi-call pattern.

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 mark this as read-only and open-world, and the description adds important behavior beyond them: output is TOON text, not JSON; missing fields mean the source did not tag them; opening hours and prices are not present; unknown availability is not treated as free for `only_available`. This gives the agent a realistic model of what the tool can and cannot return.

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 text is long but well-structured: bold labels break it into purpose, required/optional parameters, format, further guidance, and anti-fabrication rules. The core purpose is front-loaded, and while some details are dense, each sentence carries practical information. It is comprehensive rather than wasteful.

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

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

With no output schema, the description compensates by naming the return format (`TOON`), the kinds of fields a hit carries (`category`, `modality`, `parking`, `contactInfo`), and the data limitations. It covers defaults, edge cases, exclusions, and how to get more detail. For a complex eight-parameter tool, 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?

Although the schema already documents every parameter, the description adds valuable semantics: `node_types` is one comma-separated string rather than an array, `'any'` does not cover park-and-ride kinds, `'poi'` alone activates a special filter, and shared-mobility offers split the limit. These operational details go well beyond the schema text and materially affect how the agent should construct calls.

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 and resource: finding stops, POIs, and addresses within a radius around a coordinate, with a clear geographic focus. It also distinguishes itself from name-based search by explicitly routing those cases to `search_place`, so an agent can tell it apart from siblings without opening the schema.

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

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

It clearly states when to use this tool (a coordinate is present) and that name-only queries should first go through `search_place`. It also points to `get_usage_guide` for finer details and flags the `'any'` exception for park-and-ride kinds. It does not explicitly mention other siblings like `reverse_geocode`, but the coordinate-vs-name distinction is sufficient 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 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 already mark it as read-only, open-world, and non-destructive. The description adds substantial behavior beyond that: it returns OSM IDs rather than stop IDs, mis-resolves station names to districts or cities, ignores the lang parameter, and warns against geographic hallucination. 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 long, but well structured with bold markers, concrete examples, and a clear lead sentence. It earns its length by resolving high-stakes sibling ambiguity, though a few examples could be trimmed without losing meaning.

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?

Even without an output schema, the description tells the agent what comes back (coordinates and OSM IDs), what failure modes look like, how to route non-matching cases, and where to find deeper guidance via get_usage_guide. Nothing needed to call it correctly is missing.

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

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

Schema coverage is 100%, so the baseline is 3. The description restates that name is required and that lang is optional and ignored, but the schema already documents these properties in similar detail. The format parameter is not mentioned in the description, but it is adequately covered by 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 states the exact operation in the first sentence: resolving a city, region, or district name into coordinates and OSM IDs, and frames it as the first step for locating an area. It then explicitly excludes stops, addresses, and POIs, so an agent can distinguish it from sibling geolocation tools without inspecting their 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 guidance with concrete query examples, and clearly says when not to use it: stop names containing Bahnhof/Hbf/Bf belong to the Ortsauflösung, and addresses/POIs/trip endpoints are also excluded. It names concrete alternatives: reverse_geocode for coordinate-to-name and nearby for listing surroundings.

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/destructiveHint/openWorldHint already covering the safety profile, the description still adds a great deal of behavioural context: de-duplication and source-precedence rules (NDS hub beats DZT; DZT excluded entirely for tours), OSM augmentation only in vicinity mode with explicit exclusions, the requirement that query/region be a candidate-pool hint in vicinity mode, the per-hit license naming obligation, hub_detail_url semantics, and an explicit anti-fabrication rule for names, dates and prices.

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 correctly, with purpose first and the when-to-use/when-not-to-use routing blocks early, and the bolded section markers aid scanning. However it is an extremely long block that re-states several schema facts and packs return-shape and license boilerplate into the same field as selection guidance, so not every sentence is earning its place in a description whose primary job is tool 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?

There is no output schema, and the description compensates by spelling out the full return shape (place, source, type, returned, mode, center, radius_m, pois[], events[]) and the meaning of empty results (returned: 0 means nothing was retrievable for that region). For an 11-parameter, multi-mode, multi-source search tool this is complete enough to call correctly without further context.

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

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

Schema coverage is 100%, so the baseline is 3, but the description adds genuine cross-parameter semantics the schema does not: tours are practically never returned without type=tour, accommodations are excluded from the activity scope even in region mode, activity selects an entire value family while unknown values silently mean "all", and id is the key for get_tourism_details. It does repeat some schema content (default 8, clamped 1..=20), which caps it below 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?

The opening line names a specific verb and resource ("Kuratierte Tourismus-Suche des Niedersachsen-Hubs") and immediately states the scope: editorially curated entries with events, prices, media, opening hours and tours. It differentiates itself from siblings by name (expand_kg_pois, nearby, search_place, get_tourism_details, MobilityMCP, get_current_weather/get_tide), 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?

There are explicit "When to use" and "When NOT to use" blocks with concrete user-utterance examples in German and English, each mapped to the correct sibling or server. It also supplies the canonical chain (search_tourism → get_tourism_details) and tells the agent it must pass the region hint, plus the multi-call-per-region rule.

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