swiss-environment-mcp

Server Quality Checklist

Profile completionA complete profile improves this server's visibility in search results.

Latest release: v0.6.0
Disambiguation5/5
Each tool targets a specific resource and action (e.g., bathing water quality, hydrological stations, flood warnings, hunting statistics) with minimal overlap. Even paired tools like env_hazard_overview and env_hazard_regions serve distinct roles - one provides a general hazard routing, the other a region-specific orientation.
Naming Consistency4/5
All tools follow the env_<domain>_<specifier> pattern in snake_case, but the specifier varies between nouns (stations, overview) and verb phrases (limits_check). The outlier env_noise_aircraft_at uses a preposition, and some use 'current' as an adjective. Overall consistent and predictable, but not perfectly uniform.
Tool Count5/5
With 21 tools, the server covers multiple environmental subdomains (water, air, noise, snow, hunting, hazards) without being overwhelming. Each subdomain has a focused set of 2-4 tools, and there are no redundant or unnecessary tools.
Completeness4/5
The tool surface covers CRUD-like operations for most domains: list, get current, and check limits. Notable gaps include lack of direct historical hydrology time series (only current value) and no tools for road/railway noise. However, the server acknowledges these limitations in descriptions and provides alternative access paths.
Average 4.4/5 across 21 of 21 tools scored. Lowest: 3.9/5.
See the Tool Scores section below for per-tool breakdowns.
- 2 of 2 community issues answered or closed in the last 6 months
- 101 commits in the last 12 weeks
- Last stable release on August 3, 2026
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI is passing
This repository is licensed under MIT License.
This repository includes a README.md file.
No tool usage detected in the last 30 days. Usage tracking helps demonstrate server value.
Tip: use the "Try in Browser" feature on the server page to seed initial usage.
Add a glama.json file to provide metadata about your server.
If you are the author, simply .
If the server belongs to an organization, first add glama.json to the root of your repository:
```
{
  "$schema": "https://glama.ai/mcp/schemas/server.json",
  "maintainers": [
    "your-github-username"
  ]
}
```
Then . Browse examples.
Add related servers to improve discoverability.

How to sync the server with GitHub?

Servers are automatically synced at least once per day, but you can also sync manually at any time to instantly update the server profile.

To manually sync the server, click the "Sync Server" button in the MCP server admin interface.

How is the quality score calculated?

The overall quality score combines two components: Tool Definition Quality (70%) and Server Coherence (30%).

Tool Definition Quality measures how well each tool describes itself to AI agents. Every tool is scored 1–5 across six dimensions: Purpose Clarity (25%), Usage Guidelines (20%), Behavioral Transparency (20%), Parameter Semantics (15%), Conciseness & Structure (10%), and Contextual Completeness (10%). The server-level definition quality score is calculated as 60% mean TDQS + 40% minimum TDQS, so a single poorly described tool pulls the score down.

Server Coherence evaluates how well the tools work together as a set, scoring four dimensions equally: Disambiguation (can agents tell tools apart?), Naming Consistency, Tool Count Appropriateness, and Completeness (are there gaps in the tool surface?).

Tiers are derived from the overall score: A (≥3.5), B (≥3.0), C (≥2.0), D (≥1.0), F (<1.0). B and above is considered passing.

Tool Scores

Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations declare readOnlyHint=true and destructiveHint=false, which aligns with the tool's read-only nature. The description adds transparency by disclosing that the underlying endpoint is undocumented and that a schema guard handles structural changes, plus specifying the data owner (BAFU). This goes beyond annotations without contradiction.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with separate paragraphs and XML tags for use_case and important_notes. It is front-loaded with the main purpose and then provides additional context. It is not overly verbose for the complexity of the tool, earning a 4.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given that the tool has no output schema, the description explains the return value as yearly values (total and classes) or an actionable hint. It covers parameters well via schema, and adds usage context. However, it lacks detail on the exact structure of markdown vs JSON response. Still, for a tool with 4 parameters and a string output, this is fairly complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Although the input schema covers all four parameters with detailed descriptions, the description adds some extra context (e.g., species via name or code, values per age/sex class, total is sum, hunting year definition). Since schema coverage is high, the baseline is 3, and the added value is marginal but present.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states that the tool retrieves time series of Federal Hunting Statistics (kill, population, release, or accidental game numbers) per species and canton for 2015-2024. It specifies the data types and time range. While it distinguishes from sibling env_hunting_species implicitly, it doesn't explicitly differentiate from other sibling tools, so a 4 is appropriate.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides a use_case tag explaining when to use the tool (e.g., tracking development of kill or accidental numbers over time) and important_notes with details on species coding and hunting year definition. It lacks explicit exclusions or alternatives, but the context is clear enough for correct usage.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and destructiveHint=false. The description adds behavioral context beyond annotations: the response is always nationwide, a set canton filter is reported as not applied, and 'Keine Warnung' is an explicit all-clear rather than an error. No contradiction with annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is structured with use_case, important_notes, Args, and Returns sections. It is front-loaded with the purpose and avoids excessive prose, though the level enumeration and Args section partially duplicate the input schema.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a read-only query tool, the description covers the key context: nationwide scope, danger levels, canton no-op behavior, and the meaning of no warning. With an output schema present, not detailing return structure is acceptable. The only gap is the undocumented response_format option.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description explains min_level and canton semantics, including the default for min_level, but omits response_format entirely even though it is part of the input schema. Schema description coverage is 0% at the top level, so the description partially compensates but misses one parameter.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
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: 'Ruft aktuelle Hochwasserwarnungen aller BAFU-Messstationen in der Schweiz ab' (retrieves current flood warnings from all BAFU stations in Switzerland). This clearly distinguishes it from sibling environment tools like avalanche or wildfire warnings.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The <use_case> tag states when to use: 'Aktive Hochwasserwarnungen schweizweit für eine Lagebeurteilung' (active flood warnings nationwide for situation assessment). It also clarifies that canton is not applied and that 'Keine Warnung' is an explicit all-clear, but it does not name alternative tools or exclusion cases.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description discloses that the calculation is purely local ('Rein lokale Berechnung, kein Netzwerk'), which aligns with the readOnlyHint and idempotentHint. It also notes the refusal for military periods and the footnote-driven deviation for ES II first night hour, adding behavioral context beyond what annotations provide. No contradictions with annotations exist.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with a clear opening sentence, legal basis, use case, and important notes sections. While it is relatively long, each part adds necessary context for a domain-specific legal comparison tool. The structure aids quick scanning and comprehension, though some redundancy exists between the description and schema.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (nested input, four parameters, output schema), the description covers purpose, legal framework, usage context, key exceptions, and return format. It references the expected input source (sibling tool) and addresses edge cases. The presence of an output schema reduces the need to detail return structure in the description, so completeness is satisfactory.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema already provides detailed descriptions for all parameters, including enum values for period and explanations for sensitivity_level. The description adds marginal value by linking level_db to the sibling tool env_noise_aircraft_at and reiterating legal context, but the schema coverage is high enough that the description does not significantly shift understanding of parameter semantics.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Vergleicht einen Fluglärm-Beurteilungspegel gegen die LSV-Belastungsgrenzwerte' (compares a flight noise assessment level against LSV limit values), specifying a concrete verb and resource. It also cites the exact legal basis (LSV, Anhang 5) and differentiates the tool from siblings like env_noise_aircraft_at by focusing on legal classification rather than noise level retrieval.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The use case section explicitly tells when to use this tool: 'Einen dB-Wert aus env_noise_aircraft_at (oder aus einem Gutachten) rechtlich einordnen'. The important notes explain that the tool deliberately refuses the 'military' period because Annex 5 only applies to civil airports, providing a clear exclusion criterion. It also highlights the special case for ES II in the first night hour, guiding correct parameter choice.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description adds behavior beyond annotations by stating 'Rein lokale Berechnung (kein Netzwerk)', confirming the computation is local and idempotent. Annotations already indicate read-only and idempotent, so the description reinforces and adds the local aspect.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with <use_case> and <important_notes> tags, making it scannable. The main purpose is front-loaded in the first sentence. However, the 'Args' and 'Returns' sections duplicate some schema information, adding slight redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the simple tool (one object parameter with three fields), the description covers all necessary aspects: purpose, supported pollutants, averaging periods, return type, and the local computation nature. An output schema exists, so the description does not need to detail return structure.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema already describes all three parameters (value, pollutant, averaging_period) with German text, so schema description coverage is high. The tool description lists supported pollutants and averaging periods but does not add new semantic details beyond what the schema provides.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool evaluates a measured air pollutant against Swiss LRV and WHO 2021 limits, using specific verbs like 'Bewertet'. It distinguishes itself from sibling tools like env_noise_limits_check by focusing on air pollutants and regulatory standards.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The <use_case> tag explicitly defines when to use the tool: to classify a measured pollutant value against Swiss and WHO limits. It provides context but does not mention when not to use it or alternatives, which keeps it from a perfect score.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint and idempotentHint, so the description adds value by stating the data is static (no network), embedded, and contains exactly 36 species across categories. This context complements the annotations without contradiction.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is structured with clear paragraphs and XML tags for use case and important notes. It is informative without being overly verbose, though it could be slightly more streamlined.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity, the description covers all necessary aspects: purpose, how it works (static embedded), output format (list with codes and names), and usage context (reference for env_hunting_stats). It is fully sufficient for an agent to invoke correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, but the description does mention the only parameter (response_format) and its possible values ('markdown' oder 'json'). However, it does not explain the difference between formats or how they affect output, leaving the agent to infer from the enum. This is adequate for a simple parameter but not exemplary.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states that the tool lists animal species with their codes from the Swiss hunting statistics, and explicitly links it to the sibling tool env_hunting_stats for reference. The verb 'listet auf' and resource 'Tierarten mit Codes' are specific and distinguish it from other environmental tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description includes a use case tag explicitly recommending use before querying env_hunting_stats to obtain valid species codes. It implies a lookup-only purpose but does not explicitly state when not to use or mention alternatives, which prevents a 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate read-only, idempotent, non-destructive. Description adds that the data is static (not a live call) and lists the measured parameters, enhancing behavioral understanding.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Well-structured with use case and important notes sections, but slightly wordy. Clear and informative without being overly terse.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Provides complete context: number of stations, what is measured, output structure, and how to proceed. Output schema exists, so return details are covered.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema's parameter description already covers 'markdown' or 'json' output. The tool description does not add new semantics beyond that, resulting in a baseline score of 3.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool lists all 16 NABEL stations, uses the verb 'auflisten', and distinguishes itself from siblings by mentioning a follow-up use case with env_nabel_current.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Includes a <use_case> tag explaining it's the entry point for air quality data, and notes the stations are static. Does not explicitly state when not to use, but provides good context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, idempotentHint=true, destructiveHint=false. The description adds that results are lists with title/description/URLs, pagination via offset/rows, and zero-result handling (match_type 'none'). This supplements the safety profile without contradictions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with a clear first line, details, and sections for use_case and important_notes. It is concise enough while providing necessary context, though the <use_case> and <important_notes> could be integrated more succinctly.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's search function and existing annotations (read-only, idempotent), the description adequately covers purpose, parameters, pagination, and error handling. The return type is mentioned ('Liste...'), and output schema exists (though not shown). Missing details like sorting are acceptable for this complexity level.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema provides thorough descriptions for rows, query, and offset (e.g., range, default, example query). The description adds operational semantics beyond the schema: pagination guidance and advice to try broader terms on zero results. This enhances parameter understanding.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool searches BAFU datasets on opendata.swiss, specifies topics (Luft, Wasser, etc.), and mentions results contain titles, descriptions, and download URLs. It also distinguishes from sibling tool env_bafu_dataset_detail via the <use_case> tag, making the purpose specific and differentiated.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The <use_case> provides clear context for when to use this tool (initial search) and directs to env_bafu_dataset_detail for details. The <important_notes> offers guidance on pagination and handling zero results (try broader terms). However, it does not explicitly state when not to use this tool or alternative tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate readOnlyHint=true and openWorldHint=true. The description adds behavioral context: data is modeled from SLF model, values are in cm, and zero outside snow season is not an error. No contradictions with annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with sections using HTML-like tags, bullet arguments, and a clear return description. It is concise yet complete, with no unnecessary words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple data retrieval tool, the description covers purpose, usage guidance, behavioral notes, parameter list, and return format. Combined with annotations and an output schema, it provides sufficient context for the agent to use the tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Despite schema_description_coverage being 0% (as per context), the description lists parameters (canton, station, limit, response_format) with brief explanations. However, it mostly repeats what is in the schema. It adds units clarification but no additional constraints or examples beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool retrieves current snow height and new snow 24h from SLF-IMIS stations, with specific units and model source. It also notes that zero values are normal outside snow season. However, it does not explicitly differentiate from sibling tools like env_snow_stations, though the purpose is clear enough.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit use cases (current snow situation for planning), an alternative tool for precipitation (meteoswiss-mcp), and mentions the data license. This guides the agent on when and when not to use this tool, and where to go for related data.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations indicate readOnly, idempotent, non-destructive. Description adds context: deterministic, network-free, and explains the background of API shutdown. No contradiction, but could mention side effects more explicitly.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Description is front-loaded with purpose, includes background and notes. Slightly long but well-organized with tags. Minor redundancy in background section.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For an overview/routing tool, the description fully covers what it returns (mapping of hazards to tools and platform links). Output schema exists, so return values are documented externally. Complete guidance for selection and usage.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description for language is minimal but present. Description adds context that language is 'für die Portallinks'. Schema coverage is 0% per context, so description helps marginally; baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool provides an overview of Swiss natural hazards, mapping each hazard to a specific tool or official warning platform. It distinguishes from siblings by listing concrete tools like env_flood_warnings.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicit usage guidance: use as entry point, for live data use linked tools. Includes when-not-to-use (aggregated weather warnings are for meteoswiss-mcp) and provides context with <use_case> and <important_notes>.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already provide readOnlyHint=true, destructiveHint=false, idempotentHint=true. The description adds that it returns the current value and a reference path for historical series, and explains limitations about daily averages. This complements the annotations without contradiction.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is somewhat verbose, with an args list that largely duplicates schema information. It has good structure with sections, but could be more concise by removing redundant parameter details.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a read-only tool with simple output, the description covers the core behavior, limitations (no daily averages), data source (LINDAS), and a reference path. It lacks examples or error info, but is otherwise complete given annotations and simple output.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0% for the top-level parameter, but the description lists station_id, parameter, and days with brief context (e.g., 'Kontext'). It adds value by clarifying the use context, though it mostly repeats schema descriptions. The important notes also add parameter-related guidance.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it retrieves historical hourly values for a BAFU hydrometric station, specifying water level, flow, and temperature over up to 30 days. It distinguishes from siblings like env_hydro_current (current values) and env_hydro_stations (station list) by focusing on historical time series.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The <use_case> and <important_notes> explicitly guide when to use: for fetching the current value and pointing to historical daily/long-term series, and notes that daily averages are not available via API, requiring contacting BAFU. This provides clear when-to-use and when-not-to-use context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already provide readOnlyHint=true, idempotentHint=true, destructiveHint=false, so the description's job is to add context beyond that. The description adds the data source (SLF CC BY 4.0) and the explanation of station types, but does not disclose much else about behavior (e.g., rate limits, authentication, or edge cases). With annotations covering the safety profile, a 3 is appropriate – the description adds some value but not rich behavioral context.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with paragraphs, use_case, and important_notes tags, and is front-loaded with the purpose. However, it is somewhat lengthy; each sentence earns its place but could be slightly more concise. Still, the structure aids readability.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given that an output schema exists (context confirms), the description does not need to detail return values, but it still mentions the return fields (Code, Name, Kanton, Höhe, Typ). It covers the use case, important notes about data source and station types, and provides clear entry-point guidance. For a list tool with good annotations, this is complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description explicitly lists both parameters (canton and response_format) with brief explanations, adding meaning beyond what the input schema provides. The schema already has a description for canton, but the response_format parameter is an enum and the description clarifies the options. Since the schema description coverage is low (0% per context, though the schema itself has descriptions), the description compensates well.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it lists automatic IMIS snow measurement stations of SLF, and specifies what parameters they measure (snow height, new snow, wind, temperature). This distinguishes it from sibling tools like env_snow_current which retrieves actual snow data.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The use_case tag explicitly says it's an entry point to snow data, to be followed by env_snow_current. The important_notes tag explains the data source (SLF, CC BY 4.0), clarifies that type=SNOW_FLAT are flat-field stations, and importantly tells users that this is NOT a precipitation tool, directing them to meteoswiss-mcp instead. This is excellent guidance for when to use or not use this tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already provide readOnlyHint, idempotentHint, destructiveHint false. Description adds specific behavioral context: returns complete metadata including download URLs, which complements annotations. No contradictions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Description is compact with clear sections: purpose, what it returns, use case, important notes, and args. Every sentence adds value. No fluff.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a detail retrieval tool, the description fully covers what the agent needs: metadata contents, pre-requisite, and return format. Output schema exists to supplement return values.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Only one parameter (dataset_id). Schema description provides pattern, length, and example. Description repeats parameter definition but adds minimal new meaning. Schema coverage is good, so description is adequate but not additive.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states it retrieves full metadata and download URLs for a specific BAFU dataset. It lists returned items (title, description, resources, links, license, etc.) and distinguishes from sibling tool env_bafu_datasets which lists datasets.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicit use case tag specifies when to use (full metadata for a concrete dataset) and important notes instruct to first get dataset_id via env_bafu_datasets. No ambiguity on when to use this vs alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description adds significant behavioral context beyond annotations: explains data source, temporal scope (annual updates, no real-time), and the difference between overview and detail modes based on location parameter. No contradiction with readOnlyHint, openWorldHint, etc.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with clear sections, including a use case and important notes. Every sentence adds value, no redundancy. It is concise yet informative.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a read-only data retrieval tool with good annotations and schema, the description covers all essential aspects: data source, temporal update frequency, parameter behavior, and return format. It is complete and self-sufficient.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema already provides descriptions for all parameters (limit, canton, location, response_format). The description adds behavioral nuance about location parameter (overview vs detail) but does not significantly extend schema meaning. Baseline 3 is appropriate given high schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool retrieves bathing water quality data from BAFU survey, specifying data type (E.coli/Enterokokken), geographic scope (Swiss lakes and rivers), and temporal scope (multi-year since 2020). This distinguishes it from sibling tools focused on hydrology, air quality, etc.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description includes explicit use cases ('prüfen ob man baden kann' and listing stations by canton) and important notes about behavior with/without location parameter. However, it does not explicitly state when not to use this tool or mention alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false. The description adds behavioral context: results are based on isolines (not interpolation), output is a bracket with upper bound, and the result is an orientation basis, not a building permit. No contradiction with annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with clear sections (purpose, use case, important notes). It is slightly verbose but each sentence adds value. The important notes are appropriately emphasized with <important_notes> tags.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (coordinate system, isolines, multiple periods), the description is thorough. It covers input requirements, output structure (dB value, bracket, provenance, PDF link), and limitations. The use case is concrete. No obvious gaps remain.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Despite schema descriptions for parameters, the tool description adds significant value: it warns about coordinate system confusion (LV95 vs WGS84), gives concrete examples (Zürich HB), explains each period value in detail, and warns that a large radius_m overestimates noise. These details are not in the schema alone.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool evaluates aircraft noise at a point using official BAZL noise cadastre data. It specifies the exact question answered ('Liegt dieser Standort in einer Fluglärmzone — und in welcher dB-Stufe?') and distinguishes itself from sibling tools like env_noise_aircraft_registers or env_noise_limits_check by focusing on point-based noise level lookup.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit usage context: site assessment for construction projects. Important notes clarify coordinate system requirements (LV95, not WGS84), the nature of results (isolines producing a dB bracket), and that output is for orientation only. While it doesn't explicitly list when not to use, the constraints are clearly stated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description adds substantial behavioral context beyond the readOnlyHint: data source is LINDAS, values update every 10 minutes, and unknown station IDs are explicitly reported with no fallback. It also details the return content (Pegel, Abfluss, Wassertemperatur, 24h min/max) and the timestamp. This goes well beyond annotations, covering potential edge cases and data freshness.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with clear sections (intro, return values, station list, use case, important notes, Args, Returns) and is front-loaded with the core action. It is slightly redundant (10-minute update appears twice) and the station list is somewhat niche, but every section contributes to usability. Not overly verbose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple read-only tool, the description is complete: it explains what data is returned, how to get station IDs, the update frequency, and error behavior for unknown IDs. Given the output schema exists (though not shown), the brief 'Returns' line suffices. It covers usage, parameters, and edge cases effectively.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Despite the schema description coverage being 0% according to context, the description's 'Args' section explains both parameters: station_id as 'BAFU-Stationsnummer' with examples, and response_format as 'markdown' or 'json'. It also provides a list of known Zürich station IDs, which adds real-world context. However, it could explain the effect of response_format on the output structure in more depth.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's function: 'Ruft aktuelle Messwerte einer hydrologischen BAFU-Messstation ab' (retrieves current measurements). It specifies the resource (hydrological BAFU measuring station) and the scope (current values, with units listed). It distinguishes itself from siblings like env_hydro_history by focusing on current data and includes known station IDs.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides specific usage context via the '<use_case>' tag (e.g., flood situation check) and important notes (station ID via env_hydro_stations). It implicitly differentiates from historical data by stating 'aktuelle Messwerte', but it does not explicitly name alternatives like env_hydro_history. This is clear guidance, but lacks an explicit 'when not to use'.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Adds rich behavioral context: ~260 stations, measurement interval, fallback to example stations on LINDAS failure (recognizable via provenance), and match_type 'none' for empty results. These details go well beyond the readOnlyHint annotation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Structured with a clear summary, use_case, and important_notes. Front-loaded and efficient; the length is justified by the need to explain the unsupported canton and fallback behavior.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Covers listing, filtering, unsupported parameters, fallback behavior, and return format. With an output schema available, the description is complete for effective use.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description includes an Args section listing all parameters and notes canton is currently unavailable, water_body is the supported filter, and response_format accepts markdown or json. Given schema description coverage is 0%, this compensates well, though it could elaborate on response_format behavior.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states it lists BAFU hydrological stations at Swiss rivers and lakes, and distinguishes it from env_hydro_current by positioning it as the station-finding step before retrieving current values.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides an explicit use case ('Hydromessstationen finden... um danach mit env_hydro_current Pegel/Abfluss abzurufen') and clearly states the canton filter is not supported, recommending water_body instead. It does not explicitly compare to other siblings like env_hydro_history, but the context is clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description goes well beyond the annotations (readOnlyHint, openWorldHint) by detailing the data access mechanism (two-step HTML-backed contract), daily updates, language support, the 5-level scale, and the filtering behavior. This provides rich, non-contradictory behavioral context.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is moderately sized with clear tags (<use_case>, <important_notes>) and a direct first sentence. It is structured but could be slightly more concise without losing essential information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's moderate complexity (one nested input parameter, output as string, and data source details), the description provides sufficient context for an agent to use it correctly. The presence of an output schema (implied) and the detailed notes make it complete within its domain.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Although the schema descriptions already cover the parameters (canton and language), the tool description adds value by explaining the default behavior when no canton is given (highest levels first, limit 40) and the broader context of the five-step scale. This compensates for the 0% schema description coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool retrieves the current forest fire danger index by region, computed daily by BAFU on a 5-level scale, and specifies its relevance for school trips, events, and forestry operations. This is a specific verb+resource with sufficient detail to distinguish it from sibling environmental tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit use cases (forest operations, event planning) and contextual notes (daily updates, canton filtering, default behavior when no filter is applied). However, it does not explicitly state when not to use the tool or suggest alternatives, falling short of a perfect score.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description adds behavioral traits beyond annotations: it confirms the tool is network-free and deterministic, notes that the aggregated API is shut down, and explains that live data comes from linked tools. This aligns with readOnlyHint and idempotentHint, and provides additional context.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with separate paragraphs, use_case and important_notes tags, and an Args section. However, it is somewhat verbose; a more concise version could convey the same information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's moderate complexity, the description covers all relevant aspects: purpose, usage context, behavioral notes, parameter details, and return value. The output schema exists, so the brief mention of return value is sufficient. Annotations and output schema together make this complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description includes an 'Args' section that explains each parameter with examples (e.g., region name, hazard type options). Since schema description coverage is 0% (according to context signals), the description compensates by adding meaning beyond the bare schema definitions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: providing region-based orientation to natural hazards, pointing users to dedicated live tools and official hazard maps. It uses specific verbs ('verweist') and distinguishes itself from siblings by referencing 'env_wildfire_danger' for wildfire danger.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly states when to use the tool (region-based planning for events, school trips, infrastructure) and what not to use it for (live values, which are handled by linked tools like 'env_wildfire_danger'). It also explains that the tool is network-free and deterministic, providing clear guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Description adds significant behavioral context beyond annotations: queries eight sublayers without period, validity dates vary widely (2009-2024), data is a snapshot not real-time. Annotations already declare readOnly, idempotent, non-destructive, so the description enriches understanding without contradiction.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Description is well-structured with sections (overview, use case, important notes, args, returns). Every sentence adds value, and it is front-loaded with the core purpose. No redundant or vague sentences.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (multiple sublayers, filtering options, data staleness) and the presence of annotations and output schema, the description is complete. It covers purpose, parameters, behavior, return format, and usage context. All necessary information is present.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Description explicitly lists both parameters (period and response_format) and adds meaning beyond schema: period optional with eight sublayers explained, without period triggers eight requests. Even though schema coverage is low, the description compensates fully, providing clear semantics for each parameter.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states the tool provides an overview of published aircraft noise pollution registers with validity dates, number of curves, dB range, and links. The use case and 'Provenienz-Tool' label further clarify its purpose, distinguishing it from sibling tools like env_noise_aircraft_at by focusing on register metadata rather than real-time noise data.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides a clear use case ('before a site assessment, check if a register exists and how current it is') and important notes (e.g., without period multiple requests, data is not real-time). However, it does not explicitly contrast with sibling tools or specify when not to use it, missing some exclusion criteria.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Describes behavior beyond annotations: seasonality, explicit 'no active bulletin' message, data source SLF with CC BY 4.0, and EAWS scale. Annotations already indicate read-only and non-destructive, and description aligns.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Well-structured with main description, use_case, important_notes, and Args. Every sentence is informative; no fluff. Front-loaded with core purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's low complexity (1 param, output schema exists), the description covers all key aspects: purpose, usage, behavior, parameter info, and references to license. It is complete enough for correct invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0% per context, but the description provides an Args section explaining both parameters: language options and region as substring filter. This adds value, though it does not elaborate further beyond the schema's own descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it retrieves the current avalanche bulletin from SLF with warning levels per region. It specifies the EAWS scale 1-5 and distinguishes from sibling tool env_snow_current for snow depths.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly says when to use: for tour planning/safety assessment. Notes that outside winter season the tool returns 'no active bulletin' (not an error). Recommends env_snow_current for snow height data.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond annotations (readOnlyHint, etc.), description adds critical behavior: it returns metadata and download links, not real-time raw values, and specifies output contents (station info, parameters, data links, limit context). No contradiction with annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Concise yet comprehensive: one sentence summary, then structured details, use case, and important notes. Every sentence adds value, no redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given low parameter count and existence of output schema, description sufficiently covers return type (station info, parameters, data links, limit context) and the tool's scope. No omissions noted.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The single parameter (station) is explained with examples in both the description and schema description. Important notes add context on how to obtain station codes, significantly aiding parameter understanding.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states it retrieves current and historical air quality data for a specific NABEL station, listing measured parameters. It distinguishes from sibling tools like env_nabel_stations and env_air_limits_check by focusing on data access for a single station.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicit use case (current air quality / data access) and important notes (returns metadata and data links, not real-time raw values; station codes from env_nabel_stations) provide clear when-to-use and how-to-prequisites, with alternative tool mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

GitHub Badge

Glama performs regular codebase and documentation scans to:

Confirm that the MCP server is working as expected.
Confirm that there are no obvious security issues.
Evaluate tool definition quality.

Our badge communicates server capabilities, safety, and installation instructions.

Card Badge

Copy to your README.md:

[![swiss-environment-mcp MCP server](https://glama.ai/mcp/servers/malkreide/swiss-environment-mcp/badges/card.svg)](https://glama.ai/mcp/servers/malkreide/swiss-environment-mcp)

Score Badge

Copy to your README.md:

[![swiss-environment-mcp MCP server](https://glama.ai/mcp/servers/malkreide/swiss-environment-mcp/badges/score.svg)](https://glama.ai/mcp/servers/malkreide/swiss-environment-mcp)

Latest Blog Posts

Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)
By Om-Shree-0709 on July 25, 2026.
mcp
Agent Identity
OAuth 2.1
Your AI Chatbot Just Exposed Your CEO's Salary to an Intern
By Om-Shree-0709 on July 2, 2026.
Agent Identity
MCP Security
OAuth Delegation
Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)
By Om-Shree-0709 on June 30, 2026.
Agentic Ai
Prompt Injection
WebAssembly

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/malkreide/swiss-environment-mcp'

If you have feedback or need assistance with the MCP directory API, please join our Discord server