Loading ToolBench
MCP server bridging LLM tool calls to the local enphase-bridge Rust service
Strong tool definitions with comprehensive descriptions (avg 180+ chars) and well-structured schemas. All 8 tools have explicit input schemas with typed parameters and descriptions. Tool names follow verb_noun convention (get_*, compare_*, refresh_*). Key strengths: detailed parameter descriptions explaining date formats, ranges, and constraints; clear error conditions documented in descriptions. Weaknesses: no output schemas documented in visible code; missing tool annotations (readOnlyHint/destructiveHint); some parameter descriptions could be more concise for LLM parsing efficiency.
Compare two Pacific civil days' energy production and consumption. `date_a` and `date_b` are "today", "yesterday", or "YYYY-MM-DD"; the bridge must have recorded windows for both. `same_time_of_day` (default false) compares an in-progress "today" against a complete day over the same elapsed span from each day's midnight, rather than comparing today's partial figures against a full day's totals.
Compare two Pacific date ranges' energy production and consumption. `start_a`/`end_a` and `start_b`/`end_b` are explicit Pacific dates as "YYYY-MM-DD", inclusive of both ends; each range is capped at 92 days per call. Returns both periods' totals and a side-by-side comparison (produced/consumed kWh differences and percent differences). If either range includes today, today appears in that range's daily breakdown as partial but is excluded from average/best/worst day calculations, so today is never compared against finished days as if it were one.
Get the current solar system status: instantaneous production/consumption/grid power, today's running totals, and whether the bridge is online.
Get aggregated energy totals for one Pacific civil day: produced/consumed/imported/exported/net kWh, self-consumption percentage, peak production power and time, and data completeness. `date` is "today", "yesterday", or "YYYY-MM-DD"; the bridge must have recorded windows for that day.
Output schemas not documented in visible code. LLMs cannot plan downstream tool calls or extract fields without knowing response structure (e.g., what fields does get_period_summary return? Is daily_breakdown an array of objects with what keys?).
Tool annotations (readOnlyHint, destructiveHint, idempotentHint) missing. refresh_tou_schedule is marked WRITE in risk but lacks destructiveHint annotation; read-only tools lack readOnlyHint. Agents cannot distinguish safe-to-retry from irreversible operations without explicit hints.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-23 | A | 84 | 2026-07-28+ | v2 |
Check whether any inverters in the system need attention: offline inverters, inverters with stale data, or inverters producing zero watts when the array is producing. Returns a list of inverters needing attention (empty if all are healthy), each with its serial number, array name, current watts output, online status, and last report timestamp.
Get aggregated energy totals for a range of Pacific civil days, inclusive of both ends. `start_date` and `end_date` are explicit Pacific dates as "YYYY-MM-DD" (no "today"/"yesterday" shorthand); the range is capped at 92 days per call. Returns period totals (produced/consumed/imported/exported/net kWh), self-consumption percentage, average daily production, the single best and worst day by production, a full day-by-day breakdown, and what share of the period's expected 15-minute windows the bridge marked complete. If the range includes today, today appears in the breakdown as a partial, still-in-progress day, but is excluded from average/best/worst day calculations so it is never compared against finished days as if it were one. When no day in the range is both finished and has recorded data, `avg_daily_produced_kwh`, `best_day`, and `worst_day` are null (not 0 or empty).
Estimate the true-up bill for a range of Pacific civil days, by TOU period. `start_date` and `end_date` are explicit Pacific dates as "YYYY-MM-DD", inclusive of both ends, capped at 500 days per call (a full NEM true-up year — 12 months — is fine in one call; the bridge computes this server-side). Returns net cost in USD (NEGATIVE means the utility owes you a credit — see `net_cost_usd`), a per-TOU-period breakdown (peak/off_peak/super_off_peak: imported/exported kWh and their cost/credit in USD), which rate schedule was used, and how many windows in the range were excluded from the estimate because they haven't yet been recomputed onto the currently active formula version (see `excluded_window_count` — a nonzero count means the estimate is based on incomplete/stale data even though it succeeded). Raises an error for invalid or reversed dates, a range over 500 days, a single-day request on the Pacific DST spring-forward date, if no TOU rate schedule has been fetched yet (call `refresh_tou_schedule` first), if the bridge has no energy data anywhere in the range, or if the bridge is unreachable.
Fetch the latest Time-of-Use rate schedule from OpenEI and make it the active one. This tool MUTATES upstream state: enphase-bridge persists the newly fetched schedule as a new row (it does NOT overwrite the previous one — each call appends, and `get_trueup_estimate` always uses the most recently fetched row), so repeated calls are not idempotent and a timed-out call may still have landed upstream. Call it unprompted only for the first-run bootstrap — when `get_trueup_estimate` errors with no schedule configured, refresh once and retry. In every other case (rates changed, schedule looks stale), ask the user for confirmation before calling. Raises an error if OpenEI is unreachable or returns a non-2xx response, if its response can't be parsed, or if the configured rate label isn't present in it.
Error handling descriptions are present but lack recovery guidance. get_trueup_estimate documents 7 error conditions but does not suggest what the agent should do next (e.g., 'if no TOU schedule, call refresh_tou_schedule first'). Agents need actionable next steps, not just error names.
Parameter descriptions for date fields are verbose (e.g., 'Pacific civil day as "today", "yesterday", or "YYYY-MM-DD"' repeated across 4 tools). Consider enum constraints or a shared format definition to reduce token waste and improve clarity.
refresh_tou_schedule description warns about non-idempotency and upstream mutation but does not offer a dry-run or confirmation step. Agents cannot safely preview the effect before committing. Consider adding a 'dry_run' parameter or a separate 'preview_tou_schedule' tool.