Loading ToolBench
MCP server for Swath API — radar-verified hail/wind swaths and property impact reports, in Claude, ChatGPT, or any MCP client.
Swath MCP demonstrates solid tool design with complete schemas, clear descriptions, and proper parameter typing. All 9 tools have explicit Zod schemas with type constraints (enums, min/max bounds). Descriptions are detailed and domain-specific (e.g., 'radar-verified hail/wind storm events', billing model clarity). However, several parameter descriptions lack detail (roof_age_min, roof_material, owner_occupied in get_swath_report/get_report_quote/email_report have null descriptions), and output schemas are not documented. Error handling is present but generic (relies on API error messages). Tool composition is clean, each tool has one responsibility. Naming follows verb_noun convention (find_storms, get_swath_report, lookup_property). No security issues detected (API key injected via env, not parameters).
Watch a coverage area. Get an email at your account address and/or a signed webhook when a radar-verified storm crosses it. Provide email_alerts: true and/or webhook_url (at least one). With webhook_url, the response includes webhook_secret ONCE — store it.
Email a swath report summary (max hail/wind, swath area, county, affected-property count, storm link) to your account email — the address your API key was signed up with; no other recipients possible. Summary bills 1 credit (like get_report_quote); pass limit to also include the top N properties by exposure, billed like get_swath_report (1 credit/property + fresh surcharges, 10-credit minimum).
List radar-verified hail/wind storm events (hail measured by NOAA radar, wind from measured NWS gust and damage reports — never forecasts). Returns storm ids usable with get_swath_report and show_swath_map.
Cost preview for get_swath_report (1 credit): counts cached properties matching the filters without returning rows, plus a clearly-labeled estimate of fresh-fetchable records. Billing always uses actual counts. Use before pulling large reports.
Multiple parameters lack descriptions (roof_age_min, roof_material, owner_occupied, year_built_before, year_built_after, value_min, value_max, min_exposure_score in get_swath_report, get_report_quote, email_report). LLMs cannot infer parameter meaning from names alone.
Output schemas are not documented. LLMs need to know what fields to expect (e.g., what does find_storms return? What fields are in a storm object?). This forces LLMs to guess downstream field names.
Error handling is generic. The api() function throws raw API error messages without recovery guidance. LLMs need actionable next steps (e.g., 'Storm not found. Try find_storms() with a different date range.').
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-23 | D | 59 | 2026-07-28+ | v2 |
★ The Swath Report: every property inside a storm swath, each scored with the hail size measured at that location (exposure.hail_in, exposure.score 0-1). Bills 1 credit per property returned +25/fresh-fetched record (10 min); preview with get_report_quote.
Your API plan, credits used this month, and rate limit.
List your registered coverage monitors.
Full property record for one address (or lat/lng, or parcel id): year built, sqft, roof age and how it was derived, owner-occupancy, assessed value. Costs 2 credits.
A storm swath's polygon as GeoJSON (render it on any map) plus severity stats and a viewer URL.
list_monitors and get_usage have minimal descriptions (60 chars). Descriptions should explain WHEN to call these tools and what they reveal. E.g., 'Call this first to see all active monitors before creating a new one.'
create_monitor accepts optional email_alerts and webhook_url but requires at least one. This dependency is documented in the description but not enforced in the schema. LLMs may pass neither, causing a silent API error.