MeteoSwiss MCP Server

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

No annotations are provided, so the description must fully cover behavioral traits. It only mentions the input requirement (full URL) but omits details on error handling, rate limits, caching, or what happens with invalid URLs. The transparency is minimal.

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, front-loading the main purpose and immediately providing usage guidance. Every sentence is essential with no wasted words.

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

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

Given the lack of an output schema and annotations, the description should mention the return format or structure. It only hints at 'full content' but doesn't specify that markdown or plain text is returned, or what metadata includes. This is a gap for completeness.

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

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

Schema coverage is 100%, and the schema already describes all three parameters (id, format, includeMetadata). The description adds no new param-specific information beyond the schema, so the baseline of 3 is appropriate.

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

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

The description clearly states 'Fetch full content from a MeteoSwiss webpage and convert to markdown or plain text.' This identifies a specific verb (fetch) and resource (MeteoSwiss webpage content), and the conversion distinguishes it from sibling tools that provide structured data or weather info.

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 advises 'Use the search tool first to discover valid page URLs, then pass the full URL as the id parameter.' This provides clear sequential guidance and input requirements, though it lacks explicit 'when not to use' statements.

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 full burden for behavioral disclosure. It does well by specifying the data sources (29 climate stations + 46 precipitation stations), temporal scope (data going back decades), and available variables (temperature, precipitation, etc.). However, it doesn't mention rate limits, authentication requirements, or potential data availability constraints for specific stations/time periods.

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 efficiently structured with zero wasted sentences. It opens with the core purpose, lists available data types, specifies station counts and resolutions, provides concrete use cases, and explains parameter options - all in a compact format where every sentence adds essential 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 tool with 6 parameters, 100% schema coverage, but no output schema, the description provides strong context about what data is returned (temperature, precipitation, etc.), station network details, and temporal scope. The main gap is lack of output format details (structure of returned data), but the description compensates well with rich content about data characteristics and use cases.

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 meaningful context by explaining station input options (names, abbreviations, coordinates) and providing concrete examples ('Zurich', 'BAS', 'Davos'), which helps users understand how to properly identify stations beyond what the schema's technical descriptions 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 clearly states the tool 'gets homogeneous climate measurement series' from Switzerland's NBCN, specifying the exact resource (climate data) and action (retrieve). It distinguishes from siblings like meteoswissCurrentWeather (current conditions) and meteoswissPollenData (different data type) by focusing on historical climate series with multiple variables and resolutions.

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 examples ('What are typical January temperatures in Zurich?', 'How has precipitation changed in Basel over 50 years?') that clearly indicate when to use this tool for historical climate analysis versus alternatives like meteoswissCurrentWeather for current conditions. The examples demonstrate the tool's purpose for trend analysis and historical queries.

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 mentions data updates every 10 minutes, the difference between full and precipitation-only stations, and the additional daily observations for 8 stations. It does not mention rate limits or authentication, but is transparent 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?

The description is concise and well-structured. The first sentence states the main function, followed by details on data, update frequency, and how to specify stations. Every sentence is informative and there is no fluff.

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

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

With no output schema, the description explains what data is returned (temperature, precipitation, etc.) and special cases like precipitation-only stations and daily observations. It is fairly complete for a weather tool, though it could mention the response format.

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 describes both parameters with 100% coverage. The description adds value by clarifying that stations can be specified as names, abbreviations, or addresses, and that coordinates are an alternative, and that the tool finds the nearest station automatically.

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

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

The description clearly states the tool gets real-time weather measurements from Swiss stations, specifying the number of stations and the types of data. It distinguishes itself from sibling tools like meteoswissClimateData and meteoswissLocalForecast by focusing on current weather.

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 explains how to specify stations and that it finds the nearest station automatically. While it doesn't explicitly state when to use this tool over alternatives, the context implies it's for current 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?

With no annotations provided, the description carries the full burden and succeeds well: it discloses data source ('official MeteoSwiss Open Data'), update frequency ('Updated hourly'), coverage limits ('~6000 Swiss locations'), and return format ('daily summaries with temperature, precipitation, and weather icons'). Lacks rate limits or error behavior details.

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?

Excellent structure: purpose front-loaded in sentence one, provenance in sentence two, then a bulleted list clarifying input formats, followed by coverage metadata. No wasted words; every sentence provides unique information not redundant with the schema or annotations.

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 compensates thoroughly by describing return values ('daily summaries with temperature, precipitation, and weather icons'), input validation constraints (postal code vs. station formats), and operational bounds (9-day limit, hourly updates). Complete for a 2-parameter read-only tool.

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

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

Schema coverage is 100%, establishing a baseline of 3. The description adds significant value by providing richer examples for the location parameter than the schema alone: parenthetical city names for postal codes ('8001' (Zurich)), full station names ('ZUE' (Zurich Fluntern)), and additional place examples ('Basel', 'Lugano'). It also reinforces the days constraint via 'Forecast horizon: up to 9 days'.

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 'Get a multi-day weather forecast for any Swiss location'—a specific verb, resource, and geographic scope. It clearly distinguishes from sibling tools like meteoswissCurrentWeather (multi-day vs. current) and meteoswissPollenData (weather vs. pollen data) through explicit temporal scope ('multi-day', 'up to 9 days').

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 clear context for when to use (multi-day forecasts, up to 9 days) and implicitly contrasts with current weather via the name and 'multi-day' phrasing. However, it does not explicitly name sibling alternatives or state when NOT to use it (e.g., 'for current conditions, use meteoswissCurrentWeather instead').

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?

Since no annotations exist, description carries full burden. It adds valuable behavioral context: temporal scope ('current' data), coverage limitations ('~15 stations'), and data granularity ('pollen levels by type'). However, it omits operational details like rate limits, authentication requirements, or error behaviors that annotations would typically cover.

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: purpose/scope, data types, and use case. No redundant or filler text. Front-loaded with the core action.

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 100% schema coverage, description adequately covers data content (pollen types) and scope. Lacks explicit return value structure details (no output schema exists), but mentions 'shows pollen levels' giving partial insight into the response.

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%, establishing baseline 3. Description adds minimal parameter-specific guidance beyond schema, though '~15 stations across Switzerland' provides useful context for what valid station values might look like. No syntax or format details added beyond schema 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?

Excellent specificity: verb 'Get' + resource 'pollen concentration data' + source 'MeteoSwiss monitoring stations'. Explicitly distinguishes from weather-focused siblings via content (birch, grass pollen) and scope (~15 stations across Switzerland).

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 implied usage context ('Useful for allergy sufferers') but lacks explicit when-to-use/when-not-to-use guidance regarding siblings like meteoswissCurrentWeather or meteoswissLocalForecast. No 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?

With no annotations provided, the description carries the full burden. It adds valuable context about the data scope (~160 stations across Switzerland) but does not explicitly confirm read-only safety, rate limits, or return structure that annotations would typically cover.

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 zero waste. It front-loads the core action ('List and search') and follows with filtering options and network scope. Every clause 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 listing tool with 3 optional parameters and 100% schema coverage, the description is adequate. It explains the conceptual return (stations) and data volume. It could be improved by noting that results typically feed into sibling weather tools, but this is not strictly necessary for basic completeness.

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

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

Schema description coverage is 100%, so the schema fully documents all three parameters (limit, canton, search). The description mentions filtering by name and canton, which aligns with the schema, but adds no additional semantic context beyond what the schema already provides. Baseline 3 is appropriate given complete 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 clearly states the tool 'List and search MeteoSwiss automatic weather stations,' providing a specific verb and resource. It distinguishes itself from siblings like meteoswissCurrentWeather and meteoswissLocalForecast by focusing on station metadata rather than weather data.

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

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

The description explains filtering capabilities (by name, canton) and mentions browsing the full network, implying exploratory usage. However, it lacks explicit guidance on when to use this versus the generic 'search' tool or prerequisites for using weather-related siblings.

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

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

No annotations provided, so description carries full burden. It adds valuable behavioral context about pagination returning duplicate results (upstream API limitation) and clarifies the return format (pages with URLs). Missing: error handling, rate limits, or authentication 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?

Three sentences, zero waste. Front-loaded with specific purpose (Search MeteoSwiss...), followed by output description and pagination warning. Every sentence provides unique value not duplicated in structured 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?

Adequate for a 6-parameter search tool with no output schema. Description compensates by stating what gets returned (pages with URLs) and warns about pagination quirks. Would benefit from mention of error states or empty result handling, but sufficient given rich schema coverage.

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

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

Schema description coverage is 100%, so the schema comprehensively documents all 6 parameters including detailed warnings (e.g., date-asc degrades relevance). Description mentions multi-language capability but doesn't add significant parameter-specific semantics beyond what the schema provides. Baseline 3 appropriate when schema does heavy lifting.

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

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

Description clearly states the tool searches MeteoSwiss website content, specifies the multi-language capability (DE, FR, IT, EN), and distinguishes itself from sibling weather data tools (meteoswissCurrentWeather, etc.) by focusing on website content retrieval.

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 mentions that returned URLs 'can be passed to the fetch tool', establishing the intended workflow with sibling tool 'fetch'. However, it doesn't explicitly state when to use search versus directly using fetch if a URL is already known.

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