TourismMCP

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

Annotations already declare readOnlyHint=true and destructiveHint=false, but the description adds substantial behavioral context: accommodations are backend-excluded, fields are tag-derived and never guessed, attribution must be shown once, and there is an explicit anti-fabrication rule (never supplement POIs from training knowledge). 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 very long, but it is well-structured with headers, bold labels, and bullet-like sections that front-load the purpose and differentiate siblings. Every sentence adds value, though it could be trimmed slightly without losing critical information. It is more thorough than concise, hence a 4.

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?

Complete for a complex tool: covers typical chain (search_place → this tool → optional get_poi_details), multi-call guidance, anti-fabrication, OSM coverage, and return structure (pois fields, attribution, honesty fallback). An agent has everything needed to invoke it correctly, even without an output schema.

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%, but the description adds meaning beyond schema: osm_id is sourced from search_place with an example (1187768), limit defaults and clamping are clarified, types are substring and case-insensitive, include_address default, and the family_only/indoor_only coupling is explained. It also warns that a hotel types filter returns nothing because accommodations are excluded.

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 place OSM ID to the tourism POIs inside it. The first sentence clearly defines the operation and scope, and it explicitly differentiates from nearby, search_place, and stops, so an agent can distinguish it from siblings without inspecting 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' and 'When NOT to use' sections with concrete query examples in both German and English, and names alternative tools (nearby, get_poi_details, search_place, get_current_weather/get_tide) for each exclusion case. Also gives a typical chaining sequence and a multi-call note.

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 readOnlyHint and openWorldHint, so the bar is lower; the description adds substantial operational constraints: lat/lon must come from search_place and never be guessed, weather values must only come from this tool's output (anti-fabrication), and legal attribution to Deutscher Wetterdienst/GeoNutzV is required. This goes well beyond the structured 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 well-structured with bold labels and front-loaded purpose. It is longer than average, and the opening overlaps somewhat with the 'When to use' section, but nearly every sentence earns its place with operational or routing 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?

For a tool without an output schema, it covers what data will be returned (temperature, conditions, wind, humidity), the attribution object, and the one-call-per-place behavior. An agent has enough context to invoke the tool correctly and interpret its results, though exact response field names are not specified.

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 the crucial rule that lat/lon must originate from search_place rather than estimation, and clarifies unit options with temperature symbols. It mostly restates schema defaults for lang and units, but the sourcing constraint is meaningful extra semantics.

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 states the tool returns current weather for coordinates and explicitly positions it as the answer source for 'wie ist das Wetter in X', distinguishing it from general knowledge. It also contrasts itself with get_weather_forecast and get_tide, so the agent can clearly differentiate it among siblings.

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

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

The description has explicit 'When to use' and 'When NOT to use' sections naming alternatives: get_weather_forecast for forecasts beyond one hour and get_tide for tides. It also provides a typical chain (search_place → this tool) and multi-call guidance, leaving no ambiguity about when to select it.

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 (readOnlyHint=true, destructiveHint=false), and the description adds substantial behavioral context: data is from OpenStreetMap, raw tags versus normalized facts, honest fallback when sources is empty, anti-fabrication instructions, attribution/licensing requirements, and coverage caveats. No contradiction exists between description and 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 long but exceptionally well structured with bolded section headers, examples, and a clear front-loaded purpose statement. Some content, such as repeated examples and detailed attribution text, could be trimmed, but it remains focused and each section supports correct tool usage.

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 documents the response shape, including sources, subjects, properties, coord, facts, price, and attribution, plus fallback behavior when sources is empty. It also covers the multi-call pattern, typical chains, and regional coverage, leaving no critical gap for an agent to call the tool correctly.

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

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

Schema coverage is 100% and already explains that osm_id is a bare numeric string matching ^\d+$. The description goes beyond the schema by stating the parameter's provenance (from nearby/stops/search_place), reinforcing the no-prefix rule, and explicitly warning not to guess the ID. This adds meaningful semantic guidance for the only parameter.

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

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

The first line states a specific verb plus resource: 'POI-Detail-Lookup per OSM-ID' and clarifies the tool answers 'Öffnungszeiten von X' or 'erzähl mir was über X' rather than general knowledge. It differentiates from siblings by explicitly naming alternatives like lookup_place_osm, search_place, connections, and departures.

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 contains explicit 'When to use' and 'When NOT to use' sections, names concrete alternatives for excluded cases, and even provides typical chains with triggers. The guidance that osm_id must come from prior tool calls and never be guessed is especially valuable for correct invocation.

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 the tool read-only, and the description adds an explicit anti-fabrication rule: tide times must come only from tool output and must not be estimated from general knowledge. It also discloses the multi-call pattern (one call per place/date range), which is useful behavioral context beyond the schema and 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 long but densely structured with bolded sections for when-to-use, when-not-to-use, required args, typical chain, multi-call, and anti-fabrication. Every section earns its place and the most important scoping information is front-loaded.

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 tool with no output schema, the description compensates well: it explains the invocation contract, the coordinate vs city modes, exclusions, chaining, and even tells the agent to rely only on returned values. Nothing needed to select and call the tool correctly is missing.

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

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

The schema already covers 100% of parameters, so the baseline is 3; the description adds value by grouping the either/or requirement (city vs lat+lon), noting which parameters only apply in coordinate mode, and giving station_limit/date range semantics. This goes beyond the schema but the schema was already thorough.

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

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

The description clearly states that this tool answers tide (high/low water) questions for coastal places and explicitly positions it against general world knowledge and sibling tools like get_current_weather. It gives concrete example queries in both German and English, making the resource and scope unambiguous.

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

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

The description provides a dedicated 'When to use' section with positive examples, a 'When NOT to use' section naming get_current_weather and connections/stops, and even warns against inland locations. It also prescribes the typical chain with search_place, leaving no ambiguity about when this tool should be selected.

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 readOnly/openWorld/destructive annotations, it discloses honest-fallback behavior for empty sources, states that data never comes from training knowledge, explains that absent fields/facts/license are deliberately omitted, and documents the re-search scoping behavior. This is substantial additional behavioral context that annotations alone would not provide.

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 very long but well-structured with bold headings, front-loaded purpose, and uses sections. It earns most of its length through necessary edge-case and provenance rules, though some repeated 'additiv/abwesend' phrasing could be trimmed.

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 documents the return shape (id, sources[].subjects[].properties, facts, hub_detail_url, license), tour-specific fields, and fallback semantics. Coverage is strong enough for an agent to invoke the tool correctly and interpret results without external knowledge.

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?

Though schema coverage is 100%, the description adds critical semantics: id can be id or global_id from search_tourism and must not be guessed; query is a region/name hint because the source has no object-by-id endpoint and its absence can cause honest-empty. It also gives a concrete id example.

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 verb and resource: 'Kuratiertes Detail zu EINEM Niedersachsen-Hub-Treffer per id' listing the fields (description, opening hours, price, address, media). It explicitly differentiates from get_poi_details and search_tourism, making the purpose unmistakable even among siblings.

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

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

It provides dedicated 'When to use' and 'When NOT to use' sections, names alternatives (get_poi_details, search_tourism), and gives a typical chain plus multi-call guidance. The conditions for when not to use (no prior search_tourism hit, no guessing ids) are explicit and actionable.

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 readOnlyHint, openWorldHint, and destructiveHint, and the description adds valuable context beyond them: forecast values must come only from the tool output (anti-fabrication), coordinates must originate from search_place, one call per place, multi-day queries via limit, and the mandatory GeoNutzV attribution naming Deutscher Wetterdienst. This significantly enriches the behavioral contract without contradicting any annotation.

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 long but densely structured with bolded labels ('When to use', 'When NOT to use', 'Required args', 'Typical chain', 'Multi-call', 'Anti-Fab note', 'attribution'). Purpose is front-loaded, and every section earns its place by conveying a distinct operational rule. 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?

Despite having no output schema, the description covers all needed call context: parameter semantics, chaining, multi-call behavior, data integrity rules, and attribution obligations. The absence of a return-structure description is mitigated by the instruction that forecast values come exclusively from tool output, and the agent can inspect the actual response at runtime.

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 meaning beyond the schema: it marks lat/lon as required and sourced from search_place (never self-estimated), explains limit as forecast slots that span multi-day queries, and lists units and lang with their defaults and examples. This is substantive semantic guidance, not mere repetition.

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 verb+resource: 'Wetter-Vorhersage zu Koordinaten' (weather forecast to coordinates) and explicitly states this tool is the answer for 'wie wird das Wetter morgen in X'. It also differentiates from siblings by naming get_current_weather and get_tide as the tools for current conditions and tides, so an agent can disambiguate immediately.

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 provides explicit 'When to use' and 'When NOT to use' sections with concrete examples in both German and English, and names the exact sibling tools to use instead. It also gives a typical chain (search_place → THIS_TOOL → optional POI tools) and a multi-call rule, leaving no ambiguity about when to select this tool.

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

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

Even though annotations already declare readOnlyHint=true and openWorldHint=true, the description adds real behavioral detail: the result is a single instant (start == end), unresolvable phrases return candidates: [], and the agent must not fabricate dates or do its own date arithmetic. Nothing 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 fairly long and restates some schema details, but it is well structured: purpose and examples first, then parameters, then response semantics, then anti-fabrication guidance. Every part earns its place, though a bit of trimming would make it tighter.

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 tool with no output schema and subtle semantics (timezone interpretation, vague phrases, single-instant result), the description is complete: it states the return shape, where the value flows (connections.time / departures.time), the empty-candidates behavior, and the required follow-up action. It also points to get_usage_guide for finer details.

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 four parameters. The description adds meaningful operational semantics beyond that: text is marked as Pflicht, tz default is explicitly tied to Europe/Berlin local-time interpretation, and format is labeled as something the agent should leave out. This is more than the baseline needed for full schema coverage.

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 uses a specific verb+resource construction: "Löst eine Zeit-Nennung in einen absoluten ISO-8601-Zeitpunkt auf" and then gives concrete examples like "morgen früh" and "in zwei Stunden". It also states a clear boundary against a sibling scenario (full ISO-8601 with offset needs no call), so an agent can tell exactly what this tool does.

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 invoke (any time mention), when not to invoke (user already gave a complete ISO-8601 timestamp with offset), and points to get_usage_guide for the ambiguous-time case. It even instructs the agent to use this tool as the canonical source for "now" instead of inventing a date, which is strong usage guidance.

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

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

Annotations already declare readOnlyHint=true, 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?

Beyond the readOnly/openWorld/destructive annotations, the description discloses normalization rules (omit für/von/nach, keep leading am/an/in), argument-error behavior for invalid node_types, the fact that only a `stop` yields a usable routing ID, and an explicit anti-fabrication rule ('nie eine erfinden'). No statement 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 text is dense but organized with bold semantic chunks (Pflicht, Optional, Art-Wort, A→B, Anti-Fab) and front-loads the core purpose before details. Every sentence carries a distinct rule or pointer, so the length is justified by the tool's complexity.

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 7-parameter resolver with no output schema, the description covers the call intent, all relevant parameter semantics, the two-call A→B pattern, result shape (type and location, stop-only ID), and anti-hallucination guidance. It even routes to `get_usage_guide` for remaining depth.

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 already 100%, and the description still adds substantial meaning: `lat`/`lon` are ranking bias, `node_types` combinability and error behavior, `city_station` city→main-station behavior, and the rule to move the user's type word out of `query` into `node_types`. This goes well beyond the schema descriptions.

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

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

The description names a precise verb and resource: it resolves free text ('Löst Freitext') into an ID for stops, addresses, or POIs, and situates itself in concrete flows (routing, departure board, POI profile). It also differentiates itself from the sibling `search_place` by explicitly assigning areas (Stadt/Region) to that tool.

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 states when to call it ('Wo Routing, Abfahrtstafel oder POI-Steckbrief eine Id brauchen, steht es davor') and gives an explicit alternative: areas go to `search_place`. It also includes actionable call patterns (A→B call twice), prerequisites for `city_station`, and points to `get_usage_guide` for further delimitation.

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?

Annotations already mark the tool read-only, open-world, and non-destructive, and the description is consistent with that. It adds substantial behavioral context: vicinity-mode semantics, OSM breadth only in vicinity mode, de-duplication rules, DZT source fallback, per-result licensing and attribution requirements, and an explicit anti-fabrication policy for empty results. 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 very long, but its length is largely justified by 11 parameters, sibling disambiguation, source-licensing rules, and no output schema. Bold section labels such as 'When to use', 'When NOT to use', 'Typical chain', and 'Anti-Fab note' make it navigable. A few points are repeated or could be tightened, but the density is purposeful rather than padding.

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

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

With no output schema, the description carries the full burden of explaining return values, and it does: it sketches the full return shape (place, source, type, returned, pois[], events[]), defines per-result fields, explains license and hub_detail_url semantics, and tells the agent how to behave when results are empty. It also covers multi-call patterns and the typical search_tourism → get_tourism_details chain. Nothing essential for correct invocation is missing.

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

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

Schema coverage is 100%, but the description adds meaning well beyond the schema: the one-of region/query requirement, type aliases like accommodation=hotel and gastro=restaurant, the behavior of unknown type/activity values, the family_only/indoor_only coupling, and the constraint that activity applies only to type=tour. It also clarifies timeframes, defaults, clamps, and the role of lat/lon in vicinity mode. This is far more than the schema alone provides.

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: a curated tourism search over the Niedersachsen-Hub, contrasting its editorial depth (events with dates, prices, descriptions, opening hours, tours) with OSM breadth. It explicitly names sibling tools it is not, such as expand_kg_pois, nearby, and search_place, so an agent can disambiguate without opening 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?

The description gives explicit when-to-use guidance with concrete German and English example queries for events, accommodations, gastronomy, and tours. It also gives equally explicit when-not-to-use routing to expand_kg_pois, get_tourism_details, connections/departures, and weather/tide tools, plus a typical call chain. This is exemplary usage guidance.

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