InfraNode

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

Annotations already declare readOnlyHint, openWorldHint, idempotentHint, and destructiveHint=false, covering the safety profile. The description adds the specific data source (UBA), which provides source transparency. No additional behavioral details (e.g., rate limits) are given, but the annotation coverage is strong.

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

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

Two concise sentences: first states purpose and pollutants; second provides source and alternative tool. Front-loaded with the main action, no filler.

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

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

For a simple one-parameter tool with a rich schema and output schema, the description covers the data source, scope, and key data returned. It also references the sibling for different use cases, making it self-contained.

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

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

Schema description coverage is 100%, with detailed resolution logic for the slug parameter. The tool description does not add parameter-level details beyond the schema, so baseline 3 applies.

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

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

The description clearly states the action ('Get'), the resource ('official air quality'), the scope ('German city'), and specific pollutants ('PM10, NO2 and more'). It distinguishes this tool from the sibling `get_city_resource` by contrasting data source (UBA vs. live nearest-station hourly readings).

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 states when to use (for official city air quality) and when not, providing the exact alternative call: `get_city_resource(slug, resource='air')` for live hourly readings. Also notes the data source (Umweltbundesamt).

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

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

Annotations already declare readOnlyHint, idempotentHint, and destructiveHint false, covering safety. The description adds valuable context by explaining the per-city source_status handling (e.g., no_data, error) and that missing sources don't spoil the answer, but it doesn't detail any other behavioral aspects like rate limits or response structure beyond the output schema.

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 concise, with a clear opening line that summarizes the core function, followed by two sentences that explain the fan-out behavior and resilience. No redundant information; every sentence adds value, and the structure 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?

With a high-confidence schema (100% coverage), rich annotations (read-only, idempotent, non-destructive), and an output schema, the description completes the picture by clarifying the per-city status handling and scope. It's fully adequate for an agent to decide when and how to use this tool versus alternatives.

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

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

Schema description coverage is 100%, so the schema already documents both parameters with examples (e.g., city slugs, supported resources). The description reinforces the meaning of 'resource' by listing supported values, but since the schema already provides this, the additional value is limited, aligning with the 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 clearly states the tool compares ONE resource across MULTIPLE cities, distinguishing it from single-city tools like get_city_resource or weather. It specifies the output format (per-city source_status) and explicitly notes read-only behavior, making the purpose unambiguous and distinct from 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 implies usage for comparing a resource across cities and notes that it fans out over listed cities, preventing one failing city from spoiling the result. It doesn't explicitly state when not to use it or name alternatives, but the mission from siblings (e.g., get_city_resource for single-city) is clear, and the 'read-only' note discourages misuse for mutable operations.

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?

The description adds value by stating the data source ('Sourced from Wikidata') and explicitly calling out the read-only nature, which aligns with and reinforces the annotations (readOnlyHint: true, destructiveHint: false). However, it doesn't disclose further behavioral traits like what happens on error or if the city is not found, though the parameter schema does mention a 404 response with suggestions. The core safety profile is well-covered by annotations, so the description provides adequate context without being overly redundant.

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 extremely concise, consisting of two short sentences. The first sentence clearly states the purpose and core data delivered. The second paragraph is front-loaded with the most critical context (data source, read-only) immediately after. Every sentence provides necessary information without redundancy.

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

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

Given the tool's low complexity (1 parameter, 100% schema coverage, clear annotations, and an output schema for return values), the description is complete enough. It covers what the tool does, its data source, its scope, and when to use an alternative. The output schema handles the return values, so the description doesn't need to explain them.

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 description coverage is 100%, with a detailed description of the 'slug' parameter including lenient resolution rules and examples. The description itself doesn't add significant meaning about the parameter beyond what the schema already provides, so a baseline score of 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 uses a specific verb ('Get') and resource ('base data') and explicitly lists the returned fields (population, area, coordinates). It distinguishes itself from its sibling 'get_city_overview' by stating this is a 'first lookup' for core attributes vs. a broader overview.

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 clear guidance on when to use this tool ('first lookup', 'confirm a city exists') and explicitly states when not to use it ('for a broader question... use get_city_overview instead'). It also mentions the data source and read-only nature.

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 convey readOnly, openWorld, idempotent, and non-destructive behavior. The description adds valuable context not in annotations: the catalog grows over time, data types not covered show where they ARE available, and the tool returns a live highlights snapshot. The only slight gap is no mention of rate limits or potential cost, but the annotations cover core safety traits well.

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 a clear opening imperative, a bullet-style enumeration of return values, and a forward-looking note about data growth. Every sentence adds value without redundancy. Front-loading is excellent.

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 only one simple parameter, the tool returns a complex response (base data, catalog, live highlights). The description thoroughly explains what the agent can expect, including how to interpret coverage gaps and the catalog's dynamic nature. The return values are well-covered, making this complete for agent decision-making.

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 slug description is already rich. The description doesn't add to the slug's semantics directly, but it provides critical context about how the tool uses the parameter (to return the overview and catalog). Given full schema coverage, baseline is 3; the extra usage context lifts it to 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 uses a strong verb-resource pair ('Get a ONE-CALL overview') and explicitly distinguishes this tool from siblings by stating it returns a catalog of all 81 data types and directs to the exact tool to call next (get_city_resource), making the purpose crystal clear and well-differentiated.

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

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

The description commands 'Start here for any city question' and provides explicit guidance on what to do next (call get_city_resource for specific data types, and pivot to other cities when data is unavailable). This gives excellent when-to-use and next-step 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 declare readOnlyHint, openWorldHint, idempotentHint, and destructiveHint. The description adds important behavior: uncovered types return source_status='not_covered' (never an error) and location hints. This goes beyond annotations and enhances the agent's understanding of the tool's safe, non-failing nature.

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 front-loaded with the core purpose in the first sentence. It then provides a comprehensive but verbose list of example data types. While the list demonstrates breadth, it could be more concise. Overall, it is well-structured and informative.

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?

Given the tool's complexity (81 data types, 2 params, output schema exists), the description adequately covers the generic accessor role, error handling, and discovery methods. The output schema presumably covers return format, so its absence in the description is acceptable. The description is complete enough for an agent to understand when to use the tool.

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%, with both slug and resource already described in detail (slug's lenient resolution, resource's enum). The description does not add new semantics for the parameters but reinforces the tool's role. Baseline 3 is appropriate since the schema handles the parameter documentation.

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 'Fetch ANY per-city data type by its key (generic accessor, 81 data types)', providing a specific verb, resource, and scope. It distinguishes itself from sibling tools like air_quality or station_board_arrivals which are specialized for individual data types.

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 advises discovering valid keys via get_city_overview or the catalog resource, and explains that uncovered types return a 'not_covered' status. This gives the agent context on when to use this tool versus overview tools. However, it does not explicitly contrast with specialized siblings.

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?

The annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the safety profile is fully covered. The description adds the behavioral trait that the tool returns slug, federal state, population, and coverage – context not in the annotations. It also states it takes no arguments, which matches the schema. The only minor gap is not explicitly confirming the return format (e.g., array of objects), but the output schema likely handles that.

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 four short sentences, each earning its place. The first sentence states purpose and output. The second and third sentences give usage guidance. The fourth confirms safety. No wasted words.

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?

Given zero parameters, full annotation coverage, and a provided output schema, the description is complete. It tells the agent what the tool does, what it returns, how to use it (call first, no args), and why it's important (discovery for city-slug-dependent tools). No gaps remain.

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

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

Schema description coverage is 100% and there are zero parameters, so the baseline is 4. The description correctly confirms no arguments are needed, which adds value by reinforcing the schema's emptiness and explaining the tool's role in the workflow.

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 clear verb ('List') and specifies the resource ('all covered cities'). It explicitly states the fields returned (slug, federal state, population, coverage), distinguishing it from sibling tools that likely operate on a single city (e.g., get_city) or require a city slug as input.

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 guidance: it takes no arguments and should be called first to discover valid city slugs before invoking any city-scoped tool. This clearly tells the agent when to use it (initial discovery) and for what purpose (obtaining slugs for subsequent tools), effectively differentiating it from all sibling tools that require a city parameter.

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, idempotentHint, and destructiveHint as false, so the description only needs to add context. It adds 'Sourced from OpenStreetMap' and 'Read-only', which reinforces the non-destructive nature and provides data provenance. No contradictions 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 extremely concise with two short sentences plus a two-word sentence, all front-loaded with the core functionality. Every sentence provides essential information without redundancy or 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?

Given the tool's simplicity (2 parameters, high schema coverage, clear annotations, and an output schema), the description is complete enough. It covers the main action, optional filtering, and data origin. One could argue it lacks explanation of the output format, but the presence of an output schema mitigates that need.

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 adds meaning by explaining that 'slug' is resolved leniently (umlauts, exonyms) and mentions a helpful error suggestion, and that 'type' is from an API allowlist with examples – going beyond the schema's basic parameter 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 clearly states 'Get points of interest in a German city, filtered by type', specifying the verb 'get' with resource 'points of interest' and scoping to German cities with type filtering. It differentiates from siblings like 'get_city' and 'list_cities' by focusing on POIs, though it does not explicitly distinguish from other location-based 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?

The description provides context for when to use (getting POIs by city and type) but offers no guidance on when not to use it or alternatives. Sibling tools like 'compare' or 'sources' could serve different purposes, but no exclusions are mentioned.

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 provide readOnlyHint, destructiveHint, idempotentHint. The description adds that it 'shows which upstream sources InfraNode bundles and whether each is currently active,' which gives useful behavioral context beyond annotations. No contradiction.

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 three short sentences with no redundancy. Every sentence adds value: first states what is listed, second confirms no arguments, third adds behavioral insight.

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?

Given 0 parameters, rich annotations, and presence of output schema (which will describe return structure), the description covers all essential behavioral aspects: data listed, argument needs, purpose. Complete for this simple tool.

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?

Input schema has 0 parameters, so no parameter documentation is needed. The description's claim 'takes no arguments' is basic but sufficient confirmation for the agent.

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 the tool lists data sources and specifies the included attributes (license, attribution, availability). It distinguishes itself from sibling tools like 'air_quality' or 'weather' which likely access specific data, not the source catalog.

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 says 'takes no arguments,' which sets boundaries. However, it does not explicitly state when to use this tool instead of siblings, e.g., to discover available datasets before querying specific ones. The 'read-only' note subtly implies safe usage.

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, destructiveHint=false, and idempotentHint=true. The description adds valuable behavioral context beyond annotations: it specifies the feed includes all train categories, real-time delays, and disruption messages. No contradictions with annotations are 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?

Three short, focused sentences. First sentence states the core purpose with emphasis on any station. Second clarifies the sibling relationship. Third provides a prerequisite. No unnecessary words; every sentence 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?

Given the tool has a single parameter, full schema coverage, an output schema (not shown but present), and comprehensive annotations, the description provides sufficient context. It covers data type (live arrivals), scope (any station), supported features (delays, disruptions), and how to get the required input.

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% with a detailed parameter description. The description adds further value by explicitly instructing how to obtain the EVA number from 'get_city_resource', which is a helpful cross-reference that goes beyond the schema's own explanation.

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 title 'Station Board: Arrivals' and description clearly state the tool retrieves live arrivals for railway stations by EVA number. It explicitly distinguishes itself from the sibling 'station_board_departures' by calling itself its mirror for arriving trains, making purpose and differentiation 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?

The description explicitly states when to use: to get live arrivals. It contrasts with departures by referencing the mirror relationship, advises on obtaining the EVA parameter via 'get_city_resource', and declares the tool read-only. This provides clear usage context and alternatives.

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 provide readOnlyHint, idempotentHint, and destructiveHint. Description adds context about real-time delays, cancellations, and disruption messages, and states 'Read-only', which is consistent. It provides extra behavioral context beyond what annotations convey.

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

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

Three sentences with no wasted words. First sentence states purpose, second adds coverage details, third provides parameter sourcing. Information is front-loaded and every sentence 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?

Given the single parameter with high schema coverage, an output schema (present), and rich annotations, the description is fully sufficient. It covers the tool's purpose, data scope, and parameter retrieval without gaps.

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 baseline is 3. The description reiterates how to get the EVA number from get_city_resource, which the schema already includes. No new parameter semantics are added beyond the schema.

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

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

Description clearly states 'Get live departures for ANY railway station by its EVA number', specifying a specific verb and resource. It distinguishes from sibling 'station_board_arrivals' by focusing on departures, and covers train categories and real-time data, leaving no ambiguity.

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?

Description explains when to use (get live departures) and how to obtain the required parameter from another tool. However, it does not explicitly differentiate from siblings like 'transit_departures' or state when not to use this tool, leaving room for confusion about alternatives.

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 annotations (readOnly, destructive, idempotent), the description adds: data source (GTFS-RT/HVV/VGN), clarifies it returns minute-fresh data, and warns about incorrect stop_id formats (not trip_stop_id). This adds valuable behavioral context beyond what annotations already declare.

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

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

Three concise sentences that front-load purpose, then provide context and usage. Every sentence adds value with no redundancy.

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

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

Given an output schema exists (so return values are covered), the description thoroughly explains the tool's purpose, data source, prerequisite steps, and common pitfalls. Sibling tools are provided for differentiation.

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 critical context: stop_id is required despite default null, explains how to obtain valid stop IDs, and includes a detailed note on what NOT to pass (trip_stop_id). This goes beyond the schema's own 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 clearly states 'Get live public-transport departures with real-time delays for a stop', specifying the verb (get), resource (departures), and scope (one stop). It distinguishes itself from siblings like `get_city_resource(resource='transit')` by contrasting static vs live data.

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 tells when to use this tool vs. the static stop list via `get_city_resource`. It also provides a prerequisite: 'fetch the city's transit stops first to discover valid stop IDs, then pass one here.' No guidance on when not to use, but the sibling list includes other journey tools, and the description clearly sets scope.

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 provide strong behavioral cues: readOnlyHint=true, destructiveHint=false, idempotentHint=true. The description adds value by confirming it's read-only and specifying 'current conditions only (not a forecast)', but doesn't elaborate on rate limits, response size, or any edge cases beyond what annotations imply. With such comprehensive annotations, the description's added behavioral context is moderate.

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 compact (three sentences), front-loads the core purpose in the first sentence, and uses clear, direct language. Every sentence serves a distinct purpose: defining the tool, clarifying scope, and providing usage guidance with alternatives. No wasted words.

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?

Given the tool has only one required parameter, comprehensive annotations, and an output schema (context signal), the description covers all essential aspects: purpose, data source, scope, and alternatives. It is fully adequate for an agent to decide when and how to invoke this tool correctly.

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

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

Schema coverage is 100%, meaning the `slug` parameter is well-documented in the schema itself. The description reinforces this with concrete examples and resolves leniency details (umlauts, English exonyms), which adds meaningful nuance beyond the schema's basic description. The extra context about error handling (404 with suggestion) further enriches parameter understanding.

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 the tool gets current weather observations for a German city, specifies the data source (Deutscher Wetterdienst) and the fields (temperature, wind, precipitation). It distinguishes this from a forecast tool, and the verb 'Get' combined with 'current weather observations' precisely describes the output.

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 explicitly states when to use this tool (for current weather) and provides concrete alternatives: for weather warnings use get_city_resource, for a broader city overview use get_city_overview. This clearly guides the agent away from misuse, especially given the sibling tools listed.

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