How do I use Aare.guru MCP Server?

1. Click on "Install Server". 2. Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state. 3. In the chat, type @ followed by the MCP server name and your instructions, e.g., "@Aare.guru MCP Server what's the water temperature in Bern right now?" That's it! The server will respond to your query, and you can continue using it as needed. Here is a step-by-step guide with screenshots.

Aare.guru MCP Server

by baking-bread

Overview Schema Related Servers Score Discussions

JavaScript

Remote

Aare.guru MCP Server

A Model Context Protocol (MCP) server that provides access to the Aare.guru API for getting water temperature and swimming conditions of the Aare river in Switzerland.

Features

This MCP server provides the following tools:

get_cities: Get list of all available monitoring locations
get_current_conditions: Get comprehensive current data (temperature, flow, forecasts) for a specific location
get_today_summary: Get minimal current temperature and swimming recommendation
get_widget_data: Get current data for all locations at once
get_historical_data: Get historical time series data for temperature, flow, and air temperature

Related MCP server: Environment Agency Flood Monitoring MCP Server

Requirements

Node.js 18 or newer

Installation

Using npx (Recommended)

npx aareguru-mcp

Global Installation

npm install -g aareguru-mcp
aareguru-mcp

Local Development

git clone <repository-url>
cd aareguru-mcp
npm install
npm start

Usage with Claude Desktop

Add the following to your Claude Desktop MCP configuration:

{
  "mcpServers": {
    "aareguru": {
      "command": "npx",
      "args": ["aareguru-mcp"]
    }
  }
}

Or if installed globally:

{
  "mcpServers": {
    "aareguru": {
      "command": "aareguru-mcp"
    }
  }
}

Available Tools

get_cities

Get a list of all available monitoring locations along the Aare river.

Parameters: None required

app (optional): App identifier
version (optional): Version number
values (optional): Specific values to extract

get_current_conditions

Get comprehensive current conditions for a specific location.

Parameters:

city (optional, default: "bern"): Location identifier (e.g., "bern", "thun")
app (optional): App identifier
version (optional): Version number
values (optional): Specific values to extract

get_today_summary

Get a minimal summary with current temperature and swimming recommendation.

Parameters:

city (optional, default: "bern"): Location identifier
app (optional): App identifier
version (optional): Version number
values (optional): Specific values to extract

Get current data for all locations simultaneously.

Parameters:

app (optional): App identifier
version (optional): Version number
values (optional): Specific values to extract

get_historical_data

Get historical time series data for water temperature, flow, and air temperature.

Parameters: (all required)

city: Location identifier
start: Start date/time (ISO format, timestamp, "yesterday", "-1 day", etc.)
end: End date/time (ISO format, timestamp, "now", etc.)
app (optional): App identifier
version (optional): Version number
values (optional): Specific values to extract

Example Queries

Once connected to Claude Desktop, you can ask questions like:

"What's the current water temperature in Bern?"
"Show me all available Aare monitoring locations"
"Get the historical data for Thun from last week"
"What are the current swimming conditions across all locations?"

API Data

This server connects to the Aare.guru API (https://aare.guru), which provides:

Current water temperature
Water flow/discharge rates
Air temperature
Swimming recommendations and "Sprüche" (sayings)
Weather forecasts
Historical data
Multiple monitoring locations along the Aare river

License

GNU General Public License v3.0

Credits

Data provided by Aare.guru and the BAFU. The API is intended for non-commercial public use only.

This MCP server is not officially affiliated with Aare.guru but uses their public API in accordance with its terms of service.

Available Tools

5 tools

get_citiesB

Get list of all available cities/locations with Aare data

ParametersJSON Schema

Name	Required	Description	Default
`app`	No	Optional app identifier	aareguru-mcp-server
`values`	No	Optional comma-separated list of specific values to extract
`version`	No	Optional version number	1.0.0

TDQS

B3.3/5.0

Behavior2/5

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

With no annotations provided, the description carries full burden. It only says 'Get list' without disclosing any behavioral traits such as data freshness, rate limits, authentication needs, or side effects. The tool could be read-only, but this is not explicitly stated.

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 a single, efficient sentence with no wasted words. It is appropriately sized for a simple list tool.

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

Completeness3/5

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

Given the simplicity of the tool (no output schema, no nested objects), the description is adequate but lacks details on return format, sorting, or pagination. It is minimally 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?

Schema coverage is 100% with descriptions for all three parameters. However, the description adds no additional meaning beyond the schema. The parameter 'values' is ambiguous ('extract' could be clarified), but the schema already describes it.

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 returns a list of all available cities/locations with Aare data. This is a specific verb+resource and distinguishes from sibling tools like get_current_conditions or get_historical_data.

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

Usage Guidelines2/5

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

No guidance on when to use this tool versus alternatives. The description does not mention any prerequisites, exclusions, or context for usage.

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

get_current_conditionsA

Get comprehensive current Aare data for a specific location including temperature, flow, forecasts

ParametersJSON Schema

Name	Required	Description	Default
`app`	No	Optional app identifier	aareguru-mcp-server
`city`	No	City identifier (e.g., 'bern', 'thun')	bern
`values`	No	Optional comma-separated list of specific values to extract
`version`	No	Optional version number	1.0.0

TDQS

A3.7/5.0

Behavior3/5

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

No annotations are provided, so the description must fully disclose behavior. It describes the data returned (temperature, flow, forecasts) but lacks details on authentication, rate limits, or side effects. The 'comprehensive' claim is vague without further elaboration.

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 a single concise sentence that front-loads the key purpose. No redundant information. Every word earns its place.

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

Completeness3/5

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

With 4 optional parameters and no output schema, the description should provide more context about the return structure or usage. It mentions data types (temperature, flow, forecasts) but does not specify format or example. Sufficient for a simple tool but could be improved.

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 coverage is 100%, so each parameter is documented in the schema. The description adds no extra meaning beyond the schema. 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 verb 'Get', the resource 'comprehensive current Aare data', and the scope 'for a specific location including temperature, flow, forecasts'. It effectively distinguishes from sibling tools like get_historical_data and get_today_summary by focusing on current conditions.

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

Usage Guidelines3/5

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

The description implies usage for obtaining current river conditions but does not explicitly state when to use this tool versus alternatives like get_historical_data or get_today_summary. No guidance on prerequisites or exclusions.

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

get_historical_dataB

Get historical time series data for water temperature, flow, and air temperature

ParametersJSON Schema

Name	Required	Description	Default
`app`	No	Optional app identifier	aareguru-mcp-server
`end`	Yes	End date/time in various formats (ISO, timestamp, 'now')
`city`	Yes	City identifier (required for historical data)
`start`	Yes	Start date/time in various formats (ISO, timestamp, 'yesterday', '-1 day')
`values`	No	Optional comma-separated list of specific values to extract
`version`	No	Optional version number	1.0.0

TDQS

B3.3/5.0

Behavior2/5

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

No annotations are provided, and the description only states the data types but does not disclose behavioral traits such as data freshness, rate limits, or error handling.

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 a single concise sentence, but it could be slightly more informative without increasing length.

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

Completeness2/5

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

The given complexity (6 parameters, no output schema) is not addressed; the description fails to explain what the returned time series data looks like, leaving the agent uninformed about the 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?

Schema description coverage is 100%, so the schema already documents each parameter. The description adds little beyond naming the data types, which may relate to the 'values' parameter but is not explicit.

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 identifies the tool as retrieving historical time series data for specific environmental metrics (water temperature, flow, air temperature), distinguishing it from sibling tools like get_current_conditions.

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

Usage Guidelines3/5

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

The description implies historical data retrieval but does not explicitly state when to use this tool over alternatives, nor does it provide exclusions or prerequisites.

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

get_today_summaryB

Get minimal current Aare temperature and swimming recommendation for a location

ParametersJSON Schema

Name	Required	Description	Default
`app`	No	Optional app identifier	aareguru-mcp-server
`city`	No	City identifier (e.g., 'bern', 'thun')	bern
`values`	No	Optional comma-separated list of specific values to extract
`version`	No	Optional version number	1.0.0

TDQS

B3.2/5.0

Behavior2/5

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

With no annotations, the description must disclose behavioral traits. It only states the output is minimal data without addressing potential errors, data freshness, or side effects. The tool's read-only nature is implied but not explicit.

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 a single, well-structured sentence that front-loads the purpose. Every word contributes value without redundancy.

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

Completeness2/5

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

Despite low complexity, the description fails to differentiate from the sibling get_current_conditions and does not describe return format or output structure. An output schema would help, but none is provided, leaving the agent guessing about the response.

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?

All parameters have descriptions in the schema (100% coverage), so the tool's description adds no extra meaning. It does not explain how the 'values' parameter works or what values are allowed, but the schema already covers that.

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 minimal current Aare temperature and swimming recommendation for a location. The verb 'Get' and specific resource are immediately evident, distinguishing it from siblings like get_cities or get_historical_data.

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

Usage Guidelines2/5

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

No guidance is provided on when to use this tool versus alternatives such as get_current_conditions or get_widget_data. There is no mention of prerequisites or scenarios where other tools would be preferred.

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

get_widget_dataA

Get current Aare data for all locations at once, suitable for widgets/dashboards

ParametersJSON Schema

Name	Required	Description	Default
`app`	No	Optional app identifier	aareguru-mcp-server
`values`	No	Optional comma-separated list of specific values to extract
`version`	No	Optional version number	1.0.0

TDQS

A3.6/5.0

Behavior3/5

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

With no annotations, the description carries full burden. It states it returns data for all locations at once, but lacks details on data freshness, pagination, or any limitations. It is adequate but not thorough.

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?

A single sentence that is front-loaded and contains no unnecessary words. Every part earns its place.

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

Completeness2/5

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

Given the tool has 3 optional parameters and no output schema, more context is needed. The description does not explain what data is returned or any constraints, which is insufficient for a data retrieval tool.

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 100%, so baseline is 3. The description adds no extra meaning beyond the schema's parameter descriptions. Parameters are self-explanatory from the schema.

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 verb 'Get', resource 'current Aare data for all locations', and context 'suitable for widgets/dashboards'. It effectively distinguishes from sibling tools that focus on subsets or different data types.

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

Usage Guidelines3/5

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

The description implies use for dashboard display but does not explicitly state when to use this tool over siblings like get_current_conditions or get_today_summary. No when-not-to-use guidance is provided.

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

Tool Schema Changelog

Recent tool additions, removals, and schema changes observed during successful MCP inspections. Dates show when Glama detected each change.

5 tool updatesv1.0.0Apr 11, 2026
- First observedget_cities
- First observedget_current_conditions
- First observedget_historical_data
- First observedget_today_summary
- First observedget_widget_data

Install Server

RayrunBuild, deploy, and operate MCP servers without becoming an infrastructure team.ray.runAd

TDQS

A3.7/5.0

Disambiguation4/5

Tools are largely distinct: get_cities lists locations, get_current_conditions provides comprehensive data for one location, get_today_summary offers a minimal subset (temp + swim recommendation), get_historical_data gives time series, and get_widget_data aggregates current data for all locations. Slight overlap between current conditions and today summary, but descriptions clarify the difference.

Naming Consistency5/5

All tool names consistently use the get_ prefix with snake_case and follow a clear verb_noun pattern (e.g., get_cities, get_current_conditions). The naming is uniform and predictable.

Tool Count5/5

With 5 tools covering city listing, two levels of current data, historical data, and aggregated data, the set is well-scoped for the domain of Aare river data access. The number is appropriate and not excessive.

Completeness5/5

The tool set provides complete coverage for a read-only data API: city enumeration, current conditions (both comprehensive and minimal), historical time series, and batch data for dashboards. There are no obvious gaps, as the domain does not require create, update, or delete operations.

Maintenance

ActivityInactive

ResponsivenessSyncing

Resources

Need Help?

Reddit Discussion

Related Servers

Unclaimed servers have limited discoverability.

Looking for Admin?

If you are the server author, to access and configure the admin panel.

Related MCP Connectors

MeteoSwiss MCP Server A
io.github.eins78
Swiss weather data for AI assistants — forecasts, measurements, stations, pollen.
Weather Services Location Services Open Data
722
UK Environmental Intelligence MCP Server from MCPBundles AOAuth
com.mcpbundles
Access UK flood warnings, river levels, water quality, Met Office forecasts, and carbon data
Government Data Weather Services Open Data
2
USGS Water Monitoring A
com.olyport
Real-time water levels and flow rates from USGS stream gauges
Government Data Open Data Monitoring
32
usgs-water-mcp-server A
io.github.cyanheads
Query real-time and historical USGS water data from ~8,000 stream gages and groundwater wells.
Government Data Open Data
721

Related MCP Servers

LandiWetter MCP Server
Weather Services Search
nabossha
A
license
D
quality
D
maintenance
Provides Swiss weather forecast data, allowing users to search for Swiss locations and get detailed hourly and daily weather forecasts.
Updated a year ago (2025-05-06 15:19 UTC)
2
2
MIT
Environment Agency Flood
Government Data Open Data Weather Services
dwain-barnes
A
license
B
quality
C
maintenance
Provides access to UK Environment Agency's real-time flood monitoring data, enabling users to check flood warnings, monitor water levels and flow rates, and access historical measurements from monitoring stations across the UK.
Updated 2 months ago (2026-07-09 19:04 UTC)
11
22
MIT
Aareguru MCP Server
Weather Services Location Services
schlpbch
A
license
B
quality
C
maintenance
Provides Swiss Aare river swimming data including water temperature, flow rates, safety assessments, and forecasts. Enables AI assistants to answer questions about current conditions, compare cities, and provide safety recommendations based on official BAFU thresholds.
Updated 4 months ago (2026-05-17 08:26 UTC)
18
4
MIT
meteoswiss-mcp
Weather Services Open Data
malkreide
A
license
A
quality
A
maintenance
Enables AI models to access Swiss weather and climate data from MeteoSwiss, including current observations, forecasts, and warnings.
Updated 6 days ago (2026-08-31 00:10 UTC)
6
MIT

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/baking-bread/aareguru-mcp'

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