nws-weather-mcp-server

Nws Get Office Discussion

nws_get_office_discussion

Read-only

Get the latest narrative forecast product from a Weather Forecast Office (WFO). The default product is AFD (Area Forecast Discussion), which explains the meteorological reasoning behind the forecast — synoptic setup, model guidance, and forecaster confidence. Other types: HWO (Hazardous Weather Outlook, 1-7 day severe/flood/winter outlook), ZFP (Zone Forecast Product, zone-by-zone text), SPS (Special Weather Statement, short-fuse advisory). The office code is the 3-letter WFO identifier returned as the "office" field by nws_get_forecast.

Input Schema

TableJSON Schema

Name	Required	Description	Default
`office`	Yes	Three-letter Weather Forecast Office (WFO) code (e.g., "SEW" for Seattle, "LOX" for Los Angeles). Returned as the "office" field in nws_get_forecast output.
`product_type`	No	Product type code. AFD (Area Forecast Discussion) — meteorological reasoning, model analysis, forecaster confidence. HWO (Hazardous Weather Outlook) — 1-7 day outlook for severe weather, flooding, winter weather. ZFP (Zone Forecast Product) — detailed zone-by-zone text forecast. SPS (Special Weather Statement) — short-fuse advisory for notable non-warning weather.	AFD

Output Schema

TableJSON Schema

Name	Required	Description
`error`	No	Present when the call failed. Absent on success.
`productCode`	No	Product type code (e.g., "AFD").
`productName`	No	Full product name (e.g., "Area Forecast Discussion").
`productText`	No	Full narrative product text as issued by the forecaster. AFDs are typically 1,000-3,000 words covering synoptic setup, model guidance, and period-by-period reasoning.
`issuanceTime`	No	When the product was issued (ISO 8601), e.g., "2026-05-30T10:33:00+00:00".
`issuingOffice`	No	Issuing office call sign (e.g., "KSEW"). Includes the K/P prefix, unlike the input office code.
`wmoCollectiveId`	No	WMO collective identifier (e.g., "FXUS66"). Identifies the product family in international message routing.

Schema Changelog

Changes observed during successful MCP inspections.

Changed1 schema field changedSep 19, 2026

changedOutput schema / properties / error / properties / data / properties / reason / description

Previous value: -"Machine-readable failure mode. Declared by this tool: `no_products`: Office code is unknown, or a valid office has no current product of the requested type (episodic types like SPS and HWO are commonly empty) Other values are possible when a failure originates below the handler."New value: +"Machine-readable failure mode. Declared by this tool: `no_products`: Office code is unknown, or a valid office has no current product of the requested type (episodic types like SPS and HWO are commonly empty). Other values are possible when a failure originates below the handler."

Changed6 schema fields changedAug 25, 2026

changedInput schema / $schema

Previous value: -"http://json-schema.org/draft-07/schema#"New value: +"https://json-schema.org/draft/2020-12/schema"

addedInput schema / additionalProperties
```
Added value: +false
```

changedOutput schema / $schema

Previous value: -"http://json-schema.org/draft-07/schema#"New value: +"https://json-schema.org/draft/2020-12/schema"

addedOutput schema / anyOf

Added value: +[
+  {
+    "not": {
+      "required": [
+        "error"
+      ]
+    },
+    "required": [
+      "issuanceTime",
+      "issuingOffice",
+      "productCode",
+      "productName",
+      "productText",
+      "wmoCollectiveId"
+    ]
+  },
+  {
+    "required": [
+      "error"
+    ]
+  }
+]

addedOutput schema / properties / error

Added value: +{
+  "additionalProperties": {},
+  "description": "Present when the call failed. Absent on success.",
+  "properties": {
+    "code": {
+      "description": "JSON-RPC error code for this failure.",
+      "maximum": 9007199254740991,
+      "minimum": -9007199254740991,
+      "type": "integer"
+    },
+    "data": {
+      "additionalProperties": {},
+      "properties": {
+        "reason": {
+          "description": "Machine-readable failure mode. Declared by this tool: `no_products`: Office code is unknown, or a valid office has no current product of the requested type (episodic types like SPS and HWO are commonly empty) Other values are possible when a failure originates below the handler.",
+          "examples": [
+            "no_products"
+          ],
+          "type": "string"
+        },
+        "recovery": {
+          "additionalProperties": {},
+          "description": "Actionable next step for the caller.",
+          "properties": {
+            "hint": {
+              "type": "string"
+            }
+          },
+          "required": [
+            "hint"
+          ],
+          "type": "object"
+        },
+        "retryable": {
+          "description": "Whether retrying may succeed.",
+          "type": "boolean"
+        }
+      },
+      "type": "object"
+    },
+    "message": {
+      "description": "Human-readable description of what went wrong.",
+      "type": "string"
+    }
+  },
+  "required": [
+    "code",
+    "message"
+  ],
+  "type": "object"
+}

removedOutput schema / required

Removed value: -[
-  "issuanceTime",
-  "issuingOffice",
-  "productCode",
-  "productName",
-  "productText",
-  "wmoCollectiveId"
-]

AddedMay 30, 2026

TDQS

A4.3/5.0

Behavior4/5

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

The annotations only declare readOnlyHint=true, so the description adds useful behavioral context by defining the default product, the nature of each product type, and that the office code comes from nws_get_forecast. It does not contradict the annotations and gives the agent a clearer sense of what the returned content will represent.

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 two sentences: the first states the core action and default, and the second compactly lists alternative product types with brief explanations. Every sentence earns its place, and the most important information is front-loaded.

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?

For a two-parameter tool with a rich input schema and an output schema, the description is complete. It covers the primary action, default behavior, product-type semantics, and the source of the office code, leaving no meaningful gap for an agent to call the tool correctly.

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

Parameters3/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 fully documents both parameters and the enum values. The description largely repeats this information, though it adds a useful cross-reference tying the office code to nws_get_forecast. This adds marginal context but does not significantly elevate semantics beyond the schema.

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 opens with a specific verb and resource: 'Get the latest narrative forecast product from a Weather Forecast Office (WFO).' It clearly enumerates the product types (AFD, HWO, ZFP, SPS) and explains what each one contains, making the tool's purpose unmistakable and distinct from siblings.

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

Usage Guidelines4/5

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

The description gives clear context for when to use the tool and how to select among product types, explaining the default AFD and the meaning of each alternative. It does not explicitly state when NOT to use this tool versus a sibling like nws_get_zone_forecast, but it provides enough context for an agent to make a reasonable selection.

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

All nws-weather-mcp-server tools Inspect

Try in Browser

One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.