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

With no annotations, the description carries the behavioral burden, and it does so well by explaining that the tool returns only the latest reading, covers rural baseline pollution, and intentionally excludes urban measurements. It could additionally state output format or freshness guarantees, but the core behavioral boundary is clearly disclosed.

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 action and resource, then adds a necessary background clarification and a strong use-caveat. It is slightly verbose, but every sentence contributes meaningful selection and misuse-avoidance 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?

The description covers purpose, scope, and limitations well, but it does not state what happens when neither 'station' nor 'location' is provided, even though both parameters are optional. With no output schema, the absence of a clearer return-structure description also leaves some ambiguity for 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 100%, so the baseline is 3; the description itself adds little parameter-specific meaning beyond what the schema already provides. The schema already documents station precedence and the nearest-station behavior for location, so the description does not need to compensate.

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 ('Returns'), a precise resource ('AEMET's background pollution network'), and the scope ('13 rural reference stations... O3, NO, NO2, SO2 and PM10'). It clearly distinguishes the tool from urban air-quality expectations and from sibling forecast/observation 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 states this tool is for BACKGROUND pollution and tells the agent when NOT to use it: 'It does NOT answer how is the air in Madrid/Barcelona today'. It also directs urban air-quality queries to city/regional networks, preventing misuse as a proxy.

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 forecast covers 591 beaches during the bathing season, which hints at a seasonal limitation, and mentions input flexibility (accents optional, code). It does not disclose error handling, availability, or whether the forecast might be empty outside the season, but for a read-only forecast tool these are minor. The description adds some behavioral context beyond the schema, but not exhaustive.

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, well-organized paragraph that front-loads the core purpose (three-day forecast with specific fields), then covers scope and input options. Every sentence contributes useful information with no fluff or repetition. It is appropriately sized for the tool's complexity.

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

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

The description explains the output (sky, wind, waves, temperatures, UV index) and the input methods, covering both what the tool returns and how to specify location. It does not describe the exact return format (e.g., JSON structure) or error cases, but since there is no output schema, the description provides sufficient context for an agent to call it correctly. Minor gaps like units or error handling are not critical.

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

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

Schema coverage is 100%, so the schema already documents all three parameters thoroughly. The description restates the location options (accents, municipality, code) and adds the note that a municipality alone lists beaches, but this is also present in the schema. The description does not add new semantic meaning beyond what the schema provides, so a baseline 3 is appropriate.

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

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

The description uses a specific verb ('Returns') and names the exact resource ('AEMET beach forecast') along with the covered period and data fields. It clearly differentiates from siblings like get_mountain_forecast and get_maritime_forecast by specifying 'beach' and 'AEMET', so an agent can identify it without opening other definitions.

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 it: for beach forecasts from AEMET. It also explains input options (name, municipality, code) and mentions seasonal coverage. However, it does not explicitly state 'use this for beaches, not mountains or maritime', leaving some inference to the agent. The clear resource name and sibling names make the intended usage obvious, so this is above average.

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. It discloses the 6-month/186-day limit per AEMET call, the need for multiple calls for longer histories, and the 31-day threshold that changes output granularity, plus the fields returned in each mode. This is rich behavioral context 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?

Four sentences, each earning its place: core purpose, mode behavior with limits, alternative mode, and use-case routing. It is front-loaded with the action and resource, then organized by mode. No fluff or redundant schema repetition.

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 key operational details: location resolution, mode parameters, date restrictions, output granularity, and outcome. An agent has enough to call the tool correctly and to plan pagination for long histories.

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

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

Schema coverage is 100%, so the baseline is 3. The description adds value by connecting mode to from/to behavior (dates only matter in 'range', normals ignores them), warning about condensation beyond 31 days, and prompting multi-call splitting beyond 186 days. It doesn't fundamentally add syntax, but the cross-parameter behavior is helpful.

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

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

The description states the tool finds the nearest AEMET climatological station and returns its measured history, which clearly distinguishes it from forecast and observation siblings. It also names the two modes of history, making the 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?

It explicitly says 'Use this for past weather and climate questions, not for forecasts,' giving both when-to-use and when-not-to-use guidance. The mode descriptions further tell the agent when to request a date range versus normals, so the tool is routed correctly without inspecting the schema.

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. It explains that the tool returns forecast data, describes the daily fields (temperature min/max, sky state, precipitation probability, wind), and states the hourly horizon (~40h). It does not describe error cases or response structure, but for a read-only forecast lookup the covered behavior 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 three sentences with zero filler. It front-loads the core purpose, then gives input formats, then output details. 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 tool with only three parameters and no output schema, the description covers what an agent needs to call it correctly: accepted location identifiers, the meaning of both granularities, the days range context, and the kind of response data to expect. There is no critical missing operational context that would prevent 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 already documents all three parameters at 100% coverage, so the baseline is 3. The description adds extra meaning by noting that names work with or without accents and by explaining what daily vs hourly granularity actually returns, which goes beyond the schema's parameter descriptions.

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

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

The description opens with a specific verb and resource: 'Returns the AEMET forecast for any of Spain's 8000+ municipalities.' It clearly distinguishes this from sibling tools by emphasizing municipality-level general forecasts and by listing both daily and hourly granularities, so an agent can tell it apart from beach, mountain, maritime, or historical 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 clear context for when this tool is appropriate: whenever a general municipal weather forecast for Spain is needed, by name or INE code. It does not explicitly name alternatives or state when not to use it, but the municipal scope and granularity options make the intended usage 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?

No annotations are provided, so the description carries the full burden. It discloses the scope (coastal vs high seas), content (sea state, wind, etc.), and that coastal carries warnings, which is useful. However, it doesn't mention any potential limitations, such as data availability, update frequency, or whether the bulletin is text-only vs structured. For a read-only forecast tool, this is moderately transparent but not exhaustive.

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 paragraph with dense, useful information. It front-loads the core purpose and then details the two products and naming options, all without redundancy. Every sentence adds 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?

Given the tool's moderate complexity (2 params, no output schema), the description covers the key aspects: what data is returned, product types, and area naming. It doesn't explicitly describe the output format, but since there's no output schema, a brief note on return structure would improve completeness. Minor 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 coverage is 100%, so the schema already describes both parameters thoroughly. The description adds context about naming flexibility and product selection, reinforcing the schema but not adding new syntactic details. Baseline 3 is appropriate.

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

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

The description clearly states it returns an AEMET maritime bulletin (sea state, wind, visibility, warnings, validity period) for a sea area. It distinguishes two product types (coastal and high seas) and mentions how areas can be named. It doesn't explicitly contrast with siblings like get_beach_forecast, but the maritime specificity makes it 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?

The description implies when to use it: when a maritime bulletin is needed, and it explains the two product types and naming flexibility. It doesn't explicitly say when not to use it or name alternatives (e.g., beach forecast for coastal beaches), but the guidance is clear enough for an agent to select it over non-maritime 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 provided, so the description carries the full burden of behavioral disclosure. It does this well by stating the data source (AEMET), the year-round nature, the mountain-range scope, the content of the bulletin (forecaster prose, freezing levels, wind, thermal sensation), and the differences between forecast and past modes. The only minor gap is that it doesn't describe the exact response structure or error behavior, but for a read-only retrieval tool this is a limited shortfall.

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: purpose and content are front-loaded, followed by mode behavior, then usage guidance pointing to a sibling. Every sentence earns its place and there is no filler or redundant repetition of the input schema.

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 only three simple parameters, no output schema, and no annotations, the description is remarkably complete. It tells the agent what the tool returns, for which areas, with which modes, and how it relates to the sibling get_forecast. An agent has everything needed to decide when to invoke it and what to expect.

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

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

Schema description coverage is 100%, so the baseline is 3. The description adds some contextual flavor—such as the bulletin being written for mountaineers and skiers and covering the mountain range as a whole—but it largely restates what the schema already documents for area, day, and mode.

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: 'Returns the AEMET mountain bulletin for one of Spain's nine mountain areas...' and even names the areas, which makes the tool's scope unmistakable. It also points to the sibling get_forecast as the tool to avoid for mountain use, which distinguishes it from the general forecast tool.

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

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

It explicitly tells the agent when to use this tool: 'use them instead of get_forecast for anything above the valley floor.' It also differentiates between mode='forecast' and mode='past', clarifying that forecast covers today to day 3 and past summarizes the last 24 hours, so the agent can choose the correct mode without extra inference.

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

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

No annotations are provided, so the description must carry the behavioral disclosure burden. It discloses that the nearest station is selected, that the latest reading is returned, and which variables are included. However, it does not mention units, staleness, error handling for invalid locations, or any data availability constraints.

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 wasted words. The first sentence states the action and output, and the second sentence adds a succinct usage hint, making it easy to scan.

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 a rich schema, the description covers the essential context: what it does, what it returns, and when to use it. Minor gaps such as units and edge-case behavior are acceptable for this simplicity level, though they would be valuable additions.

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 documents the single 'location' parameter exhaustively, covering municipality names, INE codes, and coordinate pairs with 100% coverage. The description adds no additional parameter-level semantics, which aligns with the baseline for fully schema-documented parameters.

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 specific action: finds the nearest AEMET weather station and returns its most recent reading. It also enumerates the returned variables, making the tool's purpose concrete and distinguishable from forecast, climate history, and warning siblings.

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

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

The phrase 'Useful for what's the weather right now style questions' provides a clear when-to-use signal. It does not explicitly mention alternatives or when not to use the tool, but the real-time observation framing is enough to route an agent correctly.

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 present, the description carries the disclosure burden, and it provides useful context: data source (AEMET), protocol (CAP), scope options, and the severity scale. It does not clarify the output structure or reconcile the title's 'Active' with the description's 'most recent', but it is neither misleading nor tautological.

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 tight sentences with no wasted words. The main action and scope are front-loaded, and the severity clarification is useful and brief.

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 side is well covered by the schema, and the description explains the domain and severity model. However, with no output schema, the agent still lacks information about the return structure, empty-result behavior, and whether results are truly active or simply most recently issued.

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

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

Schema description coverage is 100%, so the parameters are already fully documented in the schema. The description reinforces the area/severity concepts but adds little beyond the existing property descriptions.

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

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

The description states a specific verb ('Returns'), a concrete resource ('CAP weather warnings issued by AEMET'), and a clear geographic scope (autonomous community or 'esp'). This makes the tool easy to distinguish from sibling forecast, observation, and history 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 intended use—retrieving AEMET weather warnings for a region—is implied clearly by the description, and the unique 'warnings' resource separates it from siblings. However, it does not explicitly state when to prefer this tool over alternatives or give any exclusion criteria.

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