noaa-spaceweather-mcp-server
Server Details
NOAA SWPC space weather: storm scales, Kp index, aurora forecasts, solar wind, activity, alerts.
- Status
- Healthy
- Last Tested
- Transport
- Streamable HTTP
- URL
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.4/5 across 6 of 6 tools scored.
Each tool targets a distinct aspect of space weather: alerts, aurora forecast, current conditions, Kp index details, solar activity, and solar wind. Even the conditions tool (which includes Kp) is described as a snapshot, while the Kp index tool provides detailed time series. No two tools have overlapping purposes.
All tools follow a uniform naming pattern of 'noaa_spaceweather_get_{noun}', where the noun is descriptive and unique (alerts, aurora_forecast, conditions, kp_index, solar_activity, solar_wind). The convention is perfectly consistent.
Six tools is well-scoped for a space weather domain. They cover alerts, current conditions, forecasts, and key parameters (Kp, solar wind, solar activity). This is a focused but complete set without being overwhelming.
The tool set provides comprehensive coverage of essential NOAA SWPC space weather data: alerts, aurora forecasts, current conditions (storm scales, Kp), Kp time series, solar flares/radiation, and real-time solar wind. No obvious gaps are present for an agent monitoring space weather.
Available Tools
6 toolsnoaa_spaceweather_get_alertsGet Space Weather AlertsARead-onlyIdempotentInspect
Active SWPC alerts, watches, and warnings — parsed into structured records with product type, severity level, issue time, validity window, and plain text. Covers geomagnetic storms, radio blackouts, radiation storms, and aurora bulletins. With active_only=false, also returns informational summaries and expired notices. max_age_hours controls how far back to look (default 48 h); the SWPC feed keeps all historical records and has no built-in expiry.
| Name | Required | Description | Default |
|---|---|---|---|
| active_only | No | When true (default), return only Warnings, Watches, and Alerts; exclude Summaries and Other. Set false to return all products. | |
| max_age_hours | No | Maximum age of alerts to return, in hours (default 48). The SWPC feed retains all historical records — this window prevents returning weeks of historical notices as "active." |
Output Schema
| Name | Required | Description |
|---|---|---|
| alerts | Yes | Matching SWPC alert/watch/warning records. |
| notice | No | Status notice when no alerts are active. |
| fetchedAt | Yes | ISO 8601 timestamp of when this data was fetched. |
| totalCount | Yes | Count of records in the alerts array. |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, openWorldHint, idempotentHint. The description adds valuable context such as the parsed record structure, coverage of storm types, and the feed's historical retention without expiry.
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 well-structured with clear, front-loaded sentences. Each 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?
With only 2 boolean/numeric parameters and an output schema, the description fully covers behavior, parameter effects, and data scope. No gaps remain.
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 3. The description adds meaning beyond the schema: e.g., active_only=false returns summaries and expired notices, and max_age_hours prevents returning weeks of old notices.
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 specifically states it retrieves 'Active SWPC alerts, watches, and warnings' and parses them into structured records, clearly distinguishing it from sibling tools like aurora forecast, conditions, 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 explains when to use the tool (retrieve alerts) and details the active_only and max_age_hours parameters, but does not explicitly state when not to use it or compare directly with alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
noaa_spaceweather_get_aurora_forecastGet Aurora ForecastARead-onlyIdempotentInspect
OVATION model aurora forecast for the next ~30–60 min: global grid of aurora probability percentages by latitude/longitude (1° resolution). With optional coordinates, returns the local aurora probability at the nearest grid point, the minimum Kp needed for aurora at that latitude, and a plain-language go/no-go verdict. Without coordinates, returns only global metadata. Data updates every ~5 minutes. Coordinates are geographic (WGS84), not geomagnetic.
| Name | Required | Description | Default |
|---|---|---|---|
| latitude | No | Geographic latitude in degrees (−90 to 90). Provide with longitude for a local aurora probability lookup. | |
| longitude | No | Geographic longitude in degrees (−180 to 180). Provide with latitude for a local aurora probability lookup. |
Output Schema
| Name | Required | Description |
|---|---|---|
| localLookup | Yes | Local aurora lookup result. Null when no coordinates were provided. |
| forecastTime | Yes | Time the aurora forecast is valid for, ISO 8601. |
| gridPointCount | Yes | Total number of grid points in the OVATION model. |
| observationTime | Yes | Time of the OVATION model observation, ISO 8601. |
| topAuroraRegion | Yes | Approximate region of the highest aurora probability grid point. |
| topAuroraPercent | Yes | Highest aurora probability anywhere on the globe (0–100). |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations indicate read-only, open-world, idempotent. Description adds useful behavioral context: update frequency (~5 min), coordinate system (WGS84 geographic not geomagnetic), resolution (1° grid), and output behavior based on coordinates. 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?
Four sentences, front-loaded with main purpose, no unnecessary words. Each sentence adds essential information about behavior, modes, and data freshness.
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 tool has 2 optional params and output schema, description fully covers modes of operation, data source, update frequency, and coordinate system. No missing critical details for an AI agent to use the tool correctly.
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 descriptions. Description adds value by clarifying coordinate system (WGS84) and explaining that providing coordinates triggers local probability lookup with additional outputs like Kp needed and go/no-go verdict.
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?
Description clearly states it provides OVATION model aurora forecast for next 30-60 min with global grid of probability percentages. Distinguishes between local lookup with coordinates vs global metadata without. Differentiates from sibling tools (alerts, conditions, etc.) by focusing on aurora 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?
Explicitly states when to use each mode: provide coordinates for local probability, omit for global metadata. Mentions data updates every 5 minutes. Does not explicitly say when not to use, but sibling context provides differentiation.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
noaa_spaceweather_get_conditionsGet Space Weather ConditionsARead-onlyIdempotentInspect
Current space-weather snapshot: NOAA R/S/G storm scales (today + 3-day forecast), latest Kp index with its G-scale equivalent and aurora-visibility latitude, and a plain-language status summary. The quickest way to answer "is anything happening right now?" — use before deciding whether to drill into solar wind (noaa_spaceweather_get_solar_wind), aurora (noaa_spaceweather_get_aurora_forecast), or alert details (noaa_spaceweather_get_alerts).
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Output Schema
| Name | Required | Description |
|---|---|---|
| today | Yes | Current observed NOAA storm scales for today. |
| summary | Yes | Plain-language status summary suitable for display, e.g. "Quiet conditions" or "G2 moderate geomagnetic storm in progress." |
| forecast | Yes | 3-day NOAA scale forecast (next 1–3 days). |
| currentKp | Yes | Latest observed planetary K-index (0–9). |
| observedAt | Yes | UTC date and time of the NOAA scales data period this snapshot reflects, e.g. "2026-06-04 15:00:00". |
| currentGScale | Yes | NOAA G-scale equivalent for current Kp (0–5). |
| auroraLatitude | Yes | Aurora visibility guidance for current conditions, e.g. "Aurora possible to ~55° geomagnetic latitude". |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, openWorldHint, and idempotentHint. Description adds useful behavioral context: includes forecasts, plain-language summary, and that it's a snapshot. 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?
Two sentences concisely communicate purpose, content, and usage guidance. No redundant or irrelevant 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?
Tool has zero parameters and an output schema, so description need not explain return values. It fully covers what the tool does and when to use it, 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?
No parameters exist, so description correctly does not add parameter info. Baseline of 4 is appropriate as schema coverage is 100% and no parameter documentation is needed.
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?
Description clearly states it provides a 'current space-weather snapshot' with specific data elements (R/S/G scales, Kp index, aurora latitude) and explicitly distinguishes from sibling tools by naming them and their purposes.
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 states it is 'the quickest way to answer "is anything happening right now?"' and advises to 'use before deciding whether to drill into' sibling tools like solar wind, aurora forecast, and alerts.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
noaa_spaceweather_get_kp_indexGet Kp IndexARead-onlyIdempotentInspect
Planetary K-index (0–9 geomagnetic activity scale) — recent observed 3-hour values with their NOAA G-scale equivalents and aurora-latitude guidance, plus the 3-day Kp forecast series. Kp is the primary driver of aurora visibility and geomagnetic storm severity: Kp≥5 is G1, Kp≥7 is G3 (aurora to ~50°), Kp≥9 is G5 extreme. Use noaa_spaceweather_get_conditions for a combined snapshot including storm scales; use this tool when you need the Kp time series or forecast detail.
| Name | Required | Description | Default |
|---|---|---|---|
| window_days | No | Number of past days of observed Kp to return (1–7, default 1). Larger windows show trend context. |
Output Schema
| Name | Required | Description |
|---|---|---|
| forecast | Yes | Forward-looking Kp forecast series (estimated and predicted entries only; observed history excluded). |
| observed | Yes | Observed Kp readings within the requested window, oldest first. |
| currentKp | Yes | Latest observed Kp value. |
| currentGScale | Yes | NOAA G-scale for current Kp. |
| observedCount | Yes | Number of Kp observations in the observed array, matching the requested window. |
| auroraLatitude | Yes | Aurora visibility guidance for current conditions. |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, openWorldHint, idempotentHint. The description adds valuable behavioral context: explaining the Kp scale and its relationship to G-storms and aurora visibility, which helps the agent understand the tool's output implications.
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 only two sentences, front-loading the key information about what the tool returns and then providing usage guidance. Every sentence adds value with 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?
For a simple tool with one parameter and an output schema, the description covers the essential aspects: output content, scale interpretation, usage guidance. It could mention the forecast timescale, but overall it's sufficiently complete.
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% for the single parameter window_days, which already describes its purpose. The description does not add significant extra meaning beyond the schema, so baseline score of 3 is appropriate.
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 the Planetary K-index with observed 3-hour values, G-scale equivalents, aurora-latitude guidance, and 3-day forecast. It explicitly distinguishes from sibling tool noaa_spaceweather_get_conditions by specifying when to use each.
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 provides explicit guidance: 'Use noaa_spaceweather_get_conditions for a combined snapshot...; use this tool when you need the Kp time series or forecast detail.' This clearly tells the agent when to use this tool vs the alternative.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
noaa_spaceweather_get_solar_activityGet Solar ActivityARead-onlyIdempotentInspect
Solar flare and radiation storm picture: recent GOES X-ray flux with flare-class labels (A/B/C/M/X), 3-day flare-class probabilities (C/M/X), active solar regions with per-region flare probabilities, and GOES integral proton flux at ≥10 MeV with NOAA S-scale. For operators tracking HF radio blackout (R-scale, driven by X-ray) and radiation storm risk (S-scale, driven by protons). Active region data helps identify which region is driving current activity.
| Name | Required | Description | Default |
|---|---|---|---|
| include_regions | No | Include active solar region details (default true). Set false to skip region data and reduce response size. |
Output Schema
| Name | Required | Description |
|---|---|---|
| sScale | Yes | Current NOAA S-scale for solar radiation storms (0–5), derived from latest proton flux. |
| fetchedAt | Yes | ISO 8601 timestamp of when this data was fetched. |
| latestXray | Yes | Most recent GOES X-ray flux reading, null if unavailable. |
| recentXray | Yes | GOES X-ray flux readings from the past hour, oldest first. |
| sScaleText | Yes | Plain-language S-scale description, e.g. "S2 moderate radiation storm". |
| latestProton | Yes | Most recent ≥10 MeV proton flux reading, null if unavailable. |
| activeRegions | Yes | Currently active solar regions with per-region flare probabilities. Empty when include_regions=false or no regions are active. |
| probabilities | Yes | 3-day flare probability forecasts. |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, so safety is covered. Description adds value by detailing the data components (X-ray flux, flare classes, proton flux, active regions) and the scales (R-scale, S-scale), which helps the agent understand the tool's behavioral scope without repeating 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?
Description is concise at three sentences, front-loading the main output and use case. Each sentence adds relevant information; no wasted words, though it could be slightly tighter.
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 complexity of solar activity data and the presence of an output schema, the description covers the key elements: flare and radiation storm metrics, active regions, and the operator use case. It is sufficient for an agent to understand what the tool offers.
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% for the single parameter include_regions, and its description in the schema is already clear. The tool description does not add extra meaning beyond what the schema provides, so it meets the baseline of 3.
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?
Description clearly states the tool provides a 'solar flare and radiation storm picture' including specific data like GOES X-ray flux, flare probabilities, active regions, and proton flux. The verb 'get' and resource 'solar activity' are specific, and it distinguishes from siblings (e.g., no other tool mentions flare or proton 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?
Description explicitly targets 'operators tracking HF radio blackout and radiation storm risk,' providing clear context of use. It does not explicitly state when not to use or name alternatives, but sibling tools offer contrasting options (e.g., aurora forecast, KP index), implying situational differentiation.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
noaa_spaceweather_get_solar_windGet Solar WindARead-onlyIdempotentInspect
Real-time solar wind data from DSCOVR at L1: proton speed (km/s), density (n/cm³), temperature (K), and the critical Bz component (southward Bz = negative = storm driver). Returns the recent plasma and magnetic field time series within the requested window. Bz < −10 nT for sustained periods is a primary geomagnetic storm trigger — use alongside noaa_spaceweather_get_kp_index to see whether elevated solar wind has translated into a geomagnetic storm.
| Name | Required | Description | Default |
|---|---|---|---|
| window_hours | No | Hours of recent solar wind history to return (1–168, default 3). Feeds update ~every 1 min. |
Output Schema
| Name | Required | Description |
|---|---|---|
| mag | Yes | Magnetic field measurements (Bx, By, Bz, Bt) within the window. |
| plasma | Yes | Plasma measurements (speed, density, temperature) within the window. |
| bzStatus | Yes | Plain-language Bz status, e.g. "Southward Bz −14 nT — storm-driving conditions" or "Northward Bz +5 nT — quiescent". |
| magCount | Yes | Number of magnetic field records in the mag array, spanning the requested window. |
| latestMag | Yes | Most recent magnetic field reading, null if no data in window. |
| plasmaCount | Yes | Number of plasma records in the plasma array, spanning the requested window. |
| latestPlasma | Yes | Most recent plasma reading, null if no data in window. |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations declare readOnly, openWorld, and idempotent hints; the description supplements this by explaining the Bz significance and that data is a recent time series, adding behavioral context.
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-loaded with key data types, and every sentence adds meaningful information 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 output schema exists, the description does not need to detail return structure; it mentions time series and companion tool, which is sufficient for a simple one-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?
The single parameter 'window_hours' is fully described in the schema, and the description adds value by noting the ~1 min update frequency, enhancing 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 specifies the exact data returned (proton speed, density, temperature, Bz) from DSCOVR at L1, and distinguishes this from sibling tools by mentioning its role in geomagnetic storm detection.
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 suggests using alongside noaa_spaceweather_get_kp_index to assess storm translation, providing clear context; however, it does not explicitly state when not to use this tool.
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!