The Aareguru MCP Server provides real-time Swiss Aare river data and swimming condition analysis for AI assistants, with no authentication required.
6 Tools:
get_current_temperature – Water temperature for any monitored city (default: Bern), including Swiss German descriptions (e.g., "geil aber chli chalt"), swimming suitability, and seasonal advice
get_current_conditions – Comprehensive conditions: water temperature, flow rate, water height, weather, and 2-hour forecast
get_flow_danger_level – Flow rate and BAFU safety assessment with danger levels (Safe / Moderate / Elevated / High / Very High)
compare_cities – Parallel comparison of multiple cities to find warmest/safest spots (8-13x faster than sequential)
get_forecasts – Batch forecasts for multiple cities concurrently: current temperature, 2-hour forecast, and trend
get_historical_data – Time-series temperature and flow data over custom date ranges for trend analysis
3 Resources accessible via aareguru:// URIs (city lists, full current data, minimal current data)
3 Pre-built Prompts:
daily_swimming_report – Comprehensive daily conditions and recommendations
compare_swimming_spots – Best swimming spots across all monitored cities
weekly_trend_analysis – Temperature and flow trend analysis
Additional features: Prometheus-compatible metrics for monitoring, rate limiting (100 req/min), and multiple deployment options (FastMCP Cloud, local, Docker, cloud platforms).
Exposes a metrics endpoint for monitoring and observability, tracking tool invocation counts, execution durations, and API request health.
Click on "Install Server".
Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state.
In the chat, type @ followed by the MCP server name and your instructions, e.g., "@Aareguru MCP Server is it safe to swim in Bern today?"
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.
MCP server for Swiss Aare river data, enabling AI assistants like Claude to answer questions about swimming conditions, water temperature, flow rates, and safety.
Latest Release: v4.7.3 — WooCommerce checkout nonce header fix (400 Bad Request). See docs/RELEASE_NOTES_v4.7.3.md for details.
Use directly from FastMCP Cloud (no installation needed).
Add it as a custom connector in Claude Desktop:
No authentication is needed.
Alternatively, add the aareguru-mcp.mcpb file via
Claude → Settings → Extensions, or edit the Claude Desktop config directly:
{
"mcpServers": {
"aareguru": {
"url": "https://aareguru.fastmcp.app/mcp"
}
}
}Related MCP server: MeteoSwiss MCP Server
Feature | Description |
12 MCP Tools | Temperature, flow, safety, forecasts, history, comparisons + shop/checkout |
8 MCP Resources | Direct data access via |
3 MCP Prompts | Daily reports, spot comparisons, weekly trends |
9 FastMCPApps | Interactive dashboards, charts, map, cart/checkout — in de / en / fr / it |
UCP Checkout | Shop cart and checkout via Universal Commerce Protocol over WooCommerce |
MCP Elicitation | Asks for confirmation on dangerous flows and large data requests |
Rate Limiting | 100 req/min, 1000 req/hour protection against abuse |
Metrics | Prometheus endpoint for monitoring and observability |
Swiss German | Authentic temperature descriptions ("geil aber chli chalt") |
BAFU Safety | Official flow danger levels and thresholds |
464 Tests | 80% coverage, comprehensive test suite (0 skipped) |
Async-First | Context managers, parallel API fetching with asyncio.gather() |
Tool | Description | Example Query |
| Water temperature with Swiss German text | "What's the Aare temperature?" |
| Full conditions (temp, flow, weather) | "How's the Aare looking today?" |
| Flow rate + BAFU safety assessment | "Is it safe to swim?" |
| Compare all cities (parallel fetching) | "Which city is warmest?" |
| Forecasts for multiple cities (parallel) | "Show forecasts for all cities" |
| Temperature/flow history (hourly data) | "Show last 7 days for Bern" |
Tool | Description | Example Query |
| Browse merchandise catalog with prices in CHF | "What merch is available?" |
| Full details for a specific product | "Tell me more about the swim buoy" |
| Start a UCP checkout session (adds items to cart) | "I want to buy the beach towel" |
| Attach billing/shipping address to a session | "My address is Bahnhofplatz 1, Bern" |
| Submit the order and return the PostFinance payment URL | "Confirm my order" |
| Cancel a session and clear the cart | "Never mind, cancel my order" |
Flow Rate | Level | Status |
< 100 m³/s | Safe | Swimming OK |
100–220 m³/s | Moderate | Experienced swimmers only |
220–300 m³/s | Elevated | Caution advised |
300–430 m³/s | High | Dangerous |
> 430 m³/s | Very High | Extremely dangerous |
URI | Description |
| All monitored cities with coordinates |
| Full current conditions for a city |
| Minimal current snapshot |
| Weather forecast entries |
| Historical hourly time series |
| BAFU 1–5 danger level reference table |
| Flow zone breakpoints with hex colors |
| Merchandise catalog from konsum.aare.guru |
Nine apps render rich UIs directly inside AI conversations via fastmcp[apps]:
App | Description |
| Dashboard: water temp, flow, weather, BAFU level |
| Area chart of temperature and flow over time |
| Sortable table comparing all cities |
| 24-hour forecast with air-temperature chart |
| Today's intraday water temperature sparkline |
| All cities ranked by temperature or safety |
| BAFU 1–5 danger level briefing with current reading |
| Interactive OpenStreetMap with all stations, satellite toggle |
| Cart and UCP checkout UI: items, total, billing, payment URL |
Prompt | Description |
| Comprehensive daily report with conditions, safety, forecast, and recommendation |
| Compare all cities to find the best swimming spot today |
| Analyze temperature and flow trends over the past week |
# Install uv and clone
curl -LsSf https://astral.sh/uv/install.sh | sh
git clone https://github.com/schlpbch/aareguru-mcp.git && cd aareguru-mcp
uv sync
# Run tests
uv run pytestEdit ~/Library/Application Support/Claude/claude_desktop_config.json:
{
"mcpServers": {
"aareguru": {
"command": "uv",
"args": ["--directory", "/path/to/aareguru-mcp", "run", "aareguru-mcp"]
}
}
}cp .env.example .env
docker-compose up -d
curl http://localhost:8000/healthThis server is deployed on FastMCP Cloud, a managed platform for MCP servers with zero-config deployment.
Features:
✅ Zero-Config Deployment — Connect GitHub repo, automatic deployment
✅ Serverless Scaling — Scale from 0 to millions of requests instantly
✅ Git-Native CI/CD — Auto-deploy on push to main, branch deployments
for PRs
✅ Built-in Security — OAuth support, token management, secure endpoints
✅ MCP Analytics — Request/response tracking, tool usage insights
✅ Free Tier — Available for personal servers
Deployment Steps:
Sign in to fastmcp.cloud with GitHub
Create Project and link your repository
Deploy — Platform automatically clones, builds, and deploys
Access — Get your unique URL (e.g., https://aareguru.fastmcp.app/mcp)
Configuration:
No special configuration needed. FastMCP Cloud auto-detects FastMCP servers:
Health endpoint: https://your-app.fastmcp.app/health
MCP endpoint: https://your-app.fastmcp.app/mcp
Pricing:
Free tier for personal projects
Pay-as-you-go for teams (usage-based)
FastMCP servers can be deployed to any Python-compatible cloud platform.
Container Platforms: Google Cloud Run, AWS ECS/Fargate, Azure Container Instances
PaaS Providers: Railway, Render, Vercel
Cloud VMs: AWS EC2, Google Compute Engine, Azure VMs
The server exposes Prometheus-compatible metrics at /metrics:
Metric | Type | Description |
| Counter | Tool invocations by name and status |
| Histogram | Tool execution times |
| Counter | Aareguru API requests |
| Counter | Errors by type and component |
| Gauge | Currently active requests |
HTTP endpoints are protected with rate limiting:
Default limits: 100 requests/minute, 1000 requests/hour
Health endpoint: 60 requests/minute
Headers: Rate limit info included in responses
429 responses: Automatic retry-after headers when limits exceeded
uv run pytest # Run tests (464 tests, all passing)
uv run pytest --cov=aareguru_mcp # With coverage (80%)
uv run ruff check src/ tests/ # Lint (all passing)
uv run mypy src/ # Type check (0 errors)
uv run fastmcp dev apps run-ext-apps.py # Preview all 9 appsFor comprehensive visual testing, render all 12 apps on one page:
./run-debug-all-apps.sh # Start debug server on http://localhost:3000This debug page includes:
✅ Complete conditions dashboard
✅ All 4 individual condition cards (temperature, flow, weather, sun)
✅ Historical chart (7 days) and intraday sparkline
✅ 24-hour forecast view
✅ City comparison table and city finder
✅ Safety briefing with BAFU levels
✅ Interactive OpenStreetMap with all stations
✅ Shop cart and checkout (UCP)
Perfect for:
Visual regression testing
Design system verification
Quick overview of all UI components
Debugging layout and styling issues
ARCHITECTURE.md — Comprehensive architecture guide
CLAUDE.md — Development guide for AI assistants
specs/ADR_COMPENDIUM.md — 18 Architecture Decision Records
docs/ — API documentation and planning
aareguru-mcp/
├── src/aareguru_mcp/
│ ├── apps/ # 9 FastMCPApps (conditions, history, compare, …, map, shop)
│ ├── server.py # FastMCP server, tools, resources, prompts
│ ├── service.py # Business logic service layer
│ ├── client.py # Async HTTP client with caching
│ ├── models.py # Pydantic models
│ └── helpers.py # Shared utilities
├── tests/ # 464 tests, 80% coverage (0 skipped)
├── docs/ # API docs, testing, implementation notes
├── ARCHITECTURE.md
├── CLAUDE.md
└── pyproject.tomlNo personal data is collected. See PRIVACY.md for the full policy.
Data from BAFU, Aare.guru, MeteoSchweiz, Meteotest.
Non-commercial use only — Contact: aaregurus@existenz.ch
MIT License — See LICENCE.md
Built with ❤️ for the Swiss Aare swimming community
Show an interactive OpenStreetMap with all Aare monitoring stations.
Each city is plotted as a circle marker coloured by BAFU safety level. Click a marker to see temperature, flow, and Swiss German description.
| Name | Required | Description | Default |
|---|---|---|---|
| city | No | Optional city identifier to fly to on load (e.g. 'Bern', 'Thun'). Omit to show all cities with the map fitted to bounds. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. It explains interactive features (click to see details), but does not disclose potential limits like data freshness, map loading behavior, or number of markers.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, front-loaded with purpose, no redundant words. Every sentence adds value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a map visualization tool, description covers what it shows and how to interact. No output schema needed as result is a visual map. No missing critical information.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Input schema covers 100% of parameters. Description adds value by explaining that 'city' is optional, defaults to null, and that omitting it shows all cities fitted to bounds. This goes beyond schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states it shows an interactive OpenStreetMap with Aare monitoring stations, colored markers by safety level, and click interaction for details. This distinguishes it from sibling tools like get_current_conditions or forecast_view which focus on data, not mapping.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Description does not explicitly mention when to use this tool versus alternatives. However, it implies usage for spatial overview of monitoring stations, which is unique among siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Show all cities ranked by water temperature or safety.
Fetches live data for every available city and ranks them so swimmers can instantly find the warmest or safest spot.
| Name | Required | Description | Default |
|---|---|---|---|
| sort_by | No | Ranking criterion — 'temperature' (warmest first, default) or 'safety' (lowest flow / safest first) | temperature |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided; description mentions 'fetches live data for every city' but does not disclose potential performance impact, whether it's read-only, or any limitations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two efficient sentences with front-loaded key information, no wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
No output schema provided; description does not specify return format (list of cities with values), leaving agents to infer the output structure.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% and parameter description is adequate; tool description adds no extra meaning beyond reiterating the two ranking options.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Clearly states verb (show), resource (all cities), and purpose (ranked by temperature or safety). Distinguishes 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.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Implies usage for swimmers wanting an overview, but does not explicitly exclude use cases or suggest alternatives among many sibling tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Compare multiple cities
This is the recommended tool for comparing one to many cities.
Args:
cities: List of city identifiers (e.g., ['Bern', 'Thun']).
If None, compares all available cities.
Returns: Dictionary with: - cities: List of city data with temperature, flow, safety - warmest: City with highest temperature - coldest: City with lowest temperature - safe_count: Number of cities with safe flow conditions - total_count: Total cities compared
| Name | Required | Description | Default |
|---|---|---|---|
| cities | No |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It details the return value structure (dictionary with specific keys), which adds transparency. However, it does not disclose whether the operation is read-only, safe, or has any side effects. The behavioral traits beyond output are not fully addressed.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is highly concise and well-structured. It front-loads the core purpose in the first line, then uses labeled sections for Args and Returns. Every sentence serves a purpose with no extraneous information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has an output schema, the description covers return values effectively. However, it could include more context about input validation (e.g., valid city identifiers, maximum number of cities) or prerequisites. Still, overall completeness is good.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description adds significant meaning beyond the input schema. It provides an example format (`['Bern', 'Thun']`), explains that 'None' means compare all available cities, and clarifies the parameter is optional. This compensates well for the 0% schema description coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'Compare multiple cities' and explicitly says it is 'the recommended tool for comparing one to many cities.' The verb 'compare' and resource 'cities' are specific, and the sibling tools (e.g., compare_cities_table) are differentiated by the description's emphasis on general comparison.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context on when to use this tool ('recommended tool for comparing one to many cities'), but it does not explicitly state when not to use it or name specific alternatives. However, this is sufficient guidance for an AI agent to differentiate from siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Show a sortable, searchable table comparing Aare conditions across cities.
Header summary cards use the aare.guru cyan (#2be6ff) accent. Safety column uses BAFU color coding.
| Name | Required | Description | Default |
|---|---|---|---|
| cities | No | City identifiers to compare. If omitted, compares all available cities. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description mentions visual behaviors (header summary cards using a specific color, safety column using BAFU color coding), but does not disclose other behavioral traits such as whether it is read-only, has rate limits, or any side effects. With no annotations, the description partially covers transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Three sentences, front-loaded with the primary purpose. The second and third sentences add specific styling details which may be useful but could be considered extraneous for an AI agent. Still, it is concise overall.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description does not explain what columns or data fields the table contains beyond mentioning a 'safety column'. With no output schema and no annotations, the agent lacks information about the tool's return format and contents, making it incomplete for a table-displaying tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema already provides full description for the single 'cities' parameter, including its behavior when omitted. The description adds no additional meaning beyond what the schema states, so baseline 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Show a sortable, searchable table comparing Aare conditions across cities.' It uses a specific verb and resource, and distinguishes from sibling tools like 'compare_cities' which may have a different format.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies the tool is for a tabular comparison, but does not explicitly state when to use it over other tools like 'compare_cities' or 'conditions_dashboard'. No when-not or alternative guidance is provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Show an interactive aare.guru-style dashboard of current Aare conditions.
Displays water temperature in the signature Aare cyan (#2be6ff) card, flow rate, BAFU safety level with the characteristic thick teal border, Swiss German description, and a danger alert when flow is elevated.
| Name | Required | Description | Default |
|---|---|---|---|
| city | No | City identifier (e.g. 'Bern', 'Thun', 'Olten') | Bern |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations are absent, so the description carries full burden. It describes the interactive and visual nature (cyan card, teal border, danger alert) but does not explicitly state it is read-only or mention any side effects. This is sufficient for a non-destructive tool but lacks explicit behavioral guarantees.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two efficient sentences: first gives the core purpose, second elaborates on key features. No redundancy or filler. Well front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
No output schema and the description does not specify the return format (e.g., HTML, JSON, data). For a dashboard tool that likely renders something, this is a gap. However, the description clearly lists what is displayed, which is somewhat complete for a simple tool with one parameter.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with a single parameter whose description provides examples (Bern, Thun, Olten). The tool description adds no extra meaning beyond the schema, only referencing 'city' indirectly. Baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it shows an interactive dashboard of current Aare conditions, lists specific displayed elements (water temperature, flow rate, safety level, etc.), and uses the specific resource 'Aare conditions'. This distinguishes it from sibling tools like flow_card or temperature_card which focus on single metrics.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies it is for an overview or summary of conditions but does not explicitly state when to use it over siblings like get_current_conditions or forecast_view. The context from sibling names helps, but no exclusions or alternatives are mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Show an interactive Aare flow and safety level card.
Displays water flow in m³/s with BAFU safety level assessment and color-coded flow zones.
| Name | Required | Description | Default |
|---|---|---|---|
| city | No | City identifier (e.g. 'Bern', 'Thun', 'Olten') | Bern |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries behavioral burden. Mentions 'interactive card' and data shown (flow, safety level, color zones), but does not disclose if it's read-only, requires user interaction, or has any side effects. Moderate transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, front-loaded with purpose. No redundant information. Efficient and clear.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Adequate for a simple card tool with one optional parameter. No output schema, so return values are not covered. Could mention that it returns a visual element or interaction model. Complete enough given context signals.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Input schema has one parameter 'city' with description, and schema coverage is 100%. The description adds no additional meaning about the parameter, so baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Clearly states it shows an interactive Aare flow and safety level card, specifying water flow in m³/s with BAFU assessment and color-coded zones. However, sibling tools like 'get_flow_danger_level' also handle safety, so differentiation is missing.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives like 'get_flow_danger_level' or 'conditions_dashboard'. The description implies it's for a visual card, but context of use is not explicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Show a 24-hour forecast with air-temperature chart and hourly card strip.
Displays the 2-hour water temperature trend alongside an hourly weather prognosis (MeteoSwiss symbols, air temp, precipitation) for the full day.
| Name | Required | Description | Default |
|---|---|---|---|
| city | No | City identifier (e.g. 'Bern', 'Thun', 'Olten') | Bern |
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 details the displayed elements (air/water temperature, precipitation, symbols) but does not mention side effects, permissions, or rate limits. It is safe but incomplete for a mutation-free tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences, front-loading the main purpose and adding relevant detail in the second. No extraneous words, achieving high conciseness with all necessary information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema, the description covers the key visual outputs (chart, card strip, water trend, symbols). It could mention whether the chart is interactive or static, but overall it is sufficient for a forecast view tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the description does not need to add parameter details. However, it adds no extra context about the 'city' parameter beyond what the schema provides, making it adequate but not exceptional.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses specific verbs ('Show', 'Displays') and resources ('24-hour forecast', 'air-temperature chart', 'hourly card strip'), clearly indicating the tool provides a visual forecast view. It distinguishes from siblings like 'get_forecasts' by emphasizing the graphical presentation format, but could more explicitly contrast with raw data tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for viewing a forecast visually but lacks explicit when-to-use or when-not-to-use guidance. With siblings such as 'get_forecasts' and 'weather_card', stating the advantage of this view (e.g., 'Use for a graphical overview') would strengthen guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get complete current conditions for a city.
Use this for safety assessments, 'is it safe to swim?' questions, and when users need a complete picture before swimming. This is the most detailed tool.
| Name | Required | Description | Default |
|---|---|---|---|
| city | No | City identifier (e.g., 'Bern', 'Thun', 'Olten'). Use `list_cities()` to discover available locations. | Bern |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. It states 'complete current conditions' but does not disclose whether the tool is read-only, requires authentication, or has any side effects. No mention of data freshness, pagination, or response structure.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, no fluff. Purpose and usage guidelines are front-loaded. Every sentence adds value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple 1-parameter tool with an output schema, the description is mostly sufficient. It names the resource and usage context. Could briefly explain what 'complete' covers, but output schema likely handles that.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema already has 100% coverage with a description for the 'city' parameter including examples and a reference to list_cities(). The tool description adds no extra parameter semantics beyond what is in the schema, so baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states 'Get complete current conditions for a city', uses a specific verb and resource. It differentiates from siblings by claiming 'This is the most detailed tool' and provides concrete usage examples such as safety assessments and swimming questions.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly tells when to use: 'Use this for safety assessments, is it safe to swim? questions, and when users need a complete picture before swimming.' It implies this is the most detailed option but does not explicitly state when to avoid it or mention alternatives like get_current_temperature.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get current water temperature for a city.
Use this for quick temperature checks and simple 'how warm is the water?' questions. Returns temperature in Celsius, Swiss German description (e.g., 'geil aber chli chalt'), and swimming suitability.
| Name | Required | Description | Default |
|---|---|---|---|
| city | No | City identifier (e.g., 'Bern', 'Thun', 'Olten'). Use `list_cities()` to discover available locations. | Bern |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description fully bears the behavioral disclosure burden. It discloses return format (temperature, Swiss German description, swimming suitability) and implies a read-only operation. It could add more about data freshness or error conditions, but the provided information is sufficient for safe invocation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is three concise sentences with no redundancy. Each sentence provides essential information: action, use case, and output details.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple tool with one parameter and an output schema, the description is fairly complete. It covers purpose, usage guidance, and output format. Minor gaps like error handling or data freshness are not critical given the tool's simplicity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with a descriptive parameter for 'city' that includes default and examples. The description adds no additional parameter semantics beyond the schema, so a baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'Get current water temperature for a city.' It distinguishes from sibling tools by focusing on quick temperature checks and water-specific queries, contrasting with other tools like 'compare_cities' or 'get_forecasts'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description advises use for 'quick temperature checks and simple how warm is the water? questions,' implying when to choose this tool. It does not explicitly name alternatives or state when not to use, but the context of sibling tools provides clear differentiation.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get current flow rate and BAFU danger assessment.
Use this for safety-critical questions about current strength and swimming danger.
Flow Safety Thresholds:
<100 m³/s: Safe · 100-220: Moderate · 220-300: Elevated
300-430 m³/s: High — dangerous · >430: Very high — extremely dangerous
| Name | Required | Description | Default |
|---|---|---|---|
| city | No | City identifier (e.g., 'Bern', 'Thun', 'Olten'). Use `list_cities()` to discover available locations. | Bern |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It lacks disclosure of behavioral traits such as side effects, authentication needs, or whether it is a read-only operation. The description only states it 'get's' data, implying no mutation, but is 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.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise with a clear header and structured thresholds list. Every sentence adds value, though the thresholds could be presented more compactly without compromising clarity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given that the tool has an output schema, the description need not explain return values. It provides thresholds for interpretation and context for safety-critical use, making it reasonably complete for its complexity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Input schema coverage is 100%, so the schema already documents the city parameter with description referencing list_cities(). The description adds flow safety thresholds which help interpret output but do not add meaning to the parameter itself, keeping it at baseline.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it retrieves current flow rate and BAFU danger assessment, which distinguishes it from sibling tools like get_current_conditions that may not include danger assessment. However, it does not explicitly differentiate itself, leaving some ambiguity.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description specifies using this tool for safety-critical questions about current strength and swimming danger, providing clear context for its use. However, it does not mention when not to use it or offer alternatives like safety_briefing.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get forecasts for multiple cities.
Fetches all forecasts concurrently.
Args:
cities: List of city identifiers (e.g., ['Bern', 'Thun'])
Returns: Dictionary mapping city names to forecast data: - forecasts (dict): Map of city to forecast data with current temp, 2-hour forecast, and trend
| Name | Required | Description | Default |
|---|---|---|---|
| cities | Yes |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. Discloses concurrent fetching and return structure. Lacks error handling or rate limits, but adequate for this simple tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Well-structured with Args/Returns sections, but includes some redundancy. Concise enough while being informative.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (1 parameter, clear output schema), description covers purpose, parameters, and return values completely. Output schema rich, so return description is adequate.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Input schema has 0% description coverage, but description adds examples (e.g., ['Bern', 'Thun']) and explains city identifiers, providing context beyond schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states 'Get forecasts for multiple cities' and specifies concurrency, distinguishing it from sibling single-city 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.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit guidance on when to use versus alternatives; only states what the tool does. Implicitly, it's for multiple cities, but no exclusions or comparisons.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get historical time-series data.
Use this for trend analysis, comparisons with past conditions, and statistical queries. Returns hourly data points for temperature and flow.
| Name | Required | Description | Default |
|---|---|---|---|
| city | Yes | City identifier (e.g., 'Bern', 'Thun', 'Olten') | |
| start | Yes | Start date/time — ISO, Unix timestamp, or relative ('-7 days', '-1 month') | |
| end | Yes | End date/time — ISO, Unix timestamp, or 'now' |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It states the output is 'hourly data points for temperature and flow,' which provides basic behavioral context. However, it does not disclose potential limitations like data range restrictions or API costs.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is very concise: two sentences that front-load the core purpose and then add usage guidance and output details. Every sentence earns its place with no wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The input schema is fully documented, and an output schema exists (though not shown). The description explains the type and granularity of returned data. It does not cover pagination or edge cases, but for a straightforward historical data retrieval tool, it is sufficiently complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Input schema has 100% description coverage, so the baseline is 3. The description adds that the tool returns hourly temperature and flow data, which provides context but does not add specific parameter-level meaning beyond what the schema already provides.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Get historical time-series data' and lists specific use cases: trend analysis, comparisons with past conditions, and statistical queries. This distinguishes it from sibling tools like get_current_conditions and get_forecasts.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit usage guidance ('Use this for trend analysis...'), but does not mention when not to use it or list alternative tools. However, the context of sibling tools makes the intended use clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Show an aare.guru-style area chart of historical Aare temperature and flow.
Uses the Aare color palette: #0877ab for temperature, #357d9e for flow.
| Name | Required | Description | Default |
|---|---|---|---|
| city | No | City identifier (e.g. 'Bern', 'Thun', 'Olten') | Bern |
| start | No | Start of period (e.g. '-7 days', '-1 month', ISO timestamp) | -7 days |
| end | No | End of period ('now' or ISO timestamp) | now |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, and the description only mentions the color palette as behavioral detail. It does not disclose data freshness, caching, or any side effects, leaving the agent with limited understanding of the tool's behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences, front-loaded with the core purpose, and the second sentence adds relevant detail about the color palette. No wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Without an output schema, the description does not explain the chart format (e.g., image URL, embedded data) or how to interpret it. Given many sibling tools, this lacks completeness for effective selection and use.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the baseline is 3. The description adds no additional meaning beyond the schema; it mentions temperature and flow but does not elaborate on parameter usage or constraints.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool shows an area chart of historical Aare temperature and flow, using a specific verb 'Show' and resource. However, it does not differentiate this chart tool from siblings like 'get_historical_data' which may return raw data, leaving potential ambiguity.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool vs. alternatives. The description only states what the tool does without mentioning context, prerequisites, or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Show today's water temperature as an intraday area chart.
Uses the past readings from the current-conditions response to plot how the Aare temperature has evolved throughout the day — no extra API call required.
| Name | Required | Description | Default |
|---|---|---|---|
| city | No | City identifier (e.g. 'Bern', 'Thun', 'Olten') | Bern |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It discloses that no extra API call is required, but does not explain behavior when data is unavailable, or side effects.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, 32 words, front-loaded with purpose, no wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Simple tool with one parameter and no output schema. The description covers basic functionality but lacks detail on output format and prerequisites (e.g., needing prior current-conditions data).
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so baseline is 3. The tool description does not add additional meaning beyond the schema's parameter description.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool shows today's water temperature as an intraday area chart, using past readings from the current-conditions response. It distinguishes itself from data-fetching tools like get_current_conditions and historical chart tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage after obtaining current-conditions data, but does not explicitly state when to use versus alternatives, nor does it mention prerequisites or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Show the official BAFU 1–5 danger level scale with the current reading highlighted.
Translates the hydrological danger level into plain swimmer guidance, using the actual flow_gefahrenstufe from the API where available.
| Name | Required | Description | Default |
|---|---|---|---|
| city | No | City identifier (e.g. 'Bern', 'Thun', 'Olten') | Bern |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden. It discloses that the tool uses an API (flow_gefahrenstufe) to highlight the current reading, but does not elaborate on any side effects, network dependencies, or error behavior. It is honest but lacks depth.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description consists of two concise sentences with no wasted words. The primary function is stated upfront in the first sentence, and the second adds a key detail about the data source.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (one optional parameter, no output schema, no annotations), the description covers the core purpose and data dependency. It could be improved by briefly mentioning the return format (e.g., text or visual representation), but it is largely sufficient.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 100% description coverage for the sole parameter 'city' with an example list. The description adds no additional meaning beyond what the schema already provides, so baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses specific verbs ('Show', 'Translates') and clearly identifies the resource (BAFU 1–5 danger level scale with current reading and plain swimmer guidance). It distinguishes itself from the sibling 'get_flow_danger_level', which likely returns raw data, by emphasizing the scale visualization and translation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for displaying the danger scale and plain language guidance, but it does not explicitly state when to use this tool versus alternatives like 'get_flow_danger_level' or other display tools. No exclusions or alternatives are mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Show an interactive Aare sun and sunshine card.
Displays total sunshine hours for today, sunset time, and time-left-in-sun for nearby locations.
| Name | Required | Description | Default |
|---|---|---|---|
| city | No | City identifier (e.g. 'Bern', 'Thun', 'Olten') | Bern |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden for behavioral disclosure. It does not explicitly state that the tool is read-only, safe, or idempotent. While displaying a card suggests read-only behavior, this is not stated, leaving gaps for an agent to assess side effects or permissions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description consists of two concise sentences without any redundant information. Every word adds value, stating the tool's purpose and the specific data it displays.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (one optional parameter, no output schema), the description adequately covers the displayed data. However, it does not mention the behavior for invalid city inputs or the nature of the interactive card. This is a minor gap; for a straightforward tool it is nearly complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema already provides a clear description for the only parameter 'city'. The tool description adds 'for nearby locations' which is consistent but does not provide additional semantics beyond what the schema offers. With 100% schema coverage, the baseline score is 3.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool 'Show an interactive Aare sun and sunshine card' and lists specific data points (total sunshine hours, sunset time, time-left-in-sun). This verb+resource structure is distinct from sibling tools like temperature_card or weather_card, which cover different weather aspects.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus its siblings. It does not mention prerequisites, alternatives, or exclusion criteria. Agents must infer usage solely from the listed output fields.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Show an interactive Aare water temperature card.
Displays the current water temperature in the signature Aare cyan card with 2-hour forecast trend and Swiss German description.
| Name | Required | Description | Default |
|---|---|---|---|
| city | No | City identifier (e.g. 'Bern', 'Thun', 'Olten') | Bern |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so the description carries full burden. It mentions 'interactive' but does not explain interactivity, data freshness, side effects, or any behavioral specifics beyond the visual output.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences with no wasted words. The key purpose and content are front-loaded, making it easy for an AI agent to quickly understand the tool's core function.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Description covers the main output elements (temperature, forecast, description) but lacks context on how it fits among many sibling tools. For a simple tool with one optional param, it is adequate but could be more complete about use case compared to forecast_view or get_forecasts.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Input schema has one optional string parameter 'city' with description listing examples. Schema coverage is 100%, so baseline is 3. The description does not add extra semantic information beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool shows an interactive Aare water temperature card with current temperature, 2-hour forecast trend, and Swiss German description. It distinguishes itself from siblings like get_current_temperature (raw data) and flow_card (different focus) by emphasizing the card presentation and specific content.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives (e.g., get_current_temperature for raw data, forecast_view for longer forecasts). The description only states what it does, not when it is appropriate.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Show an interactive Aare weather card.
Displays current air temperature, precipitation risk, and a 6-day forecast strip.
| Name | Required | Description | Default |
|---|---|---|---|
| city | No | City identifier (e.g. 'Bern', 'Thun', 'Olten') | Bern |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description should disclose behavioral traits. It mentions 'interactive' but does not explain interactivity (e.g., embedded buttons, live updates). It lacks information on data freshness, caching, auth needs, or side effects. For a display tool, it could state that it renders a card or updates in real-time.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise at two sentences, with no wasted words. Every sentence adds value: first states the tool type, second lists displayed data. Ideal for quick parsing.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
No output schema exists, so the description should clarify the return format (e.g., rendered HTML, structured data). It only says 'Show' but fails to specify what the agent receives. Without this, the agent cannot correctly handle the tool's output. Siblings like get_current_conditions likely return data, but this tool's return type is ambiguous.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% and the single parameter 'city' is well-described in the schema. The tool description adds no additional meaning beyond what the schema provides, earning a baseline score of 3.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool shows an interactive weather card with specific data (air temperature, precipitation risk, 6-day forecast). It distinguishes itself from simple data tools like get_current_temperature or temperature_card by being an interactive composite display, but it could explicitly contrast with siblings like forecast_view.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives such as forecast_view, temperature_card, or get_current_conditions. An agent is left to infer usage context without explicit when-to-use or when-not-to-use instructions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections. Dates show when Glama detected each change.
v4.6.0aare_mapcity_finder_viewcompare_cities1 field changedInput schema / additionalPropertiesAdded value: +falsecompare_cities_tableconditions_dashboardflow_cardforecast_viewget_current_conditions7 fields changedInput schema / additionalPropertiesAdded value: +falseInput schema / properties / city / descriptionAdded value: +"City identifier (e.g., 'Bern', 'Thun', 'Olten').\n Use `list_cities()` to discover available locations."Output schema / $defsRemoved value: -{
- "AareConditionsData": {
- "description": "Aare conditions data for conditions tool response.",
- "properties": {
- "flow": {
- "anyOf": [
- {
- "type": "number"
- },
- {
- "type": "null"
- }
- ],
- "default": null,
- "description": "Flow rate in m³/s"
- },
- "flow_text": {
- "anyOf": [
- {
- "type": "string"
- },
- {
- "type": "null"
- }
- ],
- "default": null,
- "description": "Flow description"
- },
- "forecast2h": {
- "anyOf": [
- {
- "type": "number"
- },
- {
- "type": "null"
- }
- ],
- "default": null,
- "description": "Temperature forecast for 2 hours"
- },
- "forecast2h_text": {
- "anyOf": [
- {
- "type": "string"
- },
- {
- "type": "null"
- }
- ],
- "default": null,
- "description": "Forecast description"
- },
- "height": {
- "anyOf": [
- {
- "type": "number"
- },
- {
- "type": "null"
- }
- ],
- "default": null,
- "description": "Water height in meters"
- },
- "location": {
- "anyOf": [
- {
- "type": "string"
- },
- {
- "type": "null"
- }
- ],
- "default": null,
- "description": "Location name"
- },
- "location_long": {
- "anyOf": [
- {
- "type": "string"
- },
- {
- "type": "null"
- }
- ],
- "default": null,
- "description": "Full location name"
- },
- "swiss_german_explanation": {
- "anyOf": [
- {
- "type": "string"
- },
- {
- "type": "null"
- }
- ],
- "default": null,
- "description": "English translation"
- },
- "temperature": {
- "anyOf": [
- {
- "type": "number"
- },
- {
- "type": "null"
- }
- ],
- "default": null,
- "description": "Water temperature in Celsius"
- },
- "temperature_text": {
- "anyOf": [
- {
- "type": "string"
- },
- {
- "type": "null"
- }
- ],
- "default": null,
- "description": "Swiss German temperature description"
- },
- "temperature_text_short": {
- "anyOf": [
- {
- "type": "string"
- },
- {
- "type": "null"
- }
- ],
- "default": null,
- "description": "Short description"
- },
- "warning": {
- "anyOf": [
- {
- "type": "string"
- },
- {
- "type": "null"
- }
- ],
- "default": null,
- "description": "Safety warning if applicable"
- }
- },
- "type": "object"
- }
-}Output schema / additionalPropertiesAdded value: +trueOutput schema / descriptionRemoved value: -"Response model for get_current_conditions tool."Output schema / propertiesRemoved value: -{
- "aare": {
- "anyOf": [
- {
- "$ref": "#/$defs/AareConditionsData"
- },
- {
- "type": "null"
- }
- ],
- "default": null,
- "description": "Aare river data"
- },
- "city": {
- "description": "City identifier",
- "type": "string"
- },
- "forecast": {
- "anyOf": [
- {
- "items": {
- "additionalProperties": true,
- "type": "object"
- },
- "type": "array"
- },
- {
- "type": "null"
- }
- ],
- "default": null,
- "description": "Weather forecast"
- },
- "seasonal_advice": {
- "anyOf": [
- {
- "type": "string"
- },
- {
- "type": "null"
- }
- ],
- "default": null,
- "description": "Season-specific guidance"
- },
- "weather": {
- "anyOf": [
- {
- "additionalProperties": true,
- "type": "object"
- },
- {
- "type": "null"
- }
- ],
- "default": null,
- "description": "Current weather conditions"
- }
-}Output schema / requiredRemoved value: -[
- "city"
-]get_current_temperature6 fields changedInput schema / additionalPropertiesAdded value: +falseInput schema / properties / city / descriptionAdded value: +"City identifier (e.g., 'Bern', 'Thun', 'Olten').\n Use `list_cities()` to discover available locations."Output schema / additionalPropertiesAdded value: +trueOutput schema / descriptionRemoved value: -"Response model for get_current_temperature tool."Output schema / propertiesRemoved value: -{
- "city": {
- "description": "City identifier",
- "type": "string"
- },
- "longname": {
- "anyOf": [
- {
- "type": "string"
- },
- {
- "type": "null"
- }
- ],
- "default": null,
- "description": "Full location name"
- },
- "name": {
- "anyOf": [
- {
- "type": "string"
- },
- {
- "type": "null"
- }
- ],
- "default": null,
- "description": "Location name"
- },
- "seasonal_advice": {
- "anyOf": [
- {
- "type": "string"
- },
- {
- "type": "null"
- }
- ],
- "default": null,
- "description": "Season-specific swimming guidance"
- },
- "suggestion": {
- "anyOf": [
- {
- "type": "string"
- },
- {
- "type": "null"
- }
- ],
- "default": null,
- "description": "Swimming recommendation based on temperature"
- },
- "swiss_german_explanation": {
- "anyOf": [
- {
- "type": "string"
- },
- {
- "type": "null"
- }
- ],
- "default": null,
- "description": "English translation of Swiss German phrase"
- },
- "temperature": {
- "anyOf": [
- {
- "type": "number"
- },
- {
- "type": "null"
- }
- ],
- "default": null,
- "description": "Water temperature in Celsius"
- },
- "temperature_prec": {
- "anyOf": [
- {
- "type": "number"
- },
- {
- "type": "null"
- }
- ],
- "default": null,
- "description": "Precise temperature value"
- },
- "temperature_text": {
- "anyOf": [
- {
- "type": "string"
- },
- {
- "type": "null"
- }
- ],
- "default": null,
- "description": "Swiss German description"
- },
- "temperature_text_short": {
- "anyOf": [
- {
- "type": "string"
- },
- {
- "type": "null"
- }
- ],
- "default": null,
- "description": "Short temperature description"
- },
- "warning": {
- "anyOf": [
- {
- "type": "string"
- },
- {
- "type": "null"
- }
- ],
- "default": null,
- "description": "Safety warning if flow is dangerous"
- }
-}Output schema / requiredRemoved value: -[
- "city"
-]get_flow_danger_level6 fields changedInput schema / additionalPropertiesAdded value: +falseInput schema / properties / city / descriptionAdded value: +"City identifier (e.g., 'Bern', 'Thun', 'Olten').\n Use `list_cities()` to discover available locations."Output schema / additionalPropertiesAdded value: +trueOutput schema / descriptionRemoved value: -"Response model for get_flow_danger_level tool."Output schema / propertiesRemoved value: -{
- "city": {
- "description": "City identifier",
- "type": "string"
- },
- "danger_level": {
- "anyOf": [
- {
- "type": "integer"
- },
- {
- "type": "null"
- }
- ],
- "default": null,
- "description": "Numeric danger level (1-5)"
- },
- "flow": {
- "anyOf": [
- {
- "type": "number"
- },
- {
- "type": "null"
- }
- ],
- "default": null,
- "description": "Current flow rate in m³/s"
- },
- "flow_text": {
- "anyOf": [
- {
- "type": "string"
- },
- {
- "type": "null"
- }
- ],
- "default": null,
- "description": "Flow description"
- },
- "flow_threshold": {
- "anyOf": [
- {
- "type": "number"
- },
- {
- "type": "null"
- }
- ],
- "default": null,
- "description": "Danger threshold for this location"
- },
- "safety_assessment": {
- "description": "Safety evaluation",
- "type": "string"
- }
-}Output schema / requiredRemoved value: -[
- "city",
- "safety_assessment"
-]get_forecasts1 field changedInput schema / additionalPropertiesAdded value: +falseget_historical_data4 fields changedInput schema / additionalPropertiesAdded value: +falseInput schema / properties / city / descriptionAdded value: +"City identifier (e.g., 'Bern', 'Thun', 'Olten')"Input schema / properties / end / descriptionAdded value: +"End date/time — ISO, Unix timestamp, or 'now'"Input schema / properties / start / descriptionAdded value: +"Start date/time — ISO, Unix timestamp, or relative ('-7 days', '-1 month')"historical_chartintraday_viewsafety_briefingsun_cardtemperature_cardweather_cardv3.3.0compare_citiesget_current_conditionsget_current_temperatureget_flow_danger_levelget_forecastsget_historical_dataTools have mostly distinct purposes with good descriptions. Some overlap exists (e.g., get_current_conditions vs. specific temperature/flow tools, compare_cities vs. compare_cities_table), but descriptions clarify the differences.
Naming is mixed: some tools use verb phrases (get_current_conditions, compare_cities), others use noun phrases (aare_map, temperature_card). Not consistently following a single pattern.
18 tools cover a wide range of functionality for Aare river conditions, including queries, maps, forecasts, historical data, and visual cards. Slightly high but still well-scoped for the domain.
The tool set covers current conditions, flow, temperature, safety, forecasts, historical data, maps, and comparisons. Minor gaps (e.g., no explicit alert tool) but overall comprehensive.
Unclaimed servers have limited discoverability.
If you are the server author, to access and configure the admin panel.
Swiss weather data for AI assistants — forecasts, measurements, stations, pollen.
Access UK flood warnings, river levels, water quality, Met Office forecasts, and carbon data
Real-time water levels and flow rates from USGS stream gauges
Search 184,900 swim spots, conditions, water activities, providers and guides worldwide.
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/schlpbch/aareguru-mcp'
If you have feedback or need assistance with the MCP directory API, please join our Discord server
