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

With no annotations, the description carries full behavioral burden. It discloses that the tool is interactive, that markers are colored by BAFU safety level, and that clicking reveals temperature, flow, and Swiss German description. It does not mention side effects, data source freshness, or error behavior, but for a display tool this is substantial behavioral disclosure.

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 and front-loaded with the primary purpose. Each subsequent line adds concrete behavioral detail, and there is no filler or repetition of schema information beyond what is 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 simple display tool the description covers the main interactions and map content, but it omits lang parameter semantics, any error or error-handling behavior, and does not clarify the refresh data source. These gaps leave the agent without full guidance for edge cases like invalid city values or non-German language requests.

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 only 50%, with the lang parameter lacking any description. The tool description does not compensate by explaining language values or how lang affects labels/descriptions. It only restates what the schema already says about city, and leaves the lang parameter under-specified 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 uses a specific verb and resource ('Show an interactive OpenStreetMap with all Aare monitoring stations') and adds concrete detail about marker colors and click behavior. It clearly differentiates itself from sibling view tools like forecast_view or compare_cities by focusing on the map display of monitoring stations.

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 displaying station information on a map, and the schema explains the city optionality, but it does not explicitly state when to prefer this tool over refresh_map or other station-based views. No exclusions or alternative routing are provided, so usage context is only 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?

No annotations are provided, so the description carries the full disclosure burden. It mentions the cart-clearing side effect and the return status 'canceled', which explains what will happen. It does not cover error behavior or idempotency, but the core behavioral outcome is transparent.

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 and well-structured with purpose, usage, Args, and Returns sections. The primary action is front-loaded, and every sentence earns its place with 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, the description covers purpose, usage context, parameter provenance, side effects, and return format. The only gaps are edge cases like invalid or already-canceled sessions, which are minor for correct invocation.

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 input schema only says session_id is a string, with 0% schema description coverage. The description compensates by explaining where to get session_id ('From create_checkout_session result'), which gives the agent usable sourcing information beyond the bare type.

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 a specific action ('Cancel') and resource ('checkout session'), and adds the side effect of clearing the cart. This distinguishes it from sibling tools like create_checkout_session, update_checkout_session, and complete_checkout.

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 says when to use it: when the user wants to abandon a checkout or start over. It does not name alternative tools, but the intended context is unambiguous given the checkout-related sibling tools.

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 no annotations, the description carries the full burden. It discloses that the tool 'fetches live data for every available city and ranks them,' which is useful behavioral context. However, it does not mention whether the operation is read-only, how many results are returned, or any caching or failure behavior.

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 sentences with no filler. The main action and ranking criteria are front-loaded, and the supporting use-case sentence earns its place by clarifying the intended audience and outcome.

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 no output schema and no annotations, the description covers the core purpose, data scope (all cities), data freshness (live), and ranking criteria. It omits details about output structure and the lang parameter, but for a simple read-only view tool this is nearly complete.

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 50%: sort_by is documented but lang is not. The description reinforces the meaning of sort_by through 'water temperature or safety' and 'warmest or safest spot,' but it adds nothing about the lang parameter, leaving part of the schema under-explained.

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 ('Show') and resource ('all cities ranked by water temperature or safety'), and the use case for swimmers makes the tool's intent unmistakable. This distinguishes it from siblings like get_current_temperature or compare_cities, which focus on single cities or comparisons.

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 when to use the tool ('so swimmers can instantly find the warmest or safest spot'), but it does not explicitly contrast it with alternatives or state when not to use it. There is no guidance about choosing this over compare_cities or forecast_view.

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?

No annotations are provided, so the description carries the behavioral burden. It does disclose important behavior: the cities parameter is optional and defaults to comparing all available cities, and it details the returned dictionary fields. It does not explicitly state non-mutating status or edge cases, but the read-only comparison nature is reasonably clear.

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 and then uses compact Args/Returns sections for the supporting details. There is no filler; every sentence and list item contributes useful information.

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

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

For a simple tool with one optional parameter and an output schema, the description covers parameter semantics and return structure well. It does not address invalid city identifiers or explicitly route agents away from sibling comparison tools, but these are minor 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?

The input schema only provides an optional array/null with no description, while the tool description fully compensates: it explains that cities are city identifiers, gives concrete examples ('Bern', 'Thun'), and documents the None behavior as 'compares all available cities'. This adds strong semantic value beyond the schema.

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

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

The description clearly states the verb-resource pair ('Compare multiple cities') and identifies the tool as recommended for comparing one to many cities. It does not explicitly differentiate from sibling tools like compare_cities_table, so it stops short of a 5.

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

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

It provides clear usage context by saying this is the recommended tool for comparing one to many cities. However, it does not mention when to use alternative comparison-related siblings such as compare_cities_table or fetch_comparison, so exclusions and alternatives are missing.

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 no annotations, the description carries the burden of behavioral disclosure. It adds useful UI behavior details: sortable, searchable, header card accent color, and BAFU safety color coding. However, it does not explicitly state read-only behavior, data freshness, or any side effects.

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 two concise sentences, front-loaded with the main purpose and followed by relevant visual specifications. Every sentence adds useful detail without 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?

For a simple table-view tool with no required parameters and no output schema, the description is mostly complete. It explains the display type and notable visual behavior, though it could optionally mention what happens when 'cities' is omitted or how language selection affects output.

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 50%, with the 'cities' parameter described but 'lang' undocumented. The description does not compensate for the gap: it mentions cities only conceptually and never addresses the language parameter or how city identifiers are supplied.

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 gives a clear verb and resource: 'Show a sortable, searchable table comparing Aare conditions across cities.' It is easy to understand what the tool renders, though it does not explicitly differentiate itself from the sibling 'compare_cities' tool beyond implying a table presentation.

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 is no guidance on when to choose this tool over alternatives like 'compare_cities' or other view tools. The description implies comparison use, but it does not state context, exclusions, or 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?

With no annotations, the description carries the burden of behavior disclosure. It does reveal that the tool finalizes/submits the order and that the returned payment_url must be opened by the user to pay via PostFinance Checkout, which is useful. However, it does not state whether this action is irreversible, whether the session becomes invalid, or what side effects occur beyond returning the URL.

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 only three short sentences, front-loads the primary action, and adds relevant context about the payment flow. Minor repetition of 'return the payment URL' and 'Returns a payment_url' is not wasteful because the second instance adds the important browser/payment-provider detail.

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 one-parameter tool with an output schema, the description covers the purpose, the correct timing, and the nature of the output well. It could more explicitly warn that calling complete_checkout ends the editable checkout phase, but 'finalise the purchase' implies this sufficiently.

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 the schema already explains session_id as coming from create_checkout_session. The description does not add meaning to the parameter, but with full schema coverage this is an acceptable baseline.

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 the specific action ('Submit the order') and the key output ('payment URL'), and clearly positions the tool as the finalization step after update_checkout_session. This distinguishes it from its sibling checkout tools without requiring schema inspection.

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 it: 'Use this after update_checkout_session to finalise the purchase.' This gives clear sequencing relative to a sibling tool. It does not enumerate exclusions or mention cancel_checkout_session, but the intended position in the flow is unambiguous.

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 no annotations provided, the description carries the burden of explaining behavior. It does so by describing the interactive UI, the signature visual styling, and the danger alert triggered by elevated flow, which tells the agent what output to expect. It does not cover data freshness or side effects, but 'Show' plus the UI details makes its read-only nature reasonably clear.

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 sentences with no filler; the first sentence states the core purpose and the second packs the distinguishing visual details. Details like #2be6ff and the thick teal border are purposeful for identifying the expected output style rather than decorative.

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 visual view tool with no output schema, the description covers the main rendered elements and the alert condition, which is most of what an agent needs to decide to call it. It is incomplete on how city and lang influence the output, and it does not mention sibling tools by name for routing.

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 only 50% and the description adds no parameter-level meaning: it never mentions how 'city' selects the river section or how 'lang' affects the Swiss German description. The lang parameter has no schema description, and the description does not compensate for that gap.

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: 'Show an interactive aare.guru-style dashboard of current Aare conditions.' It then enumerates the dashboard's contents (temperature, flow, BAFU safety level, Swiss German description, danger alert), which clearly distinguishes it from sibling single-value cards like get_current_temperature or get_current_conditions.

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 phrase 'dashboard of current Aare conditions' implies this is the composite view tool, distinct from forecast or historical tools, but the description never gives explicit when-to-use or when-not-to-use guidance. There are no named alternatives or exclusions, so an agent must infer routing from sibling names.

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 no annotations provided, the description carries the behavioral burden. It discloses a key side effect — 'Clears any existing cart and starts a new checkout session' — and describes the return fields. It does not cover error conditions or authorization requirements, but the material behavior an agent needs is present.

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

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

The description is well-structured with Args, Returns, and an Example. Every sentence contributes: purpose, when to use, side effect, return value relevance, parameter details, and a concrete invocation example — no filler or 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?

For a single-parameter tool with no annotations and an opaque input schema, the description provides the item structure, defaults, source of valid product IDs, and return fields. The example makes the expected call unambiguous, leaving no missing information needed to invoke it correctly.

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

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

Schema coverage is 0% and the schema only defines items as an array of objects with additionalProperties true. The description fully compensates by specifying each item's product_id type, its source list_shop_products, and the optional quantity defaulting to 1, adding significant meaning beyond the schema.

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

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

The description states a specific action — 'Create a UCP checkout session' — with a clear scope ('one or more products'), and differentiates itself by noting that the returned session_id is required for subsequent update and complete calls, which distinguishes it from sibling checkout 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 'Use this when the user wants to buy something' and tells the agent to source product_id from list_shop_products. It implies the workflow order by referencing subsequent update and complete calls, though it does not explicitly state when not to use it or compare it to cancel_checkout_session.

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 no annotations, the description carries the full burden of behavioral disclosure, but it only says 'fetch,' disclosing nothing about side effects, freshness, authorization, or what happens when cities is null. There is insufficient behavioral transparency for an agent to know the tool's operational characteristics.

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 a single short sentence, which is concise and front-loaded with the primary purpose. However, the parenthetical 'called from UI' adds little value for an agent and the brevity crosses into under-specification, leaving important details absent.

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?

Although the tool has only one optional parameter and an output schema exists, the description leaves major gaps: no usage guidance, no parameter semantics, and no behavioral context. Given the presence of similarly named siblings, this description is not complete enough for correct selection and invocation.

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 has 0% description coverage and the parameter 'cities' has no description in the schema. The tool description adds only 'for cities,' which does not explain the meaning of null, the expected array format, or the behavior when the parameter is omitted. The description only minimally compensates for the schema gap.

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

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

The description states a specific verb and resource: 'Fetch comparison data for cities.' This is clear about what the tool does. However, it does not differentiate from siblings like compare_cities or compare_cities_table, which likely overlap in purpose.

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 only usage hint is 'called from UI,' which implies an internal context but gives no guidance on when to use this tool versus compare_cities, compare_cities_table, or fetch_comparison alternatives. No exclusions, prerequisites, or alternative routing are provided.

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 no annotations, the description carries the full behavioral burden. It conveys that the tool fetches historical data and is UI-called, but it does not describe date/range semantics, response behavior, or any constraints, which is a meaningful transparency gap.

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 short and front-loaded, with no wasted words. The parenthetical is mildly vague, but overall the structure is efficient for such a small tool.

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 an output schema, the description omits the parameter formats and does not address the ambiguous relationship with similarly named sibling tools. For an agent selecting among many history/forecast tools, this definition is incomplete.

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 0%, so the description must compensate, but it does not explain the expected meanings or formats of city, start, or end. The phrase 'historical time-series data' weakly implies start and end form a date range, but no concrete parameter semantics are provided.

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 action and resource ('Fetch historical time-series data'), which is clear and distinguishes it from UI-invoked fetching. However, it does not differentiate from the closely named sibling get_historical_data or historical_chart, so it is not fully distinct.

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 is no guidance on when to use this tool versus alternatives such as get_historical_data or historical_chart. The parenthetical '(called from UI)' hints at invocation context but never says when an agent should choose 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?

No annotations are present, so the description carries the burden of behavioral disclosure. It does indicate the card is interactive and describes its displayed content, implying a read-only presentation tool. However, it does not disclose side effects, data freshness, language behavior, or behavior for invalid city values.

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 two short sentences, front-loading the purpose and then adding concrete detail. There is slight redundancy between 'Show an interactive... card' and 'Displays...', but no filler or unnecessary content.

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

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

For a simple two-parameter card with no output schema and no annotations, the description covers the displayed content well. However, it omits how city and lang influence the result and gives no usage context relative to the many sibling view and refresh tools, leaving some inference to the agent.

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 50%: city is documented with examples and a default, but lang has no description. The tool description does not mention either parameter or explain how city and lang affect the card, so it adds no semantics beyond the schema and does not compensate for the undocumented lang 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 description clearly states the tool shows an interactive Aare flow and safety level card, and then specifies the exact content: flow in m³/s, BAFU safety assessment, and color-coded zones. This distinguishes it from data-retrieval siblings like get_flow_danger_level, though it does not explicitly name an alternative.

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?

No guidance is given for when to use flow_card versus sibling tools such as aare_map, get_flow_danger_level, conditions_dashboard, or other card views. There are no conditions, exclusions, or alternative tool names 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?

No annotations are present, so the description itself must convey behavior. 'Show' and 'Displays' signal a read-only rendering operation, and it discloses the data source (MeteoSwiss symbols) and chart/card composition. However, it does not mention side effects, data freshness, or error/empty-city behavior; for a view this is a modest rather than severe gap.

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 short sentences, each adding distinct content: the first states the core deliverable, the second adds the water-temperature and weather-prognosis details. There is no filler or repetition of the title.

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?

The description captures the main visual components and data source, which is good for a simple view with no output schema. It falls short on lang semantics and on when to use this tool versus sibling forecast/refresh tools, so an agent has to infer part of the calling 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?

City is documented in the schema with examples, but lang is not described anywhere, and the description does not mention either parameter or how they affect the forecast. With only 50% schema coverage, the description fails to compensate for the undocumented lang 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 description opens with 'Show a 24-hour forecast with air-temperature chart and hourly card strip', which names a specific action and deliverable. It further details the water-temperature trend and MeteoSwiss weather prognosis, making it clear this is a rendered view rather than a data-fetch endpoint. It does not explicitly contrast with siblings like get_forecasts or refresh_forecast, so it stops short of a 5.

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

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

No sentence addresses when to invoke this tool versus get_forecasts, refresh_forecast, or current-condition views. The description only enumerates displayed content, leaving the agent to infer that it is for presenting forecast UI. There are no exclusions or alternative routing cues.

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?

No annotations are provided, so the description bears the transparency burden. It indicates the tool returns complete current conditions and is the most detailed option, but it does not disclose specifics like data sources, potential failure modes, or that it is read-only. The 'get' prefix implies read-only behavior, so this is adequate but not rich.

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 fluff. Purpose is front-loaded, usage guidance follows, and the 'most detailed tool' claim reinforces selection 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?

For a single-parameter tool with an output schema, the description is complete enough. It gives clear use cases and the schema handles parameter and return details. It could mention that the city defaults to Bern, but the schema already covers that, so no significant gap exists.

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 the schema already provides a clear explanation of the 'city' parameter, including examples and a pointer to list_cities(). The tool description adds no additional parameter meaning, so the baseline score of 3 applies.

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

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

The description states a specific verb and resource: 'Get complete current conditions for a city.' It explicitly distinguishes itself from siblings by calling itself 'the most detailed tool,' separating it from get_current_temperature and get_flow_danger_level.

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 the tool: 'for safety assessments, 'is it safe to swim?' questions, and when users need a complete picture before swimming.' It does not mention exclusions or alternatives, but the context is sufficiently clear for selection.

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?

No annotations are provided, so the description carries the burden of behavioral disclosure. It discloses the response contents (temperature in Celsius, Swiss German description, and swimming suitability), which are not otherwise visible. It doesn't mention data freshness or error behavior, but for a simple read tool this is reasonably transparent.

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, with the core action front-loaded. The example Swiss German description adds useful concreteness without bloat. 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?

For a simple one-parameter read tool with an output schema, the description covers purpose, usage context, and return semantics. The schema covers parameter details, so 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?

The input schema already covers the single parameter fully, including the default value and how to discover available cities. The description adds little beyond 'for a city,' so the baseline of 3 is appropriate given the 100% 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 states a clear verb and resource: 'Get current water temperature for a city.' It differentiates this from siblings like get_flow_danger_level or get_current_conditions by focusing specifically on water temperature and quick checks.

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 says to use it for 'quick temperature checks' and simple water-warmth questions, providing clear context for when it is appropriate. It doesn't explicitly name alternatives or exclusions, but the stated use case is distinct enough among the sibling tools.

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?

No annotations are present, so the description carries the full burden. It discloses the output type and provides interpretable danger thresholds, but it does not mention data freshness, potential delays, failure behavior, or limitations of the BAFU assessment. That is a meaningful gap for a safety-critical tool.

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 purpose, then gives a clear use case and a compact threshold table. Every sentence earns its place and there is 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 one-optional-parameter tool with an output schema, the description provides purpose, usage context, and interpretive thresholds. The schema covers parameter discovery and defaults, so nothing essential is missing for correct invocation.

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 already documents the city parameter, default, and list_cities() discovery path. The description adds no additional parameter semantics, so the baseline 3 applies.

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

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

The description states a specific verb ('Get'), a clear resource ('current flow rate and BAFU danger assessment'), and immediately distinguishes itself from forecast, historical, temperature, and condition siblings. The safety context further clarifies its unique role.

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 says to use it for safety-critical questions about current strength and swimming danger. It does not name specific alternatives or state when not to use it, so it stops short of a 5.

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

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

With no annotations provided, the description carries the behavioral disclosure burden. It adds useful behavioral context by mentioning concurrent fetching and by explaining the return shape as a mapping from city to forecast data. It does not cover edge cases like unknown cities or failures, but for a simple read-only forecast tool this is a reasonable level of transparency.

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 and front-loaded with the main purpose, followed by structured Args/Returns sections. It loses a point for minor redundancy between 'Dictionary mapping city names to forecast data' and the nested 'forecasts (dict)' bullet, which slightly muddies the return shape.

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 single-parameter tool with an output schema, the description is largely complete: it gives the required input, an example, and a high-level summary of what will be returned. It could be more thorough about error behavior or accepted city identifier formats, but the essentials needed to invoke the tool correctly are present.

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 0%, so the description must compensate, and it does: it documents the `cities` parameter as a list of city identifiers and provides a concrete example (`['Bern', 'Thun']`). This adds real meaning beyond the bare array-of-strings schema, though 'identifiers' remains somewhat underspecified.

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 specific verb and resource: 'Get forecasts for multiple cities.' It further clarifies the resource by listing return contents (current temp, 2-hour forecast, trend), which distinguishes it from sibling single-city/current-condition tools such as get_current_temperature and get_current_conditions.

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 clearly signals that this tool is for multiple cities and that all forecasts are fetched concurrently, which gives an agent a clear reason to choose it over single-city alternatives. However, it does not explicitly name sibling tools or state when not to use it, so it stops short of a 5.

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

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

No annotations are provided, so the description carries the full burden of behavioral disclosure. It does disclose a key behavior: it returns hourly data points for temperature and flow, which sets expectations for granularity and variables. It does not mention limitations such as date-range caps, time zones, units, or data availability, which would be useful for a tool with no annotation safety profile.

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 sentences, with the core action first, use cases second, and return shape third. There is no filler, no repetition of schema details, 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?

The tool is simple: three fully documented required parameters and an output schema, so the description does not need to restate return values. It provides enough selection context through use cases. It would be more complete with a pointer to sibling tools like fetch_history or historical_chart for different historical needs, and with a note on any time or units assumptions.

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 input schema already provides 100% coverage, documenting city, start, and end with format examples, so the baseline is 3. The description adds no parameter-specific meaning beyond confirming the returned data is hourly temperature and flow. Thus no bonus above baseline is warranted.

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 specific operation ('Get historical time-series data') and clarifies the resource scope: hourly temperature and flow data. It also lists concrete use cases such as trend analysis and statistical queries, so an agent can distinguish it from current-condition and forecast tools. However, it does not explicitly differentiate it from similarly named siblings like fetch_history or historical_chart, so it stops short of a 5.

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

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

The second sentence explicitly states when to use the tool: 'Use this for trend analysis, comparisons with past conditions, and statistical queries.' This gives clear selection context versus current-conditions or forecast tools. It does not mention when not to use it or name alternative siblings such as compare_cities or fetch_history, so it earns a 4 rather than a 5.

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

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

No annotations are provided, so the description must carry the burden. It implicitly indicates a read-only operation and describes the return dictionary, but it does not explicitly state side-effect-free behavior, error behavior, or access requirements.

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 purpose and usage, followed by clearly separated Args, Returns, and Example sections. Every sentence contributes useful information with 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 read tool, the description fully covers the use workflow, parameter provenance, and return shape. Output schema exists, so the included return fields are a bonus rather than a requirement.

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 input schema only specifies an integer, but the description adds meaning: 'product_id: WooCommerce product ID (from list_shop_products result).' This clarifies the parameter's source and semantic role, compensating for the 0% schema description 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?

States a specific action and resource: 'Get detailed information about a specific shop product.' It clearly differentiates from list_shop_products by emphasizing 'specific' and later referencing the list step.

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

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

Gives explicit workflow context: 'Use this after list_shop_products... before adding it to a checkout session.' It does not explicitly mention when not to use sibling tools like product_view or refresh_product, so it misses the full when-not 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?

No annotations exist, so the description carries the full burden. It discloses the visual style and color palette, which is a useful behavioral trait, but it does not mention side effects, return format, performance, or error handling. The read-only nature and chart output are implied rather than explicitly stated, leaving gaps.

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 two short sentences with the primary purpose front-loaded and the color palette as supplementary detail. No superfluous words, and structure is logical.

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 no annotations, the description should cover response shape, error behavior, and limitations. It only describes the chart style, omitting how lang affects the tool, potential invalid inputs, or the exact output (e.g., image vs. HTML). For a simple chart tool this feels under-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 description coverage is 75%, yet the description adds nothing about parameter usage. It does not explain how 'start'/'end' affect the chart, what 'lang' influences, or how 'city' changes data. The description focuses solely on output style, so parameters remain as-was in the schema with no additional meaning.

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 ('Show'), a resource ('historical Aare temperature and flow'), and the format ('aare.guru-style area chart'), which clearly distinguishes it from data-retrieval siblings like 'get_historical_data' and 'fetch_history'. The purpose is unambiguous and immediately actionable.

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 no guidance on when to use this tool versus alternatives such as 'forecast_view' or 'get_historical_data'. It does not mention exclusions, preferred contexts, or note that this is for visualization only. The agent must infer usage from the name and description alone.

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?

No annotations are provided, so the description carries the behavioral burden. It discloses an important trait: the chart is derived from the existing current-conditions response and requires no additional API call. It does not discuss failure modes or permissions, but for a read-only chart view these are relatively minor gaps.

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 two short sentences with no filler. The primary purpose is front-loaded in the first sentence, and the second sentence adds valuable context about the data source and the lack of an extra API call.

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 view tool with two optional parameters and no output schema, the description covers the essential facts: what is shown, the chart type, the data source, and the network behavior. It does not address edge cases such as missing current-conditions data, but the low complexity and defaults make it reasonably complete.

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 description does not mention either parameter. The schema documents 'city' with examples, but 'lang' is only given a default of 'de' with no explanation. With 50% schema coverage and no parameter guidance in the description, an agent gets insufficient help for the 'lang' 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 description states a specific action ('Show'), a specific resource ('today's water temperature'), and a specific presentation ('intraday area chart'). It further distinguishes itself from historical/forecast siblings by explaining that it uses 'past readings from the current-conditions response' rather than making a separate historical request.

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 clear context: this is for visualizing today's temperature evolution, and it explicitly notes 'no extra API call required,' which tells an agent this is a lightweight alternative to fetching historical data. It does not name specific sibling tools or state explicit exclusions, but the intended usage is clear.

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?

No annotations are provided, so the description carries the full burden of behavioral disclosure. It discloses the return shape, the full-catalog behavior when search is None, the filtering behavior when search is provided, and the product fields, plus a usage example. It does not explicitly state read-only status or mention caching/pagination, but the overall behavior is well communicated.

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, then organized into Args, Returns, and Example sections. Every section adds practical value, and there is no redundant 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 read-only list tool with one optional parameter, the description is complete: it covers purpose, arguments, return structure, sample fields, and usage. The output schema also exists, and the description complements it rather than merely repeating 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 description coverage is 0%, and the description fully compensates. It explains that 'search' is an optional keyword filter, gives examples like 'towel' and 'cap', and specifies the behavior when set to None. This adds meaning well beyond the raw 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 opens with a specific verb and resource: 'List available merchandise from the Aareguru shop.' It is clearly distinguishable from siblings like get_shop_product (single product) and refresh_shop_catalog (cache refresh), and it names concrete use cases such as browsing products and answering 'what merch is available?'.

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 says when to use the tool ('Use this to browse products, answer... or find items by keyword'), giving clear context. It does not explicitly contrast with alternatives or state when not to use it, but the use cases are strong enough to guide an agent.

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 no annotations provided, the description carries the transparency burden. It discloses what is displayed (image, name, price, stock status, description) but does not mention side effects, required permissions, or behavior on invalid product IDs. It is adequate but not rich in behavioral detail.

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 sentences, front-loaded with the core purpose, then a list of displayed fields, and finally usage guidance. Every sentence adds value, and there is no 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?

For a simple display tool with two parameters and no output schema, the description covers the primary purpose, displayed fields, and typical usage flow. It is missing an explanation of the lang parameter and any mention of return format, but given the low complexity these are minor 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 coverage is only 50% (only product_id has a description). The description adds some context for product_id by linking it to list_shop_products, but it does not explain the lang parameter, whose schema entry has no description. Since the description fails to compensate for the undocumented lang parameter and does not clarify how parameters affect output, the value added is limited.

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 ('Show a product detail page for a konsum.aare.guru merchandise item') and enumerates displayed fields. It is clear about what the tool does, though it does not explicitly differentiate from the sibling tool get_shop_product, which may serve a similar purpose.

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 usage context: 'Use after list_shop_products to let the user inspect a specific item before adding it to their cart.' This tells the agent when to use the tool, but it does not mention alternatives or when not to use it, such as when raw product data is needed instead of a rendered page.

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?

There are no annotations, so the description carries the full burden of behavioral disclosure. It only says 'refresh', implying a side effect, but does not explain whether data is fetched, cached, invalidated, or pushed to the UI. '(called from UI)' adds context but not behavioral transparency.

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 a single efficient sentence with no filler and front-loads the verb and resource. It is concise, though the brevity contributes to the lack of behavioral and parameter detail.

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 though there is only one optional parameter and an output schema exists, the description omits essential operational context: what refresh actually does, how the cities parameter alters behavior, and why an agent might need to invoke this tool. It is minimally sufficient at best.

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 0%, so the description must compensate for the undocumented 'cities' parameter. It does not mention the parameter at all, nor explain what null means, what city name formats are expected, or how the parameter affects the refresh scope.

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: it refreshes city comparison data. It is not a tautology, but 'refresh' is somewhat ambiguous (cache invalidation vs. re-fetching) and it does not differentiate it from sibling tools like compare_cities or fetch_comparison.

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 parenthetical '(called from UI)' hints that this is an internal UI-triggered operation, which is some usage context. However, it gives no guidance on when an agent should call it versus any of the many compare/refresh siblings, and it names no 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?

No annotations are provided, so the description carries the full burden of behavioral disclosure. It only mentions 'refresh' and 'called from UI,' without explaining whether this mutates state, re-fetches data, invalidates a cache, or requires special permissions. This is a significant gap for a tool with no annotation safety hints.

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?

A single, front-loaded sentence with no filler: the verb and target come first, and the UI qualifier is a brief parenthetical. Every word earns its place, and the description is appropriately sized for a one-parameter tool.

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 low complexity (one required parameter, no nested objects, and an output schema present), the description plus schema is largely sufficient for an agent to invoke the tool. The main missing pieces are side-effect transparency and explicit sibling routing, but those are already penalized in other dimensions.

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 0%, so the description needed to compensate, but it merely restates the city parameter. The singular required string 'city' is self-descriptive, yet no format, example, or further constraint is provided, and the description adds no semantic value beyond what the schema already exposes.

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 ('Refresh'), resource ('current conditions'), and target ('a city'), and adds the UI-context qualifier. It is clear, though it does not explicitly differentiate from the sibling get_current_conditions or from refresh_temperature/refresh_forecast by naming them.

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

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

'Called from UI' implies this is an internal refresher rather than a general fetch tool, but there is no explicit statement of when to use it versus alternatives. The guidance is mostly implied, not direct.

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?

No annotations are provided, so the description carries the full behavioral disclosure burden. It only says 'refresh' and offers no details about side effects, idempotency, cache invalidation, authentication, or rate limits. This is a significant gap for a tool that mutates or refreshes data.

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 short and front-loaded, with minimal filler. The parenthetical '(called from UI)' is only marginally useful and could be removed, but overall the text is appropriately concise.

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?

The input schema is simple and an output schema exists, but the description omits what a refresh actually changes and whether repeated calls are safe. Given no annotations and a large family of similar refresh tools, this is not enough for confident invocation.

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 0%, and the description adds only 'for a city,' which largely restates the city parameter. It confirms city-scoped behavior but provides no additional format, constraints, or examples.

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 action and resource: 'Refresh flow and safety data for a city.' This identifies the operation and the target data. It does not explicitly distinguish it from the sibling refresh_safety, but the combined resource scope is reasonably clear.

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 only usage signal is '(called from UI)', which does not explain when an agent should choose this tool over the many sibling refresh_* tools. There are no conditions, exclusions, or alternatives such as refresh_safety or flow_card.

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 no annotations, the description carries the full burden of behavioral disclosure, but it only says 'refresh forecast data.' It does not explain whether this mutates cached data, whether it is idempotent, what side effects occur, or what permissions/rate limits apply. The UI parenthetical is the only extra behavioral hint.

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 a single short sentence with no filler, and the core action is front-loaded. It is concise, though the parenthetical could have been used more effectively to convey usage guidance rather than just UI provenance.

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 absence of annotations and the sparse description, the agent has no way to know what a 'refresh' entails or when it should choose this over a view/get sibling. The output schema covers return values, but behavioral and usage context remains incomplete.

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 has zero description coverage for the 'city' parameter, and the description only says 'for a city,' which largely restates the parameter name without adding format, expected values, or examples. It does not compensate for the missing schema 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 states a specific action and resource: 'Refresh forecast data for a city.' The parenthetical '(called from UI)' adds context, but it does not explicitly distinguish this tool from siblings like get_forecasts or forecast_view. It is clear enough to be understood, but sibling differentiation is left implicit.

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?

No guidance is given on when to call this tool versus the many sibling view/get tools. The phrase 'called from UI' implies it may be intended for UI-triggered refresh actions, but it does not state alternatives, exclusions, or conditions for agent use.

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?

No annotations are provided, so the description carries the full behavioral burden. 'Refresh' implies some kind of re-fetch or update, but the description does not disclose whether it mutates stored data, whether it requires special permissions, whether it has rate limits, or what side effects may occur.

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 a single front-loaded sentence with no filler. It conveys the action, resource, scope, and intended caller context without wasting 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?

Although the tool is simple and has an output schema, the lack of usage guidance and behavioral disclosure leaves important context missing. An agent cannot confidently determine when to call this tool or what calling it actually does beyond the vague notion of refreshing intraday data.

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 0%, so the description needed to add meaning to the 'city' parameter. It only repeats the parameter name and adds no clarification about whether city is a name, ID, slug, or what format is expected.

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 clear action ('refresh'), a clear resource ('intraday readings'), and a scope ('for a city'). It is distinguishable from sibling refresh_* tools by data type, though 'readings' is slightly generic and could be more specific.

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 is no explicit when-to-use or when-not-to-use guidance. The parenthetical 'called from UI' hints at an intended invocation context, but it does not tell the agent how to choose this over refresh_forecast, refresh_conditions, or other refresh siblings, or whether direct agent invocation is appropriate.

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 no annotations, the description carries the full burden, but it only says 'Refresh map data' without disclosing side effects, idempotency, data source behavior, or what triggers an actual update. The UI-call hint provides limited behavioral context but not enough for an agent to predict side effects.

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 a single, front-loaded sentence with no redundant filler: 'Refresh map data' first, then the UI context. It is appropriately short, though the minimalism borderlines on under-specification.

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 there are no annotations, the description omits important behavioral and parameter details that an agent would need to invoke and use the tool confidently. The existence of an output schema helps, but the city parameter's role and the effects of refreshing are still undefined.

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 description does not mention the optional city parameter at all, and schema description coverage is 0%, so the description must compensate but does not. The parameter name 'city' and its null default are visible in the schema, but their meaning for refresh behavior is left entirely to inference.

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 phrase 'Refresh map data' names both the action and the resource clearly, and '(called from UI)' adds a context cue about how it is triggered. However, it does not differentiate this from the many sibling refresh_* tools beyond the resource name.

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 only notes that this is called from the UI, giving an implicit usage context but no explicit when-to-use guidance. It does not mention alternatives or state when not to invoke this tool, which is especially relevant among the large refresh_* sibling family.

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 no annotations, the description carries the full burden of behavioral disclosure. 'Refresh product details' does not explain whether the tool mutates data, fetches fresh information, invalidates a cache, or has side effects. The existing output schema helps with return shape, but behavioral impact is undisclosed.

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 one short sentence with no redundant wording. It front-loads the verb and resource, and the 'called from UI' parenthetical, while modest, is the only contextual clue. It is concise, though under-specification is a separate concern.

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?

The tool is low-complexity: one required integer parameter and an output schema are present, so the basic invocation shape is clear. However, the lack of usage, alternative guidance, and side-effect disclosure makes the description only minimally complete for an agent choosing among many similar sibling tools.

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 0%, and the description adds no parameter-level explanation beyond the simple fact that product details are refreshed. The single required product_id integer is self-explanatory in the schema, but because coverage is low and the description does not compensate, the parameter semantics remain under-explained.

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 ('refresh') and resource ('product details'), making it clear what the tool operates on. It is not a tautology, but it does not differentiate from siblings like refresh_shop_catalog or product_view. The parenthetical 'called from UI' adds a small amount of context but does not clarify the full scope.

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 phrase 'called from UI' provides a minimal usage context, suggesting this is intended for UI-triggered refreshes. However, there is no explicit guidance on when to choose this tool over the many sibling refresh/view tools, nor any exclusions or alternatives 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?

No annotations are provided, so the description bears the full burden of behavioral disclosure. 'Refresh' implies some state-changing or data-fetching behavior, but the description doesn't state whether it mutates cached state, whether it is idempotent, whether it triggers a slow backend fetch, or whether it has side effects.

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 single sentence has no fluff and front-loads the action, but it is under-specified rather than efficiently concise. It earns a middle score because brevity is achieved at the cost of the missing usage and behavioral context.

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 annotations, 0% schema coverage, and over 40 siblings including many refresh_X tools, this description is too thin to be complete. The output schema covers return values, but the description fails to explain refresh semantics, side effects, or how it differs from the similarly scoped safety_briefing and sibling refresh tools.

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 0% and the schema only provides 'city' as a plain string. The description adds only that the safety data is 'for a city', which barely goes beyond the parameter name and doesn't compensate for the coverage gap — no format, valid values, or city-identifier semantics are given.

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 ('refresh'), resource ('safety data'), and scope ('for a city'), which is clearly more than a tautology and matches the refresh_X naming family. It doesn't fully differentiate from safety_briefing (which also covers safety for a city), and 'refresh' itself is somewhat ambiguous about what it actually 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?

No guidance on when to invoke this tool versus its many siblings (refresh_forecast, refresh_conditions, safety_briefing, etc.). The parenthetical 'called from UI' is a faint provenance hint but provides no actionable when/when-not guidance and is ambiguous about whether the agent should call it at all.

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?

No annotations are provided, so the description carries the full burden of behavioral disclosure. It only says 'refresh cart and checkout state' without stating whether it mutates server state, requires an active session, has side effects, or differs from a plain view. This is insufficient for an agent to anticipate the tool's behavior.

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 one short sentence with no filler; the key action and scope are front-loaded. 'Called from UI' adds useful context without bloating the text.

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 one-parameter tool with no annotations and a dense sibling set, the description omits when to use it, what refreshing entails, and how it relates to cart/checkout siblings. Although an output schema exists, the missing usage and behavior guidance make the definition incomplete.

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 0% and session_id has no schema-level description. The phrase 'for a session' loosely ties the parameter to a session concept, but the description does not explain the expected format, source, or semantics of session_id, leaving the agent to guess.

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 ('refresh') and names the resource ('cart and checkout state') scoped to a session, making the core action clear. It does not explicitly contrast with sibling tools like shop_cart_view or checkout-session mutations, but the action and scope are unambiguous enough to identify the 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?

The only contextual cue is 'called from UI,' which hints at invocation context but gives no when-to-use guidance, prerequisites, or exclusions versus the many refresh_* and checkout siblings. An agent cannot determine when to choose this over shop_cart_view or update_checkout_session.

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?

No annotations are provided, so the description carries the full burden of behavioral disclosure. 'Refresh' implies a state-changing or data-reloading operation, but it doesn't disclose side effects (e.g., cache invalidation, network fetch, UI state update), permissions/authentication needs, rate limits, or what happens to the existing catalog. The '(called from UI)' note is a weak behavioral signal that doesn't explain consequences of invocation.

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?

One concise sentence with no filler; the core action and the optional filter are front-loaded. The parenthetical adds a small amount of context without bloating the description.

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?

The tool is simple (1 optional param) and has an output schema, which reduces the need for the description to explain return values. However, the lack of annotations and behavioral transparency means an agent doesn't know what refreshing entails or whether it's safe/idempotent. For a UI-triggered refresh tool, the description is minimally adequate but leaves gaps about side effects and invocation 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?

There is only one optional parameter, and schema description coverage is 0%, so the description must compensate. It adds meaning to 'search' by saying it filters the catalog refresh. With a single param and no required fields, the burden is light, but the description doesn't elaborate on search behavior (e.g., partial match, case sensitivity) or what null means beyond the schema default.

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 it refreshes the merchandise catalog and mentions optional search-term filtering, distinguishing it from siblings like refresh_shop_cart and refresh_product. The '(called from UI)' note hints at its role but is ambiguous — it doesn't clarify what 'refresh' actually returns or changes.

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 UI-driven usage, which distinguishes it from product/cart refreshes, but offers no explicit when-to-use or when-not-to-use guidance. Sibling names suggest related tools like list_shop_products and refresh_product, yet the description doesn't route the agent to alternatives or state conditions for choosing them.

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 are absent, so the description must carry the full burden. It does not disclose what 'refresh' means—whether it fetches new data from an API, updates cache, or triggers side effects. No mention of rate limits, auth, or reversibility. The 'called from UI' suggests a specific context but doesn't explain expected behavior or side effects.

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 a single, short sentence, which is concise and front-loaded with the core purpose. It's not verbose, but the sentence 'called from UI' is somewhat wasteful and adds little value, so it loses a point for not being maximally efficient.

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 parameter but no description coverage, and an output schema exists (which may help understand return format), the description is still insufficient. It omits any context about what 'sun data' includes (e.g., sunrise/sunset times, UV index) and how to specify the city correctly. It's a simple tool, but the gaps in parameter and behavioral clarity leave agents guessing.

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 0; the description adds no detail beyond the schema's 'city' parameter. The schema only lists 'city' as a string with no format or examples, and the description provides no explanation of what 'city' should be (e.g., name, ID, coordinates). This is a critical gap for correct usage.

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 verb 'Refresh' and resource 'sun data' for a city, which is clear enough, but the phrase 'called from UI' is odd and does not add semantic clarity. It does not explicitly distinguish itself from the many other refresh_* siblings beyond the 'sun' specificity.

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?

No guidance is given on when to use this tool versus alternatives. It mentions 'called from UI', hinting that it's for UI-triggered refreshes, but that is vague and not actionable. There is no mention of alternatives or conditions.

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?

No annotations are provided, so the description carries the full burden of behavioral disclosure. 'Refresh' implies some kind of update or data-fetching side effect, but the description does not explain whether it mutates caches, makes network calls, is idempotent, or requires permissions. This is a meaningful gap for an action-oriented tool.

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 a single efficient sentence with no filler. The useful UI-context qualifier is included without bloating the text, and the core action/resource pair 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?

While the tool is simple and an output schema exists, the description still omits essential context: what 'refresh' actually does, when to use this over sibling tools, and how the city parameter should be specified. With no annotations and 0% schema description coverage, this is incomplete for safe and correct invocation.

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 0%, so the description must compensate for the missing parameter documentation. It only says 'for a city,' which repeats the schema's parameter name and adds no format, identifier type, accepted values, or interpretation of the city field.

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 identifies a specific verb ('refresh') and object ('temperature data for a city'), and the parenthetical '(called from UI)' adds a useful contextual marker. It narrows the resource to temperature, which distinguishes it from many sibling tools, though it does not explicitly differentiate itself from get_current_temperature or refresh_conditions.

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 'called from UI' parenthetical implies this tool is intended for UI-triggered refreshes rather than general data fetching, which gives some usage context. However, it does not name alternatives, exclusion conditions, or when to prefer sibling tools like get_current_temperature, leaving the guidance mostly 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?

With no annotations provided, the description carries the full burden of behavioral disclosure. It only says 'refresh weather data' without explaining side effects, whether it mutates state, requires auth, is idempotent, or what happens after the call. The verb 'refresh' implies a state change but no details are given.

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 a single short sentence, which is appropriately sized for a one-parameter tool. It front-loads the action and resource, though the parenthetical 'called from UI' is somewhat extraneous and unclear, but it does not bloat the text.

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 an output schema, the description leaves crucial behavioral aspects unexplained. For a tool with no annotations, it fails to clarify the purpose beyond 'refresh', making it incomplete for an agent to decide when and how to use it correctly.

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

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

Schema coverage is 0%, so the description must compensate for the undocumented 'city' parameter. It only mentions 'for a city' without specifying whether it expects a name, ID, coordinates, or any format. This adds minimal meaning beyond the schema's type declaration.

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 action (refresh) and resource (weather data for a city), which is clear enough on its own. However, it does not differentiate from sibling refresh tools like refresh_conditions or refresh_forecast, leaving ambiguity about which specific weather data is refreshed.

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 phrase 'called from UI' is the only usage hint, but it does not explain when an agent should call this tool versus alternatives like refresh_conditions or refresh_forecast. There is no clear guidance on conditions or exclusions.

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?

No annotations are present, so the description carries the burden of behavioral disclosure. It does explain the main behavior: displaying a scale, highlighting the current reading, and translating danger levels into guidance. However, it does not clarify fallback behavior when API data is unavailable, whether the tool is read-only, or what exact output format the agent should expect.

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 two focused sentences with the core purpose front-loaded. The second sentence adds valuable context about translating the danger level into plain swimmer guidance without unnecessary detail.

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?

The tool is relatively simple with two optional parameters and no output schema, so the description is mostly adequate. Still, it lacks important context about the output format, accepted language values, and behavior when the flow_gefahrenstufe is unavailable.

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 only 50%, and the description adds no parameter-level meaning. The 'city' parameter is documented in the schema, but 'lang' has only a default with no explanation, and the description does not clarify how either parameter affects the safety briefing.

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's purpose: showing the official BAFU 1–5 danger level scale with the current reading highlighted and translating it into swimmer guidance. This differentiates it from raw-data siblings like get_flow_danger_level, but it does not explicitly name any sibling alternatives.

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?

No when-to-use or when-not-to-use guidance is provided. The description does not mention alternatives or conditions for choosing this tool over related tools such as flow_card or get_flow_danger_level.

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 no annotations, the description carries the burden of behavioral disclosure. It does state that the tool renders a full shopping cart UI with items, totals, billing address, and payment confirmation, but it does not explicitly address side effects, freshness, or authorization requirements. This is adequate but not rich.

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 and front-loaded: the first sentence states the purpose, the second adds render specifics, and the third provides usage context. Every sentence earns its place with 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 view tool with optional parameters and no output schema, the description covers the key action, content rendered, and usage sequence. It could be more complete by explicitly mentioning empty-session behavior or language parameter, but these are minor 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?

The schema already explains session_id, and the description reinforces the checkout-session connection. However, the description adds no meaning for the undocumented lang parameter, and it does not compensate for the 50% schema description coverage gap.

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 identifies the operation: showing cart contents, billing details, and order status for a checkout session. It is specific enough to distinguish from catalog/product siblings and names the checkout context explicitly.

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 an explicit usage trigger: 'Use after create_checkout_session to track your order.' It does not, however, state when not to use this tool or mention alternatives such as refresh_shop_cart.

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?

No annotations are provided, so the description carries the behavioral disclosure burden. It does this well by stating the operation is a display/view: 'Show' and 'Displays every available product with thumbnail, name, price, and stock/sale status.' It does not explicitly declare side-effect freedom or data freshness, but the view-oriented language and browsable-grid framing make the read-only nature clear enough.

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, each earning its place: action and resource, displayed content, and alternative routing. The most important scoping information is front-loaded, and there is no filler or repetition of schema fields.

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, read-only grid view with two optional parameters and no output schema, the description is complete. It tells the agent what the tool does, what it displays, when to use it, and which siblings handle related but different intents. No critical information needed to invoke 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 description coverage is 50%: the search parameter is well documented in the schema, while lang is not described at all. The tool description reinforces the 'full catalog' behavior and implies search filtering by saying it shows the full catalog, but it does not explain the lang parameter or add meaning beyond the schema. This is adequate but leaves a gap for one 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 description opens with a specific verb and resource: 'Show the full konsum.aare.guru merchandise catalog as a browsable grid.' It further specifies what is displayed (thumbnail, name, price, stock/sale status), making the tool's purpose unmistakable. It also contrasts with detail-oriented siblings by pointing to get_shop_product / product_view, so an agent can distinguish this from related 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 gives explicit trigger phrasings: 'what merch is there?' or 'show me the shop' questions. It also names alternatives for adjacent intents: get_shop_product / product_view for one item, and create_checkout_session to start a purchase. This is clear when-to-use versus when-to-use-something-else 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?

With no annotations, the description carries the behavioral disclosure burden. It conveys that the tool is interactive and displays specific data, which implies a read-only card view, but it does not explicitly state side-effect-free behavior, data source, or how city/language affect the result.

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 two short sentences with no filler; the main resource is front-loaded and the second sentence adds specific displayed fields. 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?

For a simple view tool with no output schema, the description covers the main displayed content, but it omits what 'interactive' means, how 'nearby locations' is determined, and the valid values/effect of the lang parameter. It is minimally viable but not fully complete.

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 documents 'city' with examples, but 'lang' has no description and schema description coverage is only 50%. The description does not explain either parameter or how 'nearby locations' relates to the city parameter, so it adds no parameter-level meaning beyond the schema.

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

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

The description clearly states a specific verb ('Show') and resource ('Aare sun and sunshine card'), and lists the concrete data displayed: sunshine hours, sunset time, and time-left-in-sun. It does not explicitly name or contrast a sibling like refresh_sun, so it stops short of full sibling differentiation.

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 is no guidance on when to use this tool versus alternatives such as refresh_sun or conditions_dashboard. The description implies a viewing use-case but never states a condition, exclusion, or preferred alternative.

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?

No annotations are present, so the description carries the full burden. 'Show an interactive card' implies a non-mutating display operation and it does describe the card's contents, but it does not disclose return format, data-fetch behavior, or side effects. The read-only nature is implied, not stated.

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 two sentences with no filler. The action and resource are front-loaded in the first sentence, and the second sentence adds precise content details. It is appropriately concise.

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 tool with two optional parameters, the description is mostly sufficient, but with no output schema it does not explain what the agent receives (e.g., rendered HTML, card data). It also leaves lang customization underspecified despite mentioning the Swiss German 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 50% because city has a description but lang does not. The description adds the 'Swiss German description' detail, which weakly informs the lang parameter, but it does not explain accepted lang values or city scope beyond the mention of Aare. Moderate value 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?

The description states a specific verb and resource: 'Show an interactive Aare water temperature card' and lists the content (current temperature, 2-hour forecast trend, Swiss German description). This clearly differentiates it from siblings like get_current_temperature, forecast_view, or weather_card.

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?

No guidance is given about when to use this tool versus alternatives such as get_current_temperature or forecast_view. There are no explicit conditions, exclusions, or context cues beyond the generic 'Show a card' framing.

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 no annotations provided, the description carries the full burden and does well: it discloses the mutation effect (attaching addresses), the conditional shipping fallback, and the resulting session status 'ready_for_complete'. It could go further by clarifying whether existing addresses are replaced or appended, but it discloses the key behavioral contract concisely.

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: a one-line purpose, a short usage paragraph, a compact Args block, and a Returns line. There is no filler or redundant restatement of the tool name, 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?

The description is complete for a mutation tool with zero annotations and no parameter docs in the schema. It covers workflow ordering, required parameters, optional parameters, key structures, defaults, fallback behavior, and expected return status, leaving no critical gap for an agent trying to invoke it correctly.

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

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

Schema description coverage is 0%, so the schema offers no parameter guidance. The description compensates fully by explaining the source of session_id, listing the valid keys for billing, documenting country default and optional state, and specifying shipping as optional with the same key structure.

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 pair – 'Attach billing and shipping address to a checkout session' – and distinguishes it from related siblings by placing it in the sequence between create_checkout_session and complete_checkout. An agent can immediately identify what this tool does and why it is not create, complete, or cancel.

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 it ('after create_checkout_session'), identifies it as 'Required before calling complete_checkout', and explains the fallback behavior when shipping is omitted. This gives clear selection guidance without ambiguity.

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

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

With no annotations, the description carries the burden of behavior. It discloses that the tool shows an interactive card and what data it renders, but does not clarify what 'interactive' entails or whether it triggers network requests or other side effects. No contradiction with annotations exists since none are provided.

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 and front-loaded with the primary action, followed by a single sentence listing the card's key data elements. Every sentence earns its place and there is 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 two-optional-parameter display tool, this is minimally viable: it states what the card shows and implies a read-only interactive widget. However, it lacks guidance on sibling selection, leaves lang semantics undocumented, and does not clarify the interactive behavior.

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 only 50%: city is described in the schema, while lang is not. The description itself adds no parameter-level detail, so the lang parameter remains unexplained by both schema and description.

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 specific verb and resource: 'Show an interactive Aare weather card', and lists the visible content (current air temperature, precipitation risk, 6-day forecast strip). It is clear, though it does not explicitly differentiate itself from sibling tools such as forecast_view or temperature_card.

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 is no indication of when to use this tool instead of alternatives like get_current_temperature, get_forecasts, or forecast_view. The description only states what the card displays, leaving the appropriate selection entirely to inference.

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