Skip to main content
Glama
Sign In
ProgramComputer

NASA MCP Server

by ProgramComputer
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Remote

NASA DONKI space weather

nasa_donki
Read-onlyIdempotent

Fetch and summarize NASA space weather events—solar flares, CMEs, geomagnetic storms, shocks, SEP, and simulations—by type for up to 30 days.

Instructions

Space Weather Database Of Notifications, Knowledge, Information (DONKI) events by type for up to 30 days at a time, from the NASA CCMC DONKI API (ccmc.gsfc.nasa.gov): solar flares, CMEs and their analyses, geomagnetic storms, interplanetary shocks, SEP, MPC, RBE and HSS events, WSA-ENLIL simulations and notifications. Compact one-line summaries by default; response_mode raw returns the full records. No API key needed.

Input Schema

NameRequiredDescriptionDefault
typeYesEvent type: cme, cmea, gst, ips, flr, sep, mpc, rbe, hss, wsa, notifications.
limitNoReturn only the most recent N events. Applied by this server; DONKI has no limit parameter.
endDateNoEnd date (YYYY-MM-DD), at most 30 days after startDate. Defaults to today.
startDateNoStart date (YYYY-MM-DD). With only endDate, 30 days before endDate; with neither, the last 30 days.
response_modeNocompact (default): one line per event with its key fields. raw: the full DONKI records as JSON (large for cme, cmea and wsa).compact

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed7 schema fields changedv1.2.0
    • addedInput schema / additionalProperties
      Added value: +false
    • changedInput schema / properties / endDate / description
      Previous value: -"End date (YYYY-MM-DD)"New value: +"End date (YYYY-MM-DD), at most 30 days after startDate. Defaults to today."
    • addedInput schema / properties / limit
      Added value: +{
+  "description": "Return only the most recent N events. Applied by this server; DONKI has no limit parameter.",
+  "maximum": 1000,
+  "minimum": 1,
+  "type": "integer"
+}
    • addedInput schema / properties / response_mode
      Added value: +{
+  "default": "compact",
+  "description": "compact (default): one line per event with its key fields. raw: the full DONKI records as JSON (large for cme, cmea and wsa).",
+  "enum": [
+    "compact",
+    "raw"
+  ],
+  "type": "string"
+}
    • changedInput schema / properties / startDate / description
      Previous value: -"Start date (YYYY-MM-DD)"New value: +"Start date (YYYY-MM-DD). With only endDate, 30 days before endDate; with neither, the last 30 days."
    • changedInput schema / properties / type / description
      Previous value: -"Type of space weather event"New value: +"Event type: cme, cmea, gst, ips, flr, sep, mpc, rbe, hss, wsa, notifications."
    • addedInput schema / properties / type / enum
      Added value: +[
+  "cme",
+  "cmea",
+  "gst",
+  "ips",
+  "flr",
+  "sep",
+  "mpc",
+  "rbe",
+  "hss",
+  "wsa",
+  "notifications"
+]
  2. First observed

TDQS

A3.9/5.0
Behavior4/5

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

Annotations already declare readOnlyHint, idempotentHint and openWorldHint, so the safety profile is covered. The description still adds real value beyond them: no API key required, the 30-day request ceiling, and that response_mode=raw yields large payloads specifically for cme, cmea and wsa. It stops short of describing pagination or rate-limit behavior, which keeps it out of 5 territory.

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

Conciseness4/5

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

A single front-loaded paragraph that names the source and the primary constraint first, then the type list and response modes. It is dense but every clause carries information; the long event-acronym roster is the only slight bloat.

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

Completeness4/5

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

There is no output schema, so the description reasonably covers return shape by explaining compact vs raw. Combined with rich annotations and full schema coverage, an agent has enough to invoke correctly; only the absence of error/empty-result behavior keeps it from 5.

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

Parameters3/5

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

Schema description coverage is 100%, so all five parameters are already documented in the schema, and the description largely restates them (event types, compact vs raw). The 30-day window nuance is the only added semantics, so the baseline 3 is appropriate.

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?

States a specific resource (DONKI space weather events) with the exact event-type taxonomy and names the upstream source (NASA CCMC DONKI API). An agent can immediately tell this apart from siblings like nasa_neo or jpl_fireball, which cover unrelated datasets.

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

Usage Guidelines3/5

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

The 'up to 30 days at a time' window implies a date-range use case, and enumerating the solar-flare/CME/storm event types hints at when the tool applies. However, there is no explicit when-to-use, no alternative named, and no exclusion guidance for an agent choosing among the 30 sibling NASA/JPL tools.

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

Deploy Server

Other Tools