SHEARLINE provides AI agents with analyst-grade severe weather tools for the continental US (CONUS only), using public data sources with no API keys required. It degrades gracefully on upstream failures and caches results to minimize load.
Active Warnings (get_active_warnings): Retrieve live NWS tornado, severe thunderstorm, and flash flood warning polygons with Impact-Based Warning tags (max hail, wind gusts, tornado detection/damage threat), storm motion, expiration times, point-in-polygon checks, and active watches.
SPC Convective Outlooks (get_spc_outlook): Get Storm Prediction Center categorical risk levels and hazard probabilities (tornado/hail/wind) for days 1–3 at a specific point, with analyst-calibrated interpretation.
Point Environment (get_point_environment): Compute current RAP 13-km parameters — MLCAPE/MUCAPE/CIN, LCL height, wind shear, storm-relative helicity (SRH), Bunkers storm motion, supercell composite (SCP), and significant-tornado parameter (STP) — with analyst-style storm-mode interpretation.
Environment Trend (get_environment_trend): See how the severe weather environment evolves over the next 6 hours (f00/f01/f03/f06 RAP forecast series) with trajectory interpretation (intensifying/stabilizing/steady).
MRMS Radar Products (get_mrms_severe): Sample MRMS data near a point for 60-minute max hail size (MESH), low/mid-level rotation track azimuthal shear, VIL, and composite reflectivity.
Lightning Activity (get_lightning): Query GOES-East GLM total lightning with flash count, rate, nearest strike distance/bearing/time, and tiered outdoor safety interpretation.
Real-Time Storm Reports (get_storm_reports): Retrieve normalized Local Storm Reports (tornado, hail, wind, flood) near a point for the past N hours, with magnitude, time, location, and remarks.
Historical Storm Reports (get_historical_storm_reports): Look up past storm reports for any specific date (back to ~2005) near a CONUS point — useful for insurance, agricultural, and forensic use cases.
Composite Threat Brief (get_threat_brief): Runs all tools concurrently and synthesizes an overall threat level (none/marginal/elevated/significant/extreme) with stated reasoning, ranked hazards, environment summary, nearest storm signature, and recommended attention window.
Radar Snapshot (get_radar_snapshot): Fetch nearest WSR-88D NEXRAD Level 2 volume metadata — VCP scan strategy, max reflectivity with range/azimuth, and coarse echo-top estimate.
Click on "Install Server".
Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state.
In the chat, type @ followed by the MCP server name and your instructions, e.g., "@SHEARLINE threat brief for 39.1,-94.5"
That's it! The server will respond to your query, and you can continue using it as needed.
Here is a step-by-step guide with screenshots.
The severe-weather analyst your agent doesn't have. SHEARLINE is a free, MIT-licensed MCP server that gives AI agents analyst-grade US severe-weather tools: live warning polygons with Impact-Based Warning tags, SPC convective outlooks, RAP-derived point environments and forecast trends (CAPE/shear/SRH/STP computed with MetPy), MRMS radar-derived hail and rotation products, GOES lightning, ground-truth storm reports (real-time and historical), and a composite threat brief that synthesizes all of it. A dozen weather MCPs already wrap the basic forecast API; SHEARLINE deliberately skips everything they do and ships only what requires radar meteorology to expose correctly.
Informational only. Not a substitute for official NWS warnings. Every tool repeats this, because it matters: when weather threatens, follow official warnings from weather.gov and local authorities.
Tool | What it returns |
| Active tornado/severe-thunderstorm/flash-flood warning polygons with IBW tags (max hail size, max gust, tornado detection/damage threat), parsed storm motion, expirations, and whether the exact point is inside a polygon. Watches listed separately. |
| SPC categorical risk (TSTM→HIGH) at the point plus tornado/hail/wind probabilities and significant-severe flags, days 1–3, with interpretation calibrated to the category. |
| Latest RAP 13-km analysis profile computed with MetPy: MLCAPE/MUCAPE/CINs, LCL, 0–1/0–6 km shear, 0–1/0–3 km SRH, Bunkers motion, effective inflow layer, effective SRH/shear, SCP, and significant-tornado parameter — interpreted like an analyst (pulse vs. cool-season high-shear vs. classic supercell parameter space). |
| The anticipatory view: a short RAP forecast series (f00/f01/f03/f06, one consistent cycle) of MLCAPE, 0–6 km shear, 0–1 km SRH, SCP and STP, with an interpretation of the trajectory (intensifying / stabilizing / steady) — for "is this getting worse" rather than "what is it now." |
| MRMS maxima within radius: 60-min MESH (hail, inches and mm), low-level and mid-level rotation tracks (azimuthal shear), VIL, composite reflectivity — each with valid time and distance/bearing of the max. |
| Normalized Local Storm Reports: type, magnitude with units, time, location, distance/bearing, remarks. |
| GOES-East GLM total-lightning activity in the recent window: flash count and rate, nearest strike (distance/bearing/time), and a tiered outdoor-safety interpretation (overhead / within-striking-distance / in-the-area). |
| What hail/wind/tornado hit a point on a specific past date ( |
| The showpiece: runs everything above concurrently and synthesizes a threat level (none/marginal/elevated/significant/extreme) with stated logic, hazards ranked, environment summary, nearest storm signature, and a recommended attention window. |
| Nearest WSR-88D's latest Level 2 volume metadata: VCP (scan strategy), max reflectivity with range/azimuth, coarse echo-top estimate. |
Every tool returns structured JSON with data (numeric fields, units stated), interpretation (plain-language analyst sentences), degraded (which upstream sources failed, if any — partial data instead of errors), the safety disclaimer, and a schema_version — the field contract is semver-stable (see ARCHITECTURE), so integrators can depend on it.
Related MCP server: Weather MCP Server
Real output from 2026-06-10, point inside an active tornado warning in northern Missouri:
{
"threat_level": "extreme",
"threat_logic": [
"Tornado Warning in effect at the point, corroborated by confirmed tornado reports nearby — treat as an immediate life-safety situation.",
"Severe Thunderstorm Warning at the point tagged 'Considerable' (hail to 1.75\", gusts to 60 mph).",
"Significant-tornado parameter of 4.0 with storms ongoing — environment strongly supports tornadic supercells.",
"MRMS MESH of 2.3\" hail within radius in the last hour.",
"Intense rotation track (azimuthal shear 0.013 /s) nearby in the last hour.",
"6 tornado report(s) near the point in the report window."
],
"hazards_ranked": [
{"hazard": "tornado", "level": "extreme"},
{"hazard": "hail", "level": "extreme"},
{"hazard": "damaging_wind", "level": "extreme"},
{"hazard": "flash_flood", "level": "moderate"}
],
"nearest_storm_signature": {
"signature": "composite reflectivity", "value": "58.5 dBZ",
"distance_km": 18.0, "direction": "ENE", "valid_utc": "2026-06-10T22:14Z"
},
"attention_window": {"window": "now", "until_utc": "2026-06-10T21:00:00-05:00"}
}And the same tool for a quiet coastal Maine point reads as confidently quiet — not as an error: "threat_level": "none" with the environment numbers shown so the agent can see why it's quiet.
Requires Python 3.12+ and uv. No API keys — every data source is public and anonymous. uvx downloads and runs the published package in one step; nothing is installed permanently.
Claude Code:
claude mcp add shearline -- uvx shearlineClaude Desktop (claude_desktop_config.json):
{
"mcpServers": {
"shearline": {
"command": "uvx",
"args": ["shearline"]
}
}
}Streamable HTTP (for remote/agent-platform use):
uvx shearline --http --port 8741
# serves at http://127.0.0.1:8741/mcpOn macOS you can also double-click scripts/launch.command to start the HTTP server in a Terminal window (honours SHEARLINE_PORT).
The HTTP transport is built to be hosted: it emits one structured JSON log line
per tool call (tool, coarse 1° lat/lon bucket, latency, degraded list, cache
hit/miss) and applies a per-client token-bucket rate limit, returning 429 with
Retry-After when exceeded. Both are HTTP-only — stdio behaviour is
unchanged. Configure via environment variables:
Env var | Default | Effect |
|
| sustained requests/minute/client ( |
|
| token-bucket capacity (max burst) |
|
| set |
|
| log level for the |
|
| max concurrent upstream fetches (politeness toward NOAA) |
To run the latest unreleased main instead of the PyPI release, swap shearline for --from git+https://github.com/lostnumber07/shearline shearline.
A forecast API tells you it might rain. None of the questions that matter on a severe weather day — is this storm rotating, how big is the hail, is the environment loaded for tornadoes, am I inside the polygon — are answerable from a forecast endpoint. They require the warning's IBW tags, radar-derived products, and a real sounding:
Warnings with IBW tags, not just warning text. A base-tier Severe Thunderstorm Warning and one tagged DESTRUCTIVE with 80 mph gusts are different planning problems. SHEARLINE parses the machine-readable tags (max hail size, max gust, tornado detection/damage threat) and the storm-motion vector, and does the point-in-polygon test for you.
The environment, computed honestly. CAPE without shear is a pulse-storm day; shear without CAPE is wind-driven rain. SHEARLINE pulls the current RAP analysis profile and computes the discriminating quantities with MetPy — including the effective inflow layer, effective SRH/shear, SCP, and STP — because high-CAPE/low-shear, low-CAPE/high-shear, and classic supercell parameter spaces produce very different hazards, and the interpretation says which one you're in.
MRMS, because warnings lag storms. MESH tells you what hail a storm has already produced; rotation tracks show where mesocyclones have tracked in the last hour — both on a ~2-minute cadence from the national radar mosaic, often ahead of the next warning update.
LSRs, because radar isn't ground truth. Spotter reports confirm what's actually reaching the ground — in real time, or for any past date (the insurance / forensic question, "what hit this address that day").
Lightning, because it's the most common outdoor-safety trigger. GOES GLM total lightning, distance-tiered to the 30-30 / 10-mile rules — the signal that actually stops a ballgame, a job site, or a drone flight.
Now and next. The point environment is the analysis now; the forecast trend (f00→f06 from one model cycle) says whether STP/CAPE is rising into the afternoon — the difference between "what is it" and "is it getting worse."
One brief that reasons across all of it. The threat level is rule-based with the triggered rules quoted back, so an agent can audit the logic instead of trusting a vibe.
Warnings: api.weather.gov (NWS)
Outlooks: Storm Prediction Center public GeoJSON
Point environment: NOMADS RAP grib filter, derived with MetPy
Storm reports (real-time and historical): Iowa Environmental Mesonet LSR service
NEXRAD Level 2: Unidata on AWS Open Data
Lightning: GOES GLM on AWS Open Data (GOES-East GLM-L2-LCFA)
Coverage is continental US only — out-of-bounds coordinates are rejected with a clear error. Upstream fetches are cached (warnings 60 s, MRMS/lightning 120 s, LSRs 300 s, outlooks/RAP 30 min, historical reports 6 h) and degrade gracefully: if one source is down, you get partial data plus a degraded field, never a bare exception. A daily canary workflow checks every upstream's response shape and fails on schema drift (renamed fields, moved buckets) before it reaches you.
You don't need to know what an STP is to use SHEARLINE. The .claude/skills/
directory ships three end-to-end recipes that name the exact tool sequence for a
domain task — drop them into any agent that has SHEARLINE connected:
hail-claim-verification — did damaging hail occur at this address on this date? (insurance / forensic)
chase-day-briefing — outlook → environment → trend → warnings → radar, into a go/no-go with a target window (chase / EM)
event-day-lightning-watch — poll lightning proximity and issue suspend/shelter/resume calls by the 30-30 / 10-mile rules (venues / outdoor ops)
SHEARLINE is a thin, layered async server: per-source fetch/parse modules feed a meteorology derivation layer, which feeds a uniform tool layer. Every tool returns the same {data, interpretation, degraded, disclaimer} envelope, every upstream call is TTL-cached, and one failing source degrades to partial data instead of an exception. See ARCHITECTURE.md for the module map, the request lifecycle of get_threat_brief, the concurrency model, and the upstream quirks each source module encodes.
git clone https://github.com/lostnumber07/shearline && cd shearline
uv sync
uv run pytest # offline test suite against recorded fixtures
uv run ruff check .
uv run shearline # stdio
uv run python scripts/smoke.py # live smoke test, both transports
uv run python scripts/canary.py # live upstream drift check (shape-only)See ARCHITECTURE.md for how to add a tool or data source.
MIT © Backshear LLC. Weather data is produced by NOAA/NWS and other public services; this project is not affiliated with or endorsed by NOAA.
Active NWS severe-weather warning polygons near a CONUS point.
Returns tornado / severe thunderstorm / flash flood warnings within
radius_km, each with Impact-Based Warning tags (max hail size, max wind
gust, tornado detection / damage threat), parsed storm motion, expiration
times, polygon geometry, and whether the exact point is inside the
polygon. Watches in effect at the point are listed separately.
| Name | Required | Description | Default |
|---|---|---|---|
| lat | Yes | ||
| lon | Yes | ||
| radius_km | No |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations exist, so the description carries full burden. It transparently discloses the types of warnings, what data is returned (tags, storm motion, expiration, geometry, point-in-polygon check), and that watches are listed separately. However, it omits rate limits, authentication requirements, or any side effects (though likely read-only).
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise: three compact sentences that front-load the core purpose, then list details. Every sentence adds value without redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (multiple warning types, return fields, geometry), no annotations, and 0% schema coverage, the description is fairly complete. It covers what warnings are included, key return fields, and the point-in-polygon check. The output schema likely provides remaining details. Minor gap: no mention of radius_km bounds or CONUS-specific constraints.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0% (no parameter descriptions). The description adds context by mentioning 'CONUS point' for lat/lon and 'within radius_km' for radius_km, but does not specify units, valid ranges, or format. It compensates partially but not fully for the missing schema descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool returns active NWS severe-weather warning polygons near a CONUS point, lists specific warning types (tornado, severe thunderstorm, flash flood), and details the returned data (tags, storm motion, expiration, geometry, point-in-polygon). This distinguishes it from sibling tools by focusing on active warnings vs other severe weather products.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for obtaining active warnings near a location but provides no explicit guidance on when to use this tool versus alternatives like get_mrms_severe or get_threat_brief. No exclusions or context-dependent advice is given.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
RAP forecast-environment trend at a CONUS point (the anticipatory view).
Where get_point_environment is "now" (the f00 analysis), this returns a short
forecast series (f00/f01/f03/f06) of the discriminating quantities — MLCAPE,
0-6 km bulk shear, 0-1 km SRH, supercell composite, significant-tornado
parameter — all from one consistent RAP cycle, with an interpretation of the
TRAJECTORY (intensifying / stabilizing / steady). Downloads and decodes four
forecast hours, so the first call can take ~15-20 seconds.
| Name | Required | Description | Default |
|---|---|---|---|
| lat | Yes | ||
| lon | Yes |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Without annotations, the description fully discloses behavior: it downloads/decodes four forecast hours, notes ~15-20 sec initial call, and explains the trajectory interpretation. This exceeds typical transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise with a clear first sentence stating the core purpose. It includes necessary details without excessive verbosity, though slight restructuring could improve readability.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity and presence of an output schema, the description adequately covers return values (MLCAPE, shear, SRH, etc.) and latency. Missing error handling or authentication details, but overall sufficient.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0% and the description does not elaborate on lat/lon parameters beyond implying a CONUS point. No valid ranges, format, or defaults are given, so the description adds minimal value for parameter usage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool returns a RAP forecast-environment trend for a CONUS point, differentiating it from get_point_environment which is 'now'. It lists specific variables and mentions trajectory interpretation, making the purpose unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description contrasts with get_point_environment, indicating when to use this tool for forecast trends rather than current conditions. However, it does not explicitly mention when not to use it or provide alternatives among the nine sibling tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Local Storm Reports near a CONUS point on a specific PAST date.
Answers "what hail/wind/tornado hit this location on this day." `date` is a
single UTC calendar day formatted 'YYYY-MM-DD'. Returns normalized reports
(type, magnitude with units, time, location, distance/bearing, remarks) plus
a summary. Coverage begins ~2005; the data is preliminary NWS/spotter reports
via the Iowa Environmental Mesonet, not the final NCEI Storm Events record.
For the current situation use get_storm_reports instead.
| Name | Required | Description | Default |
|---|---|---|---|
| lat | Yes | ||
| lon | Yes | ||
| date | Yes | ||
| radius_km | No |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. It discloses data source (preliminary NWS/spotter via Iowa Environmental Mesonet), coverage start (~2005), preliminary nature vs. final NCEI record, and output structure (normalized reports with summary).
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise, front-loaded with purpose, and organized logically: purpose, specifics, output, caveats, alternatives. Every sentence adds value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has an output schema (reducing need to describe returns), the description sufficiently covers usage, parameters, data caveats, and alternatives. It is complete for agent decision-making.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, but description adds meaning for date format (YYYY-MM-DD) and output structure related to parameters. However, it does not explain lat/lon format or radius_km semantics beyond default, leaving some gaps.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it retrieves local storm reports for a past date near a CONUS point, specifying it answers about hail, wind, or tornado. It distinguishes from the sibling tool get_storm_reports, which is for current situations.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly provides when to use (past dates) and when not to (current situation), directing to the alternative get_storm_reports. This is clear guidance for agent selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
GOES GLM total-lightning activity near a CONUS point in the recent window.
Returns the flash count and rate within radius_km over the last `minutes`,
the nearest strike (distance/bearing/time), and a tiered outdoor-safety
interpretation (overhead / within-striking-distance / in-the-area). GLM
detects total lightning — both in-cloud and cloud-to-ground — from the
GOES-East satellite, with ~20-40 s latency.
| Name | Required | Description | Default |
|---|---|---|---|
| lat | Yes | ||
| lon | Yes | ||
| radius_km | No | ||
| minutes | No |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description discloses that GLM detects total lightning from GOES-East with 20-40 s latency, and it explains the output composition. Without annotations, this provides reasonable transparency, though it could detail data freshness limitations or edge cases.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is mostly concise, with two sentences that front-load the purpose. The first sentence is somewhat long but packs necessary information. Minor redundancy could be trimmed.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the presence of an output schema (not shown), the description adequately covers the tool's functionality: output fields, source, latency. It provides enough context for an AI agent to use the tool correctly, though parameter details are sparse.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema description coverage, the description must add meaning. It mentions 'radius_km' and 'minutes' as time window parameters but does not clarify lat/lon or provide format details. The default values are in schema but not explained in description.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool retrieves GOES GLM total-lightning activity near a CONUS point, listing specific output fields such as flash count, rate, nearest strike, and a tiered safety interpretation. It is distinct from sibling tools, which focus on other weather phenomena.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies real-time use with 'recent window' but does not explicitly state when to use this tool versus alternatives like get_threat_brief. No exclusion criteria or context for selection are provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
MRMS radar-derived severe weather products near a CONUS point.
Samples within radius_km: max 60-minute MESH (hail size, inches and mm),
max low-level and mid-level rotation-track azimuthal shear over the last
hour, max VIL, and max composite reflectivity — each with valid time and
the distance/bearing of the maximum from the point.
| Name | Required | Description | Default |
|---|---|---|---|
| lat | Yes | ||
| lon | Yes | ||
| radius_km | No |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Without annotations, the description effectively discloses key behaviors: it samples within radius_km, returns max values over the last hour, and includes valid time and distance/bearing. However, it omits details like authentication needs or whether data is cached, though the core behavior is well-communicated.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is exceptionally concise, consisting of two dense sentences that front-load the core purpose and then list specific products with details. Every word adds value without redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (multiple severe weather products), the description thoroughly lists what is returned (MESH, shear, VIL, reflectivity) with units and time windows. The presence of an output schema means return format details are covered externally, making this description complete for tool selection.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Despite 0% schema description coverage, the main description adds meaning by stating the tool retrieves data 'near a CONUS point' and uses radius_km for sampling. This clarifies that lat/lon define the center point. However, it does not specify constraints like valid ranges for lat/lon or radius_km, leaving some ambiguity.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool returns MRMS radar-derived severe weather products near a CONUS point, listing specific products (MESH, shear, VIL, reflectivity). This distinctively differentiates it from siblings like get_active_warnings or get_radar_snapshot, which cover different data. The verb 'get' is implied, and the resource is well-defined.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for obtaining severe weather parameters at a point but provides no explicit guidance on when to use this tool versus siblings. It does not mention prerequisites, exclusions, or alternatives, leaving the agent to infer from context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
RAP-analysis severe-weather environment at a CONUS point.
Downloads the latest RAP 13-km analysis profile and computes, with MetPy:
MLCAPE/MUCAPE/SBCAPE and CINs, LCL height, 0-1 and 0-6 km bulk shear,
0-1 and 0-3 km storm-relative helicity, Bunkers storm motion, effective
inflow layer, effective SRH/shear, supercell composite (SCP) and
significant-tornado parameter (STP). Interpretation reasons through the
parameter space like an analyst. First call may take several seconds.
| Name | Required | Description | Default |
|---|---|---|---|
| lat | Yes | ||
| lon | Yes |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, yet the description discloses important behavioral details: it downloads the latest RAP data, uses MetPy for computation, and notes that the first call may take several seconds. This compensates well for the lack of annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single paragraph that efficiently conveys the tool's purpose and output. It is appropriately sized, though could be broken into separate sentences for readability. No extraneous text is present.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (computing many parameters) and the presence of an output schema, the description thoroughly lists all computed quantities and mentions interpretation behavior. This fully informs an agent of what to expect without needing to inspect the output schema.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has two required parameters (lat, lon) with 0% schema description coverage. The description does not explain their meaning, format, or valid ranges. As a basic geographic coordinate, the purpose is obvious, but the description adds no semantic value beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool computes severe-weather environment parameters from RAP analysis at a CONUS point, listing many specific outputs (MLCAPE, shear, etc.). It distinguishes from sibling tools like get_active_warnings or get_radar_snapshot by focusing on atmospheric profile analysis.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies use for severe weather analysis but does not explicitly state when to use this tool versus alternatives like get_spc_outlook. No guidance on prerequisites or when not to use is given.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Latest NEXRAD Level 2 volume metadata from the nearest WSR-88D radar.
Metadata only (no imagery): radar site and distance, volume scan start
time, VCP (scan strategy) with meaning, max reflectivity and its
range/azimuth, and a coarse 18-dBZ echo-top estimate. Downloads a full
Level 2 volume (~5-15 MB), so expect a few seconds on first call.
| Name | Required | Description | Default |
|---|---|---|---|
| lat | Yes | ||
| lon | Yes |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It transparently discloses the download size (~5-15 MB) and expected delay on first call, along with the specific metadata fields returned. It does not mention error cases or permissions, but for a read-only metadata tool these are less critical.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences, front-loaded with the main purpose, and efficiently provides details on what is returned and a performance note. No redundant words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the presence of an output schema, the return values are covered. The description adequately explains the tool's scope, data included, and a performance caveat. It does not address potential errors like missing radar coverage, but overall is sufficiently complete for a simple metadata retrieval tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has two required parameters (lat, lon) with 0% description coverage. The description does not explain these parameters further, but they are standard coordinates and their purpose is clear from context. Minimal added value beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool retrieves the latest NEXRAD Level 2 volume metadata from the nearest radar, specifying it is metadata only and listing the data fields. It distinguishes from sibling tools like get_active_warnings or get_mrms_severe by focusing on radar metadata.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description informs that the tool returns metadata only (no imagery) and mentions the download size and time cost. This indirectly guides users to not use it if they need imagery, but lacks explicit comparison to alternative tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
SPC convective outlook at a CONUS point for day 1, 2, or 3.
Returns the categorical risk (TSTM/MRGL/SLGT/ENH/MDT/HIGH) plus hazard probabilities (tornado/hail/wind for days 1-2; total severe for day 3) and significant-severe flags, with an interpretation calibrated to the category.
| Name | Required | Description | Default |
|---|---|---|---|
| lat | Yes | ||
| lon | Yes | ||
| day | No |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the burden. It describes the return data (categorical risk, probabilities, flags) but does not disclose behavioral traits like idempotency, auth needs, or rate limits.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, front-loaded with purpose, no redundant information. Every part adds value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has an output schema, the description covers the return fields adequately. However, it lacks parameter details, which is a minor gap.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, and the description only mentions 'day 1, 2, or 3' without explaining lat/lon format, range, or the day parameter's default and allowed values.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool returns SPC convective outlook at a CONUS point for days 1-3, specifying categorical risk, hazard probabilities, and flags. It distinguishes from sibling tools like get_active_warnings and get_radar_snapshot by focusing on forecast outlooks.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for obtaining outlook data but does not explicitly state when to use this tool versus alternatives, nor does it provide when-not-to-use guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Local Storm Reports (spotter/official reports) near a CONUS point.
Normalized tornado, hail, wind, and flood reports within radius_km over
the past N hours: type, magnitude with units, time, location,
distance/bearing from the point, and remarks.
| Name | Required | Description | Default |
|---|---|---|---|
| lat | Yes | ||
| lon | Yes | ||
| radius_km | No | ||
| hours | No |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden. It discloses that reports are 'local' (spotter/official) and 'normalized', with temporal (past N hours) and spatial (radius_km) scope. However, it does not mention data limitations (e.g., only CONUS, potential latency, or that reports may be sparse). Adequate but not exhaustive.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences, front-loaded with the tool's purpose and key constraints. Every word is informative; no fluff or redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the presence of an output schema, the description need not fully detail return values, but it already lists key output fields. However, it omits details on result ordering, maximum results, or handling of empty responses. For a tool returning many reports, this could hamper effective use.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, so description must explain parameters. It mentions 'within radius_km' and 'over the past N hours', which map to radius_km and hours parameters, but does not clarify lat/lon format, units (expected decimal degrees), valid ranges, or the default values. The description adds some value but is insufficient for comprehensive parameter understanding.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool retrieves 'Local Storm Reports' (spotter/official reports) near a CONUS point, with specific types (tornado, hail, wind, flood). It distinguishes from sibling tools like get_active_warnings and get_radar_snapshot by focusing on historical reports rather than warnings or radar data.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for obtaining storm reports in an area, but lacks explicit guidance on when to use this tool versus siblings, such as when to prefer get_mrms_severe or get_active_warnings. No when-not-to-use or prerequisites are stated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Composite severe-weather threat brief for a CONUS point.
Runs warnings, SPC outlook, RAP environment, MRMS products, and storm
reports concurrently, then synthesizes: an overall threat level
(none/marginal/elevated/significant/extreme) with stated logic, hazards
ranked by concern, an environment summary, the nearest current storm
signature, and a recommended attention window. The first call can take
~10 seconds while the RAP profile downloads.
| Name | Required | Description | Default |
|---|---|---|---|
| lat | Yes | ||
| lon | Yes |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden. It discloses that the tool runs multiple products concurrently, that the first call may take ~10 seconds due to RAP profile download, and describes the output structure. This provides good transparency about behavior and performance.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a concise, well-structured paragraph of four sentences. The first sentence captures the primary purpose, and each subsequent sentence adds necessary detail without redundancy. No fluff.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (composite of multiple data sources) and minimal schema, the description provides a good overview of the output. It mentions all key output components and notes the latency behavior. The presence of an output schema reduces the need for detailed return value explanations. Minor gaps in error or boundary handling, but still adequate.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 0% description coverage, so the description must compensate. It adds context that lat/lon are for a CONUS point and are used as the location for the brief. This provides basic meaning beyond the schema but lacks details like coordinate bounds or format expectations.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: it is a 'Composite severe-weather threat brief for a CONUS point' that runs multiple data sources concurrently and synthesizes them. It distinguishes itself from sibling tools like get_active_warnings by being a composite rather than a single source.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies the tool should be used for a comprehensive threat overview, but it does not explicitly contrast it with individual sibling tools or state when to use one over the other. Some guidance on use cases or when not to use it would improve clarity.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections. Dates show when Glama detected each change.
v1.1.0get_environment_trendget_historical_storm_reportsget_lightningv1.0.0get_active_warningsget_mrms_severeget_point_environmentget_radar_snapshotget_spc_outlookget_storm_reportsget_threat_briefEach tool has a distinct purpose: warnings, radar products, environment, radar metadata, outlook, reports, and a composite brief. There is no overlap, and an agent can clearly differentiate them.
All tools follow a consistent 'get_' prefix with snake_case noun phrases (e.g., get_active_warnings, get_mrms_severe). No mixing of styles or irregular verbs.
Seven tools is well-suited for a severe weather analysis server, covering warnings, radar, environment, outlook, reports, and a composite without being too few or excessive.
The tool set covers the primary data sources for severe weather threat assessment. Minor gaps like radar imagery or satellite data exist, but the composite tool integrates the available tools effectively.
Unclaimed servers have limited discoverability.
If you are the server author, to access and configure the admin panel.
Hosted MCP server for Xweather weather data: conditions, forecasts, alerts, and more.
Hosted MCP server for live public-data APIs and Skills for AI agents.
MCP server for weather with reasoning — umbrella advice, outdoor checks, city comparisons.
Real-time planetary signal engine and Model Context Protocol (MCP) server for autonomous AI agents.
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/lostnumber07/shearline'
If you have feedback or need assistance with the MCP directory API, please join our Discord server