capabilities

Get active US weather alerts for a point or state (NWS)

weather_us_alerts

Read-onlyIdempotent

Active National Weather Service watches, warnings and advisories for a US coordinate or a two-letter state or marine area code - event, severity, certainty, urgency, headline, affected areas and zone codes, and effective/onset/expiry times in UTC. Read at request time, so an empty list means nothing is active. Use when: Decide whether an active US weather warning affects a location before dispatching or travelling. Not for: You need the forecast rather than alerts - use weather.us.forecast. Related: weather_us_forecast; weather_us_observation. Price: USD 0.003/call (x402), 0.002 (account key).

Input Schema

TableJSON Schema

Name	Required	Description	Default
`lat`	No	Latitude in decimal degrees (WGS84). Provide lat and lon together, or provide state.
`lon`	No	Longitude in decimal degrees (WGS84). Provide lat and lon together, or provide state.
`limit`	No	Maximum number of active alerts to return, in the order NWS returns them. The default of 5 keeps the answer compact - a busy state can have dozens of active alerts, each covering tens of zones - and page.total always reports how many are active, so nothing is hidden.
`state`	No	Two-letter US state, territory or NWS marine area code such as CA / TX / PR. Alternative to lat and lon; one of the two forms is required.
`detail`	No	compact (default) returns the fields an agent decides on. full adds the two NWS narrative members - description (the multi-paragraph WHAT/WHERE/WHEN/IMPACTS text, truncated at 2000 characters with description_truncated set) and instruction (the protective-action text) - which are written for a human reader and are several times the size of the rest of the alert.	compact
`offset`	No	Zero-based index of the first alert to return, for paging through the active set with limit. The whole active set is read in one upstream request and returned in that order, so a window over it is consistent.

Output Schema

TableJSON Schema

Name	Required	Description	Default
`data`	Yes	Capability output; full JSON Schema at https://api.eckari.com/v1/capabilities/weather.us.alerts
`meta`	Yes

Schema Changelog

Changes observed during successful MCP inspections. Dates show when Glama detected each change.

Changed3 schema fields changedAug 18, 2026

addedInput schema / properties / detail

Added value: +{
+  "default": "compact",
+  "description": "compact (default) returns the fields an agent decides on. full adds the two NWS narrative members - description (the multi-paragraph WHAT/WHERE/WHEN/IMPACTS text, truncated at 2000 characters with description_truncated set) and instruction (the protective-action text) - which are written for a human reader and are several times the size of the rest of the alert.",
+  "enum": [
+    "compact",
+    "full"
+  ],
+  "type": "string"
+}

changedInput schema / properties / limit / default
```
Previous value: -10New value: +5
```

changedInput schema / properties / limit / description

Previous value: -"Maximum number of active alerts to return, in the order NWS returns them. The default of 10 keeps the answer compact; a busy state can have dozens of active alerts, each with a multi-paragraph narrative. page.total always reports how many are active."New value: +"Maximum number of active alerts to return, in the order NWS returns them. The default of 5 keeps the answer compact - a busy state can have dozens of active alerts, each covering tens of zones - and page.total always reports how many are active, so nothing is hidden."

Changed3 schema fields changedAug 18, 2026

addedInput schema / anyOf

Added value: +[
+  {
+    "required": [
+      "lat",
+      "lon"
+    ]
+  },
+  {
+    "required": [
+      "state"
+    ]
+  }
+]

addedInput schema / properties / limit

Added value: +{
+  "default": 10,
+  "description": "Maximum number of active alerts to return, in the order NWS returns them. The default of 10 keeps the answer compact; a busy state can have dozens of active alerts, each with a multi-paragraph narrative. page.total always reports how many are active.",
+  "maximum": 50,
+  "minimum": 1,
+  "type": "integer"
+}

addedInput schema / properties / offset

Added value: +{
+  "default": 0,
+  "description": "Zero-based index of the first alert to return, for paging through the active set with limit. The whole active set is read in one upstream request and returned in that order, so a window over it is consistent.",
+  "minimum": 0,
+  "type": "integer"
+}

Changed7 schema fields changedAug 18, 2026

removedOutput schema / properties / data / additionalProperties
```
Removed value: -false
```

addedOutput schema / properties / data / description

Added value: +"Capability output; full JSON Schema at https://api.eckari.com/v1/capabilities/weather.us.alerts"

removedOutput schema / properties / data / properties

Removed value: -{
-  "alerts": {
-    "description": "Active alerts in the order returned by NWS.",
-    "items": {
-      "additionalProperties": false,
-      "properties": {
-        "affected_zones": {
-          "description": "NWS zone URLs covered by the alert.",
-          "items": {
-            "type": "string"
-          },
-          "type": "array"
-        },
-        "area_description": {
-          "description": "Human-readable list of affected areas.",
-          "type": [
-            "string",
-            "null"
-          ]
-        },
-        "certainty": {
-          "description": "CAP certainty - Observed / Likely / Possible / Unlikely / Unknown.",
-          "type": [
-            "string",
-            "null"
-          ]
-        },
-        "description": {
-          "description": "Alert narrative, truncated to 2000 characters when description_truncated is true.",
-          "type": [
-            "string",
-            "null"
-          ]
-        },
-        "description_truncated": {
-          "description": "True when the narrative was truncated at 2000 characters.",
-          "type": "boolean"
-        },
-        "effective": {
-          "description": "Time the alert becomes effective.",
-          "type": [
-            "string",
-            "null"
-          ]
-        },
-        "ends": {
-          "description": "Expected end of the hazard.",
-          "type": [
-            "string",
-            "null"
-          ]
-        },
-        "event": {
-          "description": "Event type such as Extreme Heat Warning.",
-          "type": [
-            "string",
-            "null"
-          ]
-        },
-        "expires": {
-          "description": "Time the alert message expires.",
-          "type": [
-            "string",
-            "null"
-          ]
-        },
-        "headline": {
-          "description": "NWS headline for the alert.",
-          "type": [
-            "string",
-            "null"
-          ]
-        },
-        "id": {
-          "description": "NWS alert identifier (CAP urn:oid form).",
-          "type": "string"
-        },
-        "instruction": {
-          "description": "Protective action instruction issued by NWS.",
-          "type": [
-            "string",
-            "null"
-          ]
-        },
-        "message_type": {
-          "description": "CAP message type - Alert / Update / Cancel.",
-          "type": [
-            "string",
-            "null"
-          ]
-        },
-        "onset": {
-          "description": "Expected start of the hazard.",
-          "type": [
-            "string",
-            "null"
-          ]
-        },
-        "sender_name": {
-          "description": "Issuing office such as NWS Las Vegas NV.",
-          "type": [
-            "string",
-            "null"
-          ]
-        },
-        "sent": {
-          "description": "Time the message was sent.",
-          "type": [
-            "string",
-            "null"
-          ]
-        },
-        "severity": {
-          "description": "CAP severity - Extreme / Severe / Moderate / Minor / Unknown.",
-          "type": [
-            "string",
-            "null"
-          ]
-        },
-        "status": {
-          "description": "CAP status such as Actual / Exercise / Test.",
-          "type": [
-            "string",
-            "null"
-          ]
-        },
-        "urgency": {
-          "description": "CAP urgency - Immediate / Expected / Future / Past / Unknown.",
-          "type": [
-            "string",
-            "null"
-          ]
-        }
-      },
-      "required": [
-        "id",
-        "event",
-        "severity",
-        "certainty",
-        "urgency",
-        "status",
-        "message_type",
-        "area_description",
-        "sender_name",
-        "effective",
-        "expires",
-        "description_truncated",
-        "affected_zones"
-      ],
-      "type": "object"
-    },
-    "type": "array"
-  },
-  "count": {
-    "description": "Number of active alerts returned.",
-    "type": "integer"
-  },
-  "query": {
-    "additionalProperties": false,
-    "properties": {
-      "lat": {
-        "description": "Latitude queried, when a point was supplied.",
-        "type": [
-          "number",
-          "null"
-        ]
-      },
-      "lon": {
-        "description": "Longitude queried, when a point was supplied.",
-        "type": [
-          "number",
-          "null"
-        ]
-      },
-      "state": {
-        "description": "Area code queried, when a state was supplied.",
-        "type": [
-          "string",
-          "null"
-        ]
-      }
-    },
-    "required": [
-      "lat",
-      "lon",
-      "state"
-    ],
-    "type": "object"
-  }
-}

removedOutput schema / properties / data / required

Removed value: -[
-  "query",
-  "count",
-  "alerts"
-]

addedOutput schema / properties / meta / properties / attribution_url
```
Added value: +{
+  "format": "uri",
+  "type": "string"
+}
```
addedOutput schema / properties / meta / properties / retrieved_at / format
```
Added value: +"date-time"
```

addedOutput schema / properties / meta / required

Added value: +[
+  "capability",
+  "version",
+  "retrieved_at",
+  "source",
+  "freshness",
+  "request_id"
+]

First observedAug 18, 2026

TDQS

A4.8/5.0

Behavior4/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already declare readOnlyHint=true, openWorldHint=true, idempotentHint=true, and destructiveHint=false, so the safety profile is clear. The description adds value by noting that the result is read at request time ('Read at request time, so an empty list means nothing is active') and describing the limit mechanism with page.total for completeness. However, it could mention that NWS data may have latency or that the tool depends on upstream availability, which is minor.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is a single well-structured paragraph that front-loads the core purpose and input types, then provides usage guidance, alternatives, and pricing. Every sentence adds distinct value, and the text is streamlined with no redundancy.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the tool's complexity (6 parameters, no required ones, an output schema exists, and full annotation support), the description is complete. It covers purpose, input options, alternative tools, behavioral guarantees, and even pricing cost context. The output schema likely handles return value descriptions, so the description need not cover that.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters5/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100%, so the schema already documents all parameters well. The description adds significant meaning beyond the schema: it explains the purpose of limit ('keeps the answer compact...page.total always reports how many are active'), detail's difference ('compact returns the fields an agent decides on; full adds NWS narrative members'), and offset behavior ('the whole active set is read in one upstream request...a window over it is consistent'). This enriches parameter understanding.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description uses specific verbs ('Get active...weather alerts') and identifies the resource ('National Weather Service watches, warnings and advisories') and location inputs ('US coordinate or a two-letter state or marine area code'). It clearly distinguishes from siblings like weather_us_forecast and weather_us_observation listed in the sibling-tools.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines5/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description provides explicit when-to-use guidance ('Decide whether an active US weather warning affects a location before dispatching or travelling'), explicit when-not-to-use ('Not for: You need the forecast rather than alerts'), and names specific alternative tools ('use weather.us.forecast', 'Related: weather_us_forecast; weather_us_observation'). It also mentions pricing to inform cost-aware decisions.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

All capabilities tools Inspect

Try in Browser

RayrunBuild, deploy, and operate MCP servers without becoming an infrastructure team.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

TDQS

A4.4/5.0

Disambiguation4/5

Tools are largely distinct, targeting specific entities (UK company, US company, domain, LEI, FX, location, parcel, weather) or sub-aspects (e.g., accounts vs. charges vs. directors). Overlap exists between company.uk.profile and company.uk.status (both contain status info, but the latter is cheaper and focused). Also, company.uk.filings and company.us.filings_latest could be confused if an agent generalizes 'filings' across jurisdictions.

Naming Consistency5/5

All tools follow a consistent pattern: domain_entity_subject (e.g., company_uk_accounts, domain_expiry, weather_us_alerts). Underscores and lower case are used throughout. Verbs are implied by the noun (e.g., 'search' for lookup, 'detect' for identification). No mixed conventions or unpredictable names.

Tool Count4/5

24 tools is on the high side but still reasonable for a general-purpose data server spanning multiple domains (company, domain, entity, fx, location, parcel, weather). Each domain gets a cohesive set, and the documentation justifies each tool. Could be slightly leaner if some niche tools (e.g., domain_expiry vs. registration) were merged, but overall scoping is acceptable.

Completeness4/5

Each domain offers good coverage: UK company tools cover CRUD-like operations (profile, status, search, filings, charges, directors, owners, registered office); similarly for US companies (profile, filings, resolve, latest filings). Weather has forecast, observation, alerts. Parcel only detects carrier (no tracking). Missing features like advanced filtering on company filings or less common domains, but core workflows are covered.

Resources

Need Help?