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

With no annotations, the description carries the behavioral burden and does substantial work: it enumerates all six comparison criteria with their semantic meanings (e.g., 'driest: Lowest precipitation probability'), describes the ranked output shape, and implies aggregation across multiple locations. It does not disclose potential multi-API-call cost or failure behavior for invalid locations, but the criteria and return-structure detail go well beyond the schema.

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

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

The description is well-organized with clear bolded headers, a front-loaded summary of purpose, and no wasted sentences in the criteria or args sections. The Examples block is mildly redundant with the criteria and usage sections, making it slightly longer than strictly necessary, but each section still earns its place.

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

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

Given 0% schema coverage, no annotations, and a loose input schema, the description must bear the full explanatory load — and it succeeds. It covers every parameter's semantics, defaults, and valid ranges, enumerates all criteria values, explains the output structure (criteria, ranked locations, winner, details), and gives usage scenarios. Nothing needed to invoke the tool correctly is missing.

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

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

Schema description coverage is 0%, and the description fully compensates. For 'locations' it specifies the required dict keys ('name', 'latitude', 'longitude') that the loose 'additionalProperties: true' schema omits. For 'criteria' it documents every valid value with a definition despite no enum in the schema, and for 'forecast_days' it adds the 1-16 valid range beyond the bare integer 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 opening sentence states a specific verb and resource — 'Compare weather conditions across multiple locations' and 'Rank locations by specified weather criteria to find the best destination.' This clearly distinguishes it from single-location siblings like get_weather and get_air_quality, and the multi-location scope is explicitly stated.

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?

A dedicated 'Use this tool when' section lists concrete trigger scenarios: choosing between multiple destinations, planning group activities, and finding optimal conditions for specific activities. It provides clear context but does not name alternatives or state when not to use it (e.g., no explicit 'for a single location use get_weather'), so it falls short of the full when/when-not standard.

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 and uses it well: it reveals the Europe-only pollen limitation, explains that pollen returns None outside Europe, discloses both EAQI and USAQI interpretation bands, and describes the current/hourly/pollen/location output structure. It does not cover error behavior or data freshness, but the key gotchas an agent needs are disclosed. 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 front-loaded — the first sentence states the core function — and uses clear section dividers (Examples, Provides, Health Guidelines, Use this tool when) that make it scannable. It is long, however: the Returns prose partially duplicates the existing output schema, and the full AQI/UV interpretation tables add bulk, so not every sentence strictly 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 five-parameter tool with no annotations and an output schema, the description covers purpose, when-to-use scenarios, paramter semantics, output shape, and an edge case (pollen outside Europe). The notable omission is a cross-reference to the sibling search_location/search_location_swiss tools for resolving the place-based example queris ('Zurich') into the latitude/longitude the API actually requires — a minor but real integration gap.

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's Args section does the heavy lifting — and it adds genuine meaning: decimal-degree units for coordinates, the 1-5 range for forecast_days, defaults for forecast_days/include_pollen/timezone, and the Europe-only caveat for pollen. This fully compenates for the empty schema. The only gap is that timezone lacks format guidance (e.g., IANA timezone names).

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

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

The opening sentence uses a specific verb and resource — 'Retrieves air quality forecast including AQI, pollutants, UV index, and pollen data' — and enumerates its data contents, making the tool's scope unmistakable. This clearly distinguishes it from sibing tools like get_weather or get_marine_conditions without requiring the agent to open any schema.

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

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

The 'Use this tool when' section lists four concrete scenarios (asthma/allergy outdoor planning, exercise assessment, pollen checks, UV sun safety) that give an agent clear selection context. However, it stops short of stating when NOT to use it or naming an alternative tool like get_weather for weather-specific queris, so it lacks the explicit exclusions that would earn 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 present, so the description carries the behavioral burden. It discloses the provided data fields, the return dictionary structure, and important timezone behavior ('auto' tries to auto-detect). It could mention read-only nature or potential data limitations, but nothing contradicts the operation.

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 longer than average but well-organized with headings, use cases, examples, and return structure. The core purpose is front-loaded, and each section earns its place even if a few examples could be trimmed.

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

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

For a low-complexity tool with three parameters, the description is complete: it explains data provided, use cases, example queries, parameter semantics, and return fields. The output schema exists, and the description covers the relevant return values, so an agent has enough context 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%, but the Args section compensates fully by explaining latitude, longitude, and timezone in meaningful terms, including units and the auto-detect behavior of the default timezone. This adds substantial value 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 states a specific verb and resource: 'Provides astronomical data for a location (sunrise, sunset, golden hour)'. This clearly distinguishes it from sibling tools like get_weather, get_snow_conditions, and get_air_quality by focusing on astronomy-specific times and photography 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 provides clear use cases such as photography location scouting, event planning, and sunrise/sunset viewing, plus concrete example queries. It does not explicitly say when not to use it or name alternative tools, but the context is 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 available, the description carries the full burden of behavioral transparency. It goes beyond a simple action by disclosing the scoring scale, the exact factors included, and the return dictionary structure with overall index, factor breakdown, and recommendation. This gives an agent a strong mental model of how the tool behaves.

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 sections for score interpretation, factors, examples, args, and returns. It is longer than minimal but every section adds value. There is slight redundancy between the opening summary and the 'Factors Included' list, but overall it remains focused and readable.

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 3-parameter tool: it documents all parameters, explains the score range and interpretation, lists contributing factors, provides usage examples, and describes the return value shape. Even without annotations, an agent has enough context to invoke the tool correctly and interpret its result.

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

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

The input schema has zero description coverage, so the description must compensate. It does so by defining each parameter: latitude and longitude in decimal degrees, and timezone as a timestamp timezone with a default of 'auto'. This adds essential meaning that the schema alone does not provide.

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: 'Calculates outdoor activity comfort index (0-100).' It clearly distinguishes itself from sibling weather tools by explaining that it combines weather, air quality, UV, and precipitation into a single derived score, making its purpose unmistakable.

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

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

The description provides clear usage context through the 'planning outdoor activities' framing and concrete example queries like 'Is it good weather for hiking?' This implies when to use it, but it does not explicitly name alternatives or state when not to use it versus 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 disclosure burden. It reveals the 80+ year data archive, the effect of include_hourly, date-range inputs, and the shape of the response. It does not mention API limits or the fact that it does not return current conditions, but it is substantially transparent for a read-only historical query 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 well-structured with a clear first sentence, a supporting '80+ years' fact, use cases, examples, Args, and Returns sections. It is longer than minimal, but the length is justified given zero schema descriptions and six parameters to document.

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?

All required parameters are identifiable, optional behavior is described, and the return structure is outlined. The description gives enough context an agent needs to decide and call the tool correctly, though it could mention maximum date range or timezone semantics explicitly.

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 Args section is essential. It documents all six parameters, including decimal-degree latitude/longitude, ISO date format, defaults for include_hourly and timezone, although it could have provided more detail like date-range constraints.

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 clear verb and resource: 'Retrieves historical weather data' for trend analysis. The word 'historical' differentiates it from current-weather siblings like get_weather, and the use cases and examples reinforce the intended 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?

Provides explicit use cases and realistic example queries that tell an agent when this tool is appropriate, such as year-over-year comparisons and climate research. However, it does not explicitly contrast it with alternatives or state when not to use it.

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

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

With no annotations provided, the description carries the full disclosure burden. It transparently details what data is returned (wave height in meters, direction, period, swell, wind-wave parameters, hourly/daily forecasts) and the return container. It does not discuss limitations like geographic scope, update frequency, or data source, but for a read-only retrieval tool the behavioral disclosure is strong.

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

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

The description is organized into clear sections (summary, examples, provides, use-case, args, returns) and is front-loaded with the core purpose. The examples and use-case list add practical context, though the content is somewhat longer than strictly necessary for an agent to invoke the tool correctly.

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 5 parameters, no schema-level descriptions, and an output schema, the description adequately covers invocation details: required and optional parameters, defaults, ranges, and returned fields. It could be more complete by stating the exact geographic coverage and any data-source caveats, but nothing essential for calling the tool 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 has zero parameter descriptions, so the description's Args block provides all semantic meaning. It explains latitude and longitude in decimal degrees, gives the valid range and default for forecast_days (1-16, default 7), and clarifies the boolean and timezone defaults. This fully compensates for the sparse 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: 'Retrieves marine conditions for lakes and coastal areas,' clearly distinguishing it from general weather tools. It further specifies the data domain (wave height, swell, period, wind-wave states) and provides concrete examples, so an agent can immediately tell it apart from siblings like get_weather and get_snow_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 'Use this tool when' section explicitly lists water sports planning, boating safety, and recreation planning on Swiss lakes, giving clear guidance on appropriate contexts. However, it does not explicitly state when not to use it or name alternative tools, so it stops short of a full 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 full disclosure burden and largely meets it: it reveals default behaviors (7 forecast days, hourly included, Europe/Zurich timezone), the enriched 'ski condition assessment' computation, and the exact return structure. It omits data-source provenance and latency, but for a read-only retrieval tool these are minor; no hidden mutation or destructive behavior exists to warn about.

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 content is useful and well-structured with bold headers, but it is redundant: the parameter list and returns are documented twice (once in the overview, again in the Args/Returns block). The same information spans roughly double the needed length, which dilutes front-loading.

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 5-parameter tool with zero schema descriptions and no annotations, the description is nearly self-sufficient: it explains all required and optional parameters, supplies defaults and examples, documents the nested return structure, and gives use cases. The only notable omission is guidance on coordinate validation or how this tool relates to get_weather when planning is not ski-specific.

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: every parameter is explained with a natural-language meaning, a default value, and concrete examples (45.9763 / 7.6586 for Zermatt), plus the 1-16 range for forecast_days that the schema does not convey. Minor gap: latitude/longitude valid ranges are not stated.

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 statement: 'Retrieves snow conditions and forecasts for mountain locations.' Combined with the use-case list (ski trip planning, resort checks, avalanche risk assessment), it clearly differentiates from siblings like get_weather and get_historical_weather by scope and location type.

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 'Use this tool for' section provides concrete invocation contexts (ski trip planning, checking resort conditions, mountain weather forecasts, avalanche risk assessment), which is clear contextual guidance. However, it never names alternatives or states when NOT to use it, so an agent could still confuse it with get_weather for general mountain forecasts.

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 it well: it discloses the Open-Meteo data source, no API key requirement, sub-200ms performance, enriched interpretation/formatting, and the return structure. It also implies read-only behavior by describing a forecast retrieval operation.

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 a one-sentence summary and then well-structured into Examples, Provides, Data Source, Performance, Use this tool when, Args, and Returns. It is longer than strictly necessary because 'Provides' and 'Returns' partially overlap, but every section adds useful decision or invocation 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?

The description, combined with the output schema, covers what the tool does, when to use it, how to provide each parameter, what the response contains, and operational details like data source and performance. There are no significant missing pieces an agent would need to call 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?

The schema has zero description coverage, but the Args section adds example coordinates, decimal-degree context, the valid 1-16 range for forecast_days, defaults for include_hourly and timezone, and the meaning of timezone for timestamps. This fully 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 uses a specific verb ('retrieves') and resource ('weather forecast for a location'), and enumerates concrete output fields (temperature, rain, sunshine, wind, humidity). It clearly identifies this as the general weather tool rather than snow, air quality, alerts, historical, or marine 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?

A dedicated 'Use this tool when' section lists concrete triggers: weather questions, outdoor activities, travel impact, and journey planning. It gives clear context but does not explicitly name sibling alternatives or state when not to use this tool, 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 annotation coverage, the description carries the full behavioral burden and does so thoroughly: it specifies exact thresholds for each alert type, defines the three severity levels, and explains that alerts are generated from forecast conditions. It also outlines the return structure, making the tool's behavior predictable.

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-organized with a front-loaded summary, structured bullet lists, and clearly separated sections. The examples add some value but are partially redundant with the alert-type list, so the text is not perfectly tight.

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

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

The description covers purpose, threshold behavior, severity semantics, all parameters and defaults, and return fields, complementing the output schema. The only minor gap is coordinate range validation, but for normal invocation the information is complete enough for an 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 0%, but the description compensates fully by documenting all four parameters with operational meaning: latitude/longitude in decimal degrees, forecast_hours with range and default, and timezone with default. This is exactly the semantic detail the schema alone lacks.

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 ('Generate') and resource ('weather alerts'), and explains the tool derives alerts from thresholds and forecast rather than raw observations. The alert-type list and severity levels further distinguish it from siblings like get_weather, which would return current conditions without alert generation.

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?

Example scenarios ('Check for heat waves during summer,' 'Monitor for storms before outdoor events') give clear usage context. It does not explicitly name alternative tools or state when not to use this tool, so it lacks the exclusionary guidance needed for 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, the description carries the full behavioral burden. It discloses fuzzy matching, multi-language support, country filtering, and richer outputs (population, timezone, elevation, feature type, elevation category), plus examples of multiple matches. It doesn't cover error cases or rate limits, but for a read-only search tool this is substantial.

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

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

The description is long but organized into scannable sections with the core purpose front-loaded. Some redundancy exists between the Features list and the Returns section, but each section adds contextual value.

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

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

Covers purpose, triggers, workflow, parameter details, and return structure in depth. An output schema is present, and the description still documents the returned dictionary fields. Because it doesn't mention the sibling search_location_swiss or error behavior, it stops short of complete, but it is more than sufficient 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 has 0% description coverage, so the description must compensate. The Args section provides detailed semantics for every parameter: name examples, count range (1-100), language options, and country code examples. This exceeds what the bare schema types convey.

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

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

States a specific verb and resource: 'Searches for locations by name to get coordinates for weather queries.' The examples and features clarify it converts names to coordinates. However, it does not explicitly differentiate itself from the sibling search_location_swiss tool, which would earn 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?

Includes a dedicated 'Use this tool when' section listing three concrete triggers (location name instead of coordinates, need coordinates for a city/mountain/landmark, discover locations in a country). Also provides a three-step workflow leading to get_weather/get_snow_conditions. It lacks an explicit 'when not to use' or a comparison to search_location_swiss.

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 must carry the behavioral disclosure burden. It does disclose defaults for include_features, language, and count, plus return fields, but it never reconciles the default false of include_features with examples like 'Search for Matherhorn → Mountain peak', leaving the required configuration ambiguous.

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?

Markdown sections — Feature Types, Examples, Use this tool when, Args, Returns — make the description scannable, and the purpose is front-loaded in the first sentence. A few sentences repeat the same idea, but no major section is wasteful.

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

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

The description covers inputs, defaults, examples, and returns well for a tool with one required parameter. It is incomplete because it never tells the agent when to prefer this tool over the sibling search_location, and it does not clarify how include_features must be set for the feature-type examples to work.

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 has 0% description coverage, but the Args section fully compensates: all four parameters are explained, language values are enumerated (de, fr, it, en), count is bounded (1-50), and default behavior is stated. This adds substantial meaning 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 'Search for locations in Switzerland...' and reinforces 'Specialized search for Swiss locations', naming populated places, mountains, lakes, and passes. This clearly distinguishes it from the generic sibling search_location by geographic scope and feature focus.

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 'Use this tool when' section provides concrete selection criteria: searching in Switzerland, seeking geographic features, needing coordinates, and filtering by location type. However, it does not explicitly exclude non-Swiss searches or point to search_location as the alternative, and the 'filter by location type' bullet implies a type parameter not present in the schema.

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