Loading ToolBench
The Ecowitt MCP server demonstrates good definition quality with clear tool naming, comprehensive parameter schemas, and detailed descriptions. All 4 tools are properly registered with input schemas and descriptions. Naming follows verb_noun convention (get_*, all action-oriented). Parameters include type definitions and descriptions. However, there are gaps in output schema documentation, error handling guidance, and some parameter descriptions could be more explicit about constraints and formats. The server provides good discovery tools (get_devices) and guides users to call them first, following composition patterns well.
Get the current datetime in ISO 8601 format (UTC).
Get historical measurements for a single Ecowitt device over a time range. Use the `mac` value from `get_devices`. Times must be in the device's timezone and formatted as 'YYYY-MM-DD HH:mm:ss'. If you are unsure about units, omit all unit fields to use the device defaults.
Get current real-time measurements for a single Ecowitt device. Use the `mac` value from `get_devices`. If you are unsure about units, omit all unit fields to use the device defaults.
List all Ecowitt weather station devices. Call this first to discover devices and valid MAC addresses (see `mac` field) to use with the other tools.
Output schemas for tools are not fully documented in the code. While input schemas are explicit via Zod validation, the response structure (what fields get_devices, get_device_realtime_info, get_device_historical_info return) is inferred from handler logic rather than declared in tool registration.
get_device_historical_info's 'callback' parameter description mentions 'comma-separated list' but does not explicitly state the format constraint or provide examples of valid field paths. LLMs would benefit from clearer guidance like: 'Comma-separated field paths, e.g., "outdoor.temp,indoor.humidity,wind.speed"'.
Error handling is absent from tool descriptions. None of the tools document what errors they may return or what the LLM should do if a device is not found, the API times out, or authentication fails. This violates pattern:recovery-guide.
Inferred effective spec: 2025-06-18+.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | C | 63 | 2025-06-18+ | v2 |
| 2026-03-09 | C | 60 | - | v1 |
get_current_datetime has a minimal description ('Get the current datetime in ISO 8601 format (UTC).') that lacks context for when to use it. Per the rubric, descriptions should answer WHAT, WHEN, and WHAT it returns. A better description: 'Get the current UTC time in ISO 8601 format. Use this to construct start/end date parameters for get_device_historical_info or to verify time synchronization.'
MAC address parameter accepts two formats ('AA:BB:CC:DD:EE:FF' or 'AABBCCDDEEFF') but the description does not make it clear whether both are equally valid or if one is preferred. Additionally, 'case-insensitive' should be emphasized more clearly for LLM clarity.