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.3/5 across 7 of 7 tools scored.
Each tool targets a distinct aspect of NWS data: stations, forecast, observations, office discussion, zone forecast, alert types, and alert searching. No two tools overlap in purpose, and descriptions clearly differentiate them.
All tools follow the 'nws_[verb]_[noun]' pattern with underscores, using verbs like 'find', 'get', 'list', 'search'. This naming convention is uniform and predictable.
With 7 tools covering core NWS functionalities, the set is well-scoped. Each tool serves a unique purpose, and the count is neither too sparse nor overwhelming.
The tools provide a solid foundation for weather data access: stations, forecasts, observations, text products, zone forecasts, and alerts. Minor gaps like radar or historical data exist, but the core workflow from search to forecast is complete.
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.
| Name | Required | Description | Default |
|---|---|---|---|
| hourly | No | If true, returns hourly forecast (next 48 one-hour 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). | |
| longitude | Yes | Longitude in decimal degrees (e.g., -122.3321). |
Output Schema
| Name | Required | Description |
|---|---|---|
| mode | Yes | Forecast mode: "hourly" or "7-day" |
| notice | No | Set when upstream returned more periods than the cap — states how many periods were omitted. |
| 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 (capped at 48). |
| totalPeriodCount | Yes | Total forecast periods available upstream before the cap was applied. |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate readOnlyHint, which the description aligns with. Adds useful output format details (period types, hourly includes dewpoint/humidity). No contradictions.
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?
Single, concise sentence that front-loads the core action and key options. No redundant or extraneous wording.
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?
Covers main purpose and output modes; output schema exists for detailed return values. Slight gap: could explicitly note geographic constraint (US only) but already stated.
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 reiterates parameter behavior already in the schema (e.g., hourly parameter details) without adding new meaning.
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?
Clear verb 'Get' with specific resource 'weather forecast for a US location'. Distinguishes between two output modes (named 12-hour periods vs hourly breakdowns), differentiating from sibling tools like nws_get_observations.
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?
No explicit when-to-use or when-not-to-use guidance. Does not mention alternatives or prerequisites (e.g., needing a station). Usage is implied but lacks directive context.
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.
| 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 declare readOnlyHint=true, and the description confirms it's a read operation. It adds helpful behavioral context about product types and what each contains, beyond the bare 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?
Two sentences, no wasted words. The first sentence states the main purpose and default, the second provides alternative products and source for office code. Perfectly front-loaded.
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 simplicity (2 params, output schema present), the description covers the main function, defaults, alternative products, and how to obtain the office code. No gaps.
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%, so baseline is 3. The description adds meaning by explaining the default product and the purpose of each product_type enum, supplementing the schema's existing 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 gets the latest narrative forecast product from a WFO, specifies the default AFD product, and lists other product types. It distinguishes from siblings by referencing the office code from nws_get_forecast.
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?
Provides clear context for when to use (get narrative forecast) and explains different product types. Does not explicitly list when not to use or compare directly with siblings, but the description offers enough guidance for selection.
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. | |
| limit | No | Maximum number of alerts to include in the response (1-25, default 25). totalCount still reports the full number of matches, so a small limit returns a digest of broad or national searches without dropping the total. | |
| 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 the requested limit, max 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 limit/cap is applied |
| 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, indicating safe read operation. The description adds behavioral context about mutual exclusivity and the ability to omit filters for a national search, but does not disclose details like result ordering or that only active alerts are returned (implied by 'active'). No contradictions with 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?
Two concise sentences front-load the purpose and key constraints. Every word adds value; no redundancy or filler.
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 9 parameters, output schema existence, and readOnlyHint annotation, the description covers the core functionality and critical restrictions. It lacks guidance on combining filters or handling defaults but is sufficient for a search 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 description coverage is 100% with detailed parameter descriptions (e.g., event partial matching, limit totalCount). The tool description adds minimal extra meaning beyond listing filter categories and reinforcing mutual exclusivity, meeting the baseline for high coverage.
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 with a specific verb-resource combination: 'Search active weather alerts'. It lists key filter dimensions and mentions national search, distinguishing it from sibling tools like nws_get_forecast or nws_list_alert_types.
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 by listing filter options and noting mutual exclusivity of area, point, and zone, but it does not explicitly state when to use this tool versus alternatives (e.g., nws_list_alert_types for discovering event names). No when-not or exclusion criteria are mentioned.
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.