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.5/5 across 6 of 6 tools scored.
Each tool targets a distinct aspect of space weather (alerts, aurora, conditions, Kp, solar activity, solar wind). Descriptions are detailed and clearly differentiate the data each tool returns.
All tools follow the consistent pattern 'noaa_spaceweather_get_<resource>' with snake_case, making the naming predictable and easy to understand.
Six tools cover the essential areas of space weather monitoring without being excessive. Each tool serves a unique purpose and the count is appropriate for the server's scope.
The set covers real-time conditions, alerts, forecasts, and key parameters. Missing historical data access and perhaps a combined forecast tool, but core operations are well-covered.
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 value by explaining that the SWPC feed retains all historical records and max_age_hours prevents returning weeks of notices, providing behavioral context 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 three sentences, front-loaded with the main purpose, and each sentence adds essential information without redundancy or 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?
Given the tool has only two parameters with full schema coverage and an output schema (not shown), the description adequately explains behavior, filtering, and data source characteristics, making it 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% with descriptions for both parameters. The description adds context for max_age_hours (default 48h and why) and clarifies that active_only=false returns summaries and expired notices, 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 clearly states it retrieves 'Active SWPC alerts, watches, and warnings' and lists the types covered (geomagnetic storms, radio blackouts, etc.). It distinguishes from sibling tools (forecast, conditions, etc.) by specifying alerts specifically.
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 (for active alerts) and how to modify behavior with active_only and max_age_hours. It does not explicitly exclude alternatives, but the 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_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 (readOnlyHint, openWorldHint, idempotentHint) are consistent with description. No contradiction. Description adds context about output components but could mention data freshness or rate limits; however annotations reduce the burden.
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, clearly structured with output details first followed by usage context. No extraneous information; each sentence adds value.
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 moderate complexity (multiple output components) and presence of output schema, the description adequately covers all aspects: recent flux, probabilities, regions, and proton flux. No gaps identified.
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 (include_regions) is fully described in the schema. The description mentions active region data but does not add new semantics beyond the schema. With 100% schema coverage, baseline 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?
Description clearly states the tool provides a picture of solar flares and radiation storms, listing specific data types like GOES X-ray flux, flare probabilities, active regions, and proton flux. It distinguishes itself from siblings by focusing on current activity for HF and radiation storm tracking.
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 specifies target users (operators tracking HF radio blackout and radiation storm risk) and explains what the data helps identify. It does not explicitly contrast with alternatives but implies usage context relative to sibling tools.
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!