Loading ToolBench
MCP server for the lfpweather-api, providing weather, environmental, and agricultural metrics from a Lake Forest Park station
lfpweather-mcp demonstrates solid tool design with clear naming, comprehensive descriptions, and well-structured schemas. All 8 tools follow verb_noun conventions (query_, list_, get_). Descriptions are detailed (100-300 chars) and explain WHEN to use each tool. Input schemas are complete with types and enums. However, output schemas are not documented in the visible code, and error handling guidance is absent. The server targets a specialized domain (weather/environmental data) with read-only operations, reducing complexity. Tool composition is clean, each tool has one responsibility. Parameter descriptions are thorough, including format hints and enum constraints.
Get the current Zambretti forecast derived from barometric pressure and its trend.
List birds detected acoustically at the station (BirdNET), with a detection count per species over a time range, most-detected first. Answers "what birds have been around", "which birds today/this week". Defaults to the last 24 hours.
Get the current date and time in US Pacific time (America/Los_Angeles, PST/PDT) — the timezone the station reports in. Use it to reason about "now", "today", or "tonight" relative to the data.
Get the year-to-date reference evapotranspiration (ET0, FAO-56 Penman-Monteith) for the station, in millimeters. Answers "how much water have plants lost", "evapotranspiration this year", and irrigation-demand questions.
Get the year-to-date growing degree days (GDD) for the station. Answers "how much growing heat has accumulated", "degree days this season", and crop or pest development questions.
Output schemas not documented. Tool descriptions explain what is returned (e.g., 'time series', 'detection count per species'), but the actual response structure (field names, types, pagination) is not visible in the code. LLMs cannot plan downstream operations without knowing what fields to extract.
No error handling guidance. Tools lack descriptions of failure modes (e.g., 'metric not found', 'invalid time range', 'API timeout'). LLMs cannot self-correct or retry intelligently without knowing what went wrong.
Specialized domain terms (ET0, GDD, Zambretti) lack explanation in tool descriptions. Users unfamiliar with agricultural/meteorological terminology may not understand when to call get_et0 or get_gdd. Descriptions should include brief definitions or use cases.
Inferred effective spec: 2026-07-28+.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-23 | A | 82 | 2026-07-28+ | v2 |
Get the most recent reading for one or more metrics — the current conditions. Answers "what's the temperature/humidity/AQI/CO2 right now", "current battery voltage", or "how much solar power right now". Accepts friendly aliases or table.column references (see list_weather_fields).
List every table, column, and type that query_weather can query, plus the friendly metric aliases. Call this to discover what data exists — for example the exact battery or solar charge-controller columns — before building a query_weather call.
Query a time series for one environment metric from the Lake Forest Park station: weather (temperature, humidity, pressure, wind_speed, wind_gust, rain_rate, solar_radiation, uv_index), air quality (aqi, co2, nox_index, tvoc_index), bird detections (birdnet), battery (litime.*) and solar charge controller (renogychargecontroller.*). Use it for history, trends, averages, minima/maxima, and "over the last week/month/year" questions. Pass a friendly name, or a table.column reference (call list_weather_fields to discover columns). Buckets are chosen automatically to fit the range unless you set one.
query_weather accepts both friendly aliases and table.column references, but the distinction is not clearly separated in the parameter description. LLMs may be confused about which format to use when. Consider splitting into two parameters or clarifying precedence.
No pagination or result-limit documentation. query_weather and list_weather_fields may return large datasets, but there is no mention of limits, pagination tokens, or how to handle large result sets. This risks context window exhaustion.