nws-weather-mcp-server
Server Details
Get US weather forecasts, active alerts, and current observations.
- Status
- Healthy
- Last Tested
- Transport
- Streamable HTTP
- URL
- Repository
- cyanheads/nws-weather-mcp-server
- GitHub Stars
- 1
- Server Listing
- @cyanheads/nws-weather-mcp-server
Glama MCP Gateway
Connect through Glama MCP Gateway for full control over tool access and complete visibility into every call.
Full call logging
Every tool call is logged with complete inputs and outputs, so you can debug issues and audit what your agents are doing.
Tool access control
Enable or disable individual tools per connector, so you decide what your agents can and cannot do.
Managed credentials
Glama handles OAuth flows, token storage, and automatic rotation, so credentials never expire on your clients.
Usage analytics
See which tools your agents call, how often, and when, so you can understand usage patterns and catch anomalies.
Tool Definition Quality
Average 4.6/5 across 7 of 7 tools scored.
Each tool targets a distinct NWS resource: stations, forecasts, observations, office discussions, zone forecasts, alert types, and alerts. No functional overlap.
All tools follow a consistent 'nws_verb_noun' pattern with lowercase underscores, e.g., nws_get_forecast, nws_list_alert_types. Predictable and uniform.
7 tools provide a well-scoped set for accessing NWS weather data—covering forecasts, observations, alerts, and narrative products—without being excessive or sparse.
The tool surface covers key NWS functionalities: station discovery, forecasts (period and zone), observations, narrative discussion, and alert search. No obvious gaps for typical weather data retrieval.
Available Tools
7 toolsnws_find_stationsNws Find StationsARead-onlyInspect
Find weather observation stations near a location. Returns stations sorted by proximity with distance and bearing. Use to discover station IDs for nws_get_observations.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | Max stations to return (1-50). | |
| latitude | Yes | Center latitude for proximity search. | |
| longitude | Yes | Center longitude for proximity search. |
Output Schema
| Name | Required | Description |
|---|---|---|
| notice | No | Guidance when no stations were found near the requested coordinates. |
| stations | Yes | Nearby stations sorted by distance |
| totalCount | Yes | Number of stations returned (respects the limit parameter) |
| totalFound | Yes | Total observation stations available near this location before the limit was applied |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, and the description adds behavioral details about sorting by proximity and including distance and bearing, which is consistent and informative.
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, both essential. First sentence states purpose and key behavior. Second sentence gives usage guidance. 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?
With complete parameter documentation, an output schema, and clear usage context, the description provides all necessary information without needing to explain return values.
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 100%, so baseline is 3. The description adds value by explaining the overall purpose of the parameters (finding stations near a location) and the sorting behavior, which is not in 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 action 'Find' and the resource 'weather observation stations,' and explicitly connects it to discovering station IDs for nws_get_observations. It distinguishes well from sibling tools that handle forecasts, observations, alerts, etc.
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 tells the agent to use this tool to discover station IDs for nws_get_observations, providing clear context. It does not explicitly list when not to use it or name alternatives, but the sibling tools are distinct, making usage straightforward.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
nws_get_forecastNws Get ForecastARead-onlyInspect
Get the weather forecast for a US location. Returns either named 12-hour periods (default) or hourly breakdowns. Internally resolves coordinates to the NWS grid.
| Name | Required | Description | Default |
|---|---|---|---|
| hourly | No | If true, returns hourly forecast (~156 periods) instead of 12-hour named periods (14 periods). Hourly includes dewpoint and relative humidity. | |
| latitude | Yes | Latitude in decimal degrees (e.g., 47.6062). Truncated to 4 decimal places. | |
| longitude | Yes | Longitude in decimal degrees (e.g., -122.3321). Truncated to 4 decimal places. |
Output Schema
| Name | Required | Description |
|---|---|---|
| mode | Yes | Forecast mode: "hourly" or "7-day" |
| periods | Yes | Forecast periods |
| location | Yes | Resolved location metadata |
| generatedAt | Yes | When the forecast was generated (ISO 8601) |
| periodCount | Yes | Number of forecast periods returned |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description adds significant behavioral context beyond the annotations, including internal coordinate resolution, two output types with period counts, and extra fields for hourly. The readOnlyHint annotation already conveys safety, and the description enriches without contradiction.
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?
Three sentences, front-loaded with the main purpose. Each sentence contributes unique information (purpose, output options, internal step). No 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 does not need to detail return values. It covers when to choose hourly vs default, the internal resolution step, and the US location scope, making it complete for selection and invocation.
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 100% with parameter descriptions. The description adds value by clarifying default vs hourly output, period counts (14 vs ~156), and that hourly includes dewpoint and humidity. This meaningfully extends 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 gets a weather forecast for a US location, distinguishing it from sibling tools like observations or zone forecasts. It specifies two output formats (12-hour periods or hourly) and mentions internal coordinate resolution.
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?
Usage is implied: to get a forecast for a US location. However, there is no explicit guidance on when not to use this tool versus alternatives like nws_get_observations or nws_get_zone_forecast. Sibling names suggest alternatives, but the description does not direct the agent away from them.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
nws_get_observationsNws Get ObservationsARead-onlyInspect
Get current weather observations (actual measured conditions). Accepts coordinates (resolves nearest station automatically) or a station ID directly (e.g., "KSEA").
| Name | Required | Description | Default |
|---|---|---|---|
| latitude | No | Latitude for automatic station resolution. Use with longitude. Ignored if station_id is provided. | |
| longitude | No | Longitude for automatic station resolution. Use with latitude. Ignored if station_id is provided. | |
| station_id | No | Station identifier directly (e.g., "KSEA", "KORD"). Use nws_find_stations to discover station IDs. |
Output Schema
| Name | Required | Description |
|---|---|---|
| notice | No | Guidance when the latest observation is more than 2 hours old — data may not reflect current conditions. |
| station | Yes | Station ID that served the observation (e.g., "KSEA") |
| timeZone | Yes | Station time zone when known |
| dewpointC | Yes | Dewpoint in Celsius |
| stationId | Yes | Observation station ID |
| timestamp | Yes | Observation time (ISO 8601) |
| heatIndexC | Yes | Heat index in Celsius |
| observedAt | Yes | Observation timestamp (ISO 8601) |
| windChillC | Yes | Wind chill in Celsius |
| cloudLayers | Yes | Cloud layer information |
| stationName | Yes | Station name |
| visibilityM | Yes | Visibility in meters |
| windGustKmh | Yes | Wind gust in km/h |
| temperatureC | Yes | Temperature in Celsius |
| windSpeedKmh | Yes | Wind speed in km/h |
| textDescription | Yes | Conditions summary (e.g., "Mostly Cloudy") |
| windDirectionDeg | Yes | Wind direction in degrees (0-360) |
| relativeHumidityPct | Yes | Relative humidity in percent (0-100) |
| barometricPressurePa | Yes | Barometric pressure in Pascals |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, so the description carries a lower burden. It adds behavioral context such as automatic station resolution from coordinates and the override behavior when station_id is provided. This goes beyond the static annotation.
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 extremely concise—two sentences with no extraneous words. It front-loads the core purpose and immediately follows with actionable usage details. Every sentence contributes meaningful information.
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 and the tool's straightforward nature (3 optional parameters), the description covers essential usage contexts: both location methods and how they interact. It does not specify default behavior when no parameters are provided, but the overall completeness is high.
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 100% schema description coverage, the baseline is 3. The description adds practical meaning: explains auto-resolution for coordinates, provides an example station ID, and directs users to a sibling tool for discovery. This enriches understanding beyond the schema alone.
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 current weather observations, distinguishing it from forecasts. It specifies the verb 'Get' and resource 'current weather observations' and provides explicit details on location specification methods.
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 explains when to use coordinates versus a station ID, and references nws_find_stations for discovering station IDs. It lacks explicit when-not-to-use guidance but effectively differentiates from sibling tools like nws_get_forecast.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
nws_get_office_discussionNws Get Office DiscussionARead-onlyInspect
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. Fetches the two-hop products API: list endpoint first (newest product), then the full product detail.
| 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
| Name | Required | Description |
|---|---|---|
| productCode | Yes | Product type code (e.g., "AFD"). |
| productName | Yes | Full product name (e.g., "Area Forecast Discussion"). |
| productText | Yes | 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 | Yes | When the product was issued (ISO 8601), e.g., "2026-05-30T10:33:00+00:00". |
| issuingOffice | Yes | Issuing office call sign (e.g., "KSEW"). Includes the K/P prefix, unlike the input office code. |
| wmoCollectiveId | Yes | WMO collective identifier (e.g., "FXUS66"). Identifies the product family in international message routing. |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate readOnlyHint=true, and the description adds that the tool performs a two-hop API call (list then detail), which discloses internal behavior beyond the annotation. No contradiction.
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 well-structured paragraph with front-loaded purpose, followed by supplementary details on product types, office source, and method. 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 two-parameter input and the existence of an output schema, the description fully covers the tool's behavior, workflow, and variations, making it complete for an AI agent.
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 100%, and the description adds meaning by explaining that office comes from nws_get_forecast output and detailing each product type's purpose, enriching the parameter definitions.
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 gets the latest narrative forecast product from a WFO, specifies the default AFD product, and lists other types. It distinguishes from sibling tools like nws_get_forecast by emphasizing the narrative reasoning aspect.
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?
It explains when to use this tool (to get narrative products) and describes the product types, but does not explicitly state when not to use it or provide alternatives to the default AFD. However, it does mention the office code source.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
nws_get_zone_forecastNws Get Zone ForecastARead-onlyInspect
Get the text forecast for a public NWS forecast zone. Returns named forecast periods (e.g., "Today", "Tonight", "Monday") with detailed narrative text — the human-readable, zone-level forecast written by local forecasters. Completes the alert-to-forecast chain: nws_search_alerts returns zone codes in "affectedZones", and nws_find_stations returns them in the "forecastZone" column; use those codes here. Zone codes follow the pattern XXZ### (e.g., "WAZ315" for Western Washington lowlands). County zone codes (XXC###) are not supported — use the forecast zone code.
| Name | Required | Description | Default |
|---|---|---|---|
| zone_id | Yes | NWS public forecast zone code (e.g., "WAZ315" for the Western Washington lowlands including Seattle). Returned as "forecastZone" by nws_get_forecast and nws_find_stations, or in "affectedZones" by nws_search_alerts. Format: two-letter state + "Z" + three-digit number. |
Output Schema
| Name | Required | Description |
|---|---|---|
| zoneId | Yes | Zone ID as provided (e.g., "WAZ315"). |
| periods | Yes | Forecast periods in chronological order, typically covering 7 days. |
| updated | Yes | When the zone forecast was last updated (ISO 8601 with timezone offset). |
| periodCount | Yes | Number of forecast periods returned. |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, so the read-only behavior is clear. The description adds context about the return format (narrative text) and the zone code pattern, enhancing understanding beyond 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 concise with 6 sentences, front-loading purpose. Could be slightly more structured (e.g., bullet points), but no waste.
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?
With output schema present, no need to detail return format, but description does mention named periods and narrative text. Explains input format and context. Complete for a simple single-parameter 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?
Schema coverage is 100%, baseline 3. The description adds meaning by explaining the zone code pattern, the source of codes (from sibling tools), and the exclusion of county codes, which goes beyond the schema definition.
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 a text forecast for a public NWS forecast zone, with specific details on output (named periods, narrative text). It distinguishes from siblings by referencing the alert-to-forecast chain and specifying zone code usage.
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 explains when to use this tool: completing the chain from nws_search_alerts and nws_find_stations. Also provides a clear exclusion: county zone codes (XXC###) are not supported, guiding the agent to use forecast zone codes.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
nws_list_alert_typesNws List Alert TypesARead-onlyInspect
List all valid NWS alert event type names. Use to discover valid values for the event filter in nws_search_alerts, or to browse alert categories. No parameters required.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Output Schema
| Name | Required | Description |
|---|---|---|
| count | Yes | Number of event types |
| eventTypes | Yes | Alert event type names sorted alphabetically |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description adds context beyond annotations: it specifies the tool's purpose for discovery/browsing and its relationship to another tool. Annotations already declare readOnlyHint=true, so the description doesn't need to repeat safety aspects. However, it doesn't detail behavioral traits like rate limits or response format, though output schema exists.
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 front-loaded with the core purpose in the first sentence, followed by usage guidelines and parameter info. Every sentence earns its place with no wasted words, making it highly efficient and well-structured.
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 low complexity (0 parameters, read-only, with output schema), the description is complete. It covers purpose, usage, and parameter requirements adequately, and the output schema handles return values, so no gaps exist for this simple 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?
With 0 parameters and 100% schema description coverage, the baseline is high. The description compensates by explicitly stating 'No parameters required,' which adds clarity beyond the empty schema. No parameters to document, so it effectively addresses the lack of input needs.
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 specific action ('List all valid NWS alert event type names'), identifies the resource ('NWS alert event types'), and distinguishes it from siblings by mentioning its relationship to 'nws_search_alerts' for filtering. It avoids tautology by explaining functionality beyond the name/title.
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 explicitly states when to use this tool ('Use to discover valid values for the event filter in nws_search_alerts, or to browse alert categories') and provides an alternative context ('browse alert categories'). It also clarifies 'No parameters required,' indicating simplicity compared to parameter-heavy siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
nws_search_alertsNws Search AlertsARead-onlyInspect
Search active weather alerts (watches, warnings, advisories) across the US. Filter by state, coordinates, zone, event type, severity, urgency, or certainty. area, point, and zone are mutually exclusive. Omit all filters for a national search.
| Name | Required | Description | Default |
|---|---|---|---|
| area | No | US state/territory code (e.g., "WA", "OK", "PR") or marine area code (e.g., "GM"). Mutually exclusive with point and zone. | |
| zone | No | NWS forecast zone (e.g., "WAZ558") or county zone (e.g., "WAC033"). Mutually exclusive with area and point. | |
| event | No | Filter to specific event types (e.g., ["Tornado Warning"]). Matches are case-insensitive and partial, so "tornado" matches both "Tornado Warning" and "Tornado Watch". Use nws_list_alert_types to discover valid names. | |
| point | No | Coordinates as "lat,lon" (e.g., "47.6,-122.3"). Returns alerts whose geometry contains this point. Mutually exclusive with area and zone. | |
| status | No | Alert status filter. Default "Actual". Use a different value only when you specifically need non-live alerts. | Actual |
| urgency | No | Filter by urgency level. | |
| severity | No | Filter by severity level. | |
| certainty | No | Filter by certainty level. |
Output Schema
| Name | Required | Description |
|---|---|---|
| alerts | Yes | Matching alerts (capped at 25) |
| notice | No | Guidance when no alerts matched — echoes applied filters and suggests how to broaden the search. |
| shownCount | Yes | Number of alerts included in this response |
| totalCount | Yes | Total number of matching alerts before the 25-alert cap |
| appliedFilters | Yes | Summary of applied search filters |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, and the description confirms read-only search. It adds behavioral details like mutual exclusivity of area/point/zone, partial matching on event, and default status. No contradictions. Could mention pagination or rate limits, but overall strong.
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 four short sentences, front-loaded with the action ('Search active weather alerts'), and every sentence adds essential information. 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 8 parameters, 0 required, 100% schema coverage, and an output schema, the description is very complete. It covers filtering options, constraints, and national search. The only minor omission is pagination, but output schema likely covers that.
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 100%, but the description adds significant value: it clarifies mutual exclusivity, explains partial case-insensitive matching for event, gives default for status, and directs to nws_list_alert_types for valid names. This goes 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 verb 'Search', the resource 'active weather alerts', and scopes it to 'across the US' with a national option. It distinguishes from sibling tools like nws_get_forecast which are about different functions.
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 tells when to use (searching alerts) and provides mutual exclusivity rules for filters. It also mentions nws_list_alert_types for valid event names. However, it does not explicitly state when not to use or list alternatives, though sibling tools are different.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Claim this connector by publishing a /.well-known/glama.json file on your server's domain with the following structure:
{
"$schema": "https://glama.ai/mcp/schemas/connector.json",
"maintainers": [{ "email": "your-email@example.com" }]
}The email address must match the email associated with your Glama account. Once published, Glama will automatically detect and verify the file within a few minutes.
Control your server's listing on Glama, including description and metadata
Access analytics and receive server usage reports
Get monitoring and health status updates for your server
Feature your server to boost visibility and reach more users
For users:
Full audit trail – every tool call is logged with inputs and outputs for compliance and debugging
Granular tool control – enable or disable individual tools per connector to limit what your AI agents can do
Centralized credential management – store and rotate API keys and OAuth tokens in one place
Change alerts – get notified when a connector changes its schema, adds or removes tools, or updates tool definitions, so nothing breaks silently
For server owners:
Proven adoption – public usage metrics on your listing show real-world traction and build trust with prospective users
Tool-level analytics – see which tools are being used most, helping you prioritize development and documentation
Direct user feedback – users can report issues and suggest improvements through the listing, giving you a channel you would not have otherwise
The connector status is unhealthy when Glama is unable to successfully connect to the server. This can happen for several reasons:
The server is experiencing an outage
The URL of the server is wrong
Credentials required to access the server are missing or invalid
If you are the owner of this MCP connector and would like to make modifications to the listing, including providing test credentials for accessing the server, please contact support@glama.ai.
Discussions
No comments yet. Be the first to start the discussion!
Your Connectors
Sign in to create a connector for this server.