Skip to main content
Glama

noaa-spaceweather-mcp-server

by io.github.cyanheads

Get Solar Wind

noaa_spaceweather_get_solar_wind
Read-onlyIdempotent

Real-time solar wind measurements from the active spacecraft 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, oldest first, each record tagged with the reporting spacecraft. 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.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
window_hoursNoHours of recent solar wind history to return (1–168, default 3). Records update ~every 1 min, but the feed only carries roughly the last 24 hours — a larger window returns the whole feed, not more history. When a window comes back empty, feedStalenessHours and latestFeedPlasmaTime/latestFeedMagTime report how current the feed actually is.

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault
magNoMagnetic field measurements (Bx, By, Bz, Bt) within the window, oldest first.
errorNoPresent when the call failed. Absent on success.
noticeNoGuidance when the requested window returned no plasma or magnetic field records — names the newest record the feed carries, or reports that the feed itself returned nothing from an active spacecraft.
plasmaNoPlasma measurements (speed, density, temperature) within the window, oldest first.
bzStatusNoPlain-language Bz status, e.g. "Southward Bz −14 nT — storm-driving conditions" or "Northward Bz +5 nT — quiescent".
magCountNoNumber of magnetic field records in the mag array, spanning the requested window.
latestMagNoMost recent magnetic field reading, null if no data in window.
plasmaCountNoNumber of plasma records in the plasma array, spanning the requested window.
latestPlasmaNoMost recent plasma reading, null if no data in window.
latestFeedMagTimeNoISO 8601 time of the newest magnetic field record the feed carries, ignoring the window. Null when the feed returned no active-spacecraft mag records.
feedStalenessHoursNoHours between now and the newest record across both feeds — how far behind real time the upstream data is. Null when both feeds returned no active-spacecraft records.
latestFeedPlasmaTimeNoISO 8601 time of the newest plasma record the feed carries, ignoring the window. Null when the feed returned no active-spacecraft plasma records. Compare against the window to tell a quiet feed from a stale one.

TDQS

A4.8/5.0
Behavior5/5

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

Annotations already declare readOnly/openWorld/idempotent, but the description adds substantial behavior beyond that: update frequency (~1 min), feed retention (~24 hours), that larger windows return the whole feed, records sorted oldest-first, spacecraft tagging, and handling of empty windows via feedStalenessHours/latestFeed times. This covers edge cases and data provenance thoroughly.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

While lengthy, every sentence adds operational value—data content, sorting, spacecraft tags, storm significance, and cross-referencing. The main purpose is front-loaded, and the structure flows from what the tool returns to how to interpret it. No filler or redundancy.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the tool's complexity (feed special cases, storm relevance), the description is complete: it covers the data, the parameter's behavior, what to pair it with, and how to interpret errors (empty window). The output schema exists, so return details aren't needed. The description fully enables correct selection and invocation.

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

Parameters5/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The schema describes window_hours with range and default (100% coverage, baseline 3), but the description adds critical semantics: what happens with windows >24h (returns whole feed, not more history), the meaning of an empty window, and how to check feed currentness. This goes beyond the schema and directly impacts correct invocation.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description states a specific verb and resource: 'Real-time solar wind measurements from the active spacecraft at L1', and enumerates exact data fields (proton speed, density, temperature, Bz). It clearly distinguishes itself from sibling tools (alerts, aurora, conditions, KP, solar activity) by focusing on solar wind plasma and magnetic field data.

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

Usage Guidelines4/5

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

It provides clear usage context: Bz threshold for storm triggers, and explicitly recommends using alongside noaa_spaceweather_get_kp_index to assess storm translation. While it doesn't explicitly state 'don't use for X', the domain is so specific that alternatives are obvious, and the pairing guidance is actionable.

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

All noaa-spaceweather-mcp-server toolsInspect
Try in Browser
RayrunBuild, deploy, and operate MCP servers without becoming an infrastructure team.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

TDQS

A4.5/5.0
Disambiguation5/5

Each tool targets a distinct aspect of space weather: alerts, aurora forecast, conditions snapshot, Kp index, solar activity, and solar wind. No two tools serve the same purpose, and the descriptions clearly delineate when to use each (e.g., conditions for a quick overview versus Kp for time series detail).

Naming Consistency5/5

All tools follow the exact same pattern: `noaa_spaceweather_get_<resource>`. This is perfectly consistent and predictable, making it easy for an agent to infer tool purpose from the name alone.

Tool Count5/5

With 6 tools, the server covers the major space-weather data categories without being overwhelming. Each tool provides substantial, non-redundant information, and the scope aligns well with what an agent might need for operational space-weather queries.

Completeness5/5

The tool set spans alerts/warnings, current conditions, KP index, solar activity, solar wind, and aurora forecasts – covering the full lifecycle of space-weather monitoring. No obvious missing operations exist; the description even cross-references tools to guide exploration (e.g., conditions leads to solar wind, aurora, or alerts).

Resources