Loading ToolBench
MCP server for accessing Netatmo weather station data via Java/Quarkus, providing tools to fetch current weather, historical data, device information, and administrative diagnostics.
The Netatmo MCP server has 3 tools with varying quality. Tool naming follows verb_noun convention (get_*, all present). However, critical gaps appear in parameter descriptions and schema validation. Tool 1 (get_current_weather) and Tool 2 (get_available_devices) have empty input schemas with no parameters, meaning they accept no user input. Tool 3 (get_historical_weather) has 6 parameters declared but parameters lack proper type definitions beyond basic 'string' declarations. All parameter descriptions exist but are minimal (10-30 chars), leaving ambiguity about valid ranges, formats, and constraints. No output schemas are documented, LLMs cannot infer what fields to expect from these tools, complicating downstream tool chaining. Error handling is not visible in the source excerpt, so recovery guidance is unknown. The server lacks explicit descriptions of what happens on failure, whether calls are retryable, or which errors are user-fixable. Tool descriptions are present (34-194 chars), meeting the minimum bar, but lack clarity on when to use each tool vs. others.
Get list of available Netatmo weather station devices with their IDs, names, types, and supported data types.
Get current weather data from Netatmo weather station including indoor/outdoor temperature, humidity, pressure, CO2, and noise levels.
Get historical weather data from Netatmo weather station for a specified date range. Returns timestamped measurements in JSON format. Data is automatically summarized for large ranges (daily aggregates for >7 days, capped at 24 data points by default).
Get diagnostic information about all weather stations including connectivity status and data freshness.
Force a refresh of the weather station data cache by fetching fresh data from the Netatmo API.
get_current_weather and get_available_devices have empty input schemas ({}). No parameters are declared even though the tool likely accepts optional filters. Empty schemas prevent the LLM from understanding what the tool can do.
get_historical_weather parameters lack proper type constraints beyond 'string'. No enum for 'scale' parameter (should be restricted to: 30min, 1hour, 3hours, 1day, 1week, 1month). No min/max constraints on 'maxDataPoints'. No format validation for date strings (YYYY-MM-DD). Free-form strings invite hallucinated values from LLMs.
No output schemas documented for any tool. LLMs cannot plan downstream calls or extract data without knowing the response structure. This violates pattern:tool which requires documented return types.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | F | 0 | <=2025-11-25 | v2 |
| 2026-03-09 | F | 42 | - | v1 |
Parameter descriptions are too brief (10-30 chars). 'Device ID (optional, uses first available device if not provided)' is the longest. 'Scale' description is ambiguous about which scales are valid or what units they represent. 'Sensor types comma-separated' does not explain the exact expected format or validation rules.
No error handling guidance visible. No recovery hints (e.g., 'If device not found, call get_available_devices() first'). No indication which errors are retryable vs. user-fixable. Pattern:recovery-guide is not implemented.
Tool 3 description mentions 'Returns data in JSON format' but does not specify the JSON structure. This forces LLMs to guess the response shape, increasing token waste and hallucination risk.