Integrates with NASA's public APIs to provide tools for astronomy pictures, media search, Earth events, space weather, and EPIC Earth imagery.
Click on "Deploy Server".
Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state.
In the chat, type @ followed by the MCP server name and your instructions, e.g., "@NASA MCP show me today's astronomy picture of the day"
That's it! The server will respond to your query, and you can continue using it as needed.
Here is a step-by-step guide with screenshots.
A local stdio MCP server that turns NASA's public APIs into compact, assistant-friendly tools instead of pouring raw telemetry into the context window.
nasa_daily_brief — APOD, recent space-weather notices, current Earth events, and the latest full-disc Earth image in one fault-tolerant call.
nasa_apod — Astronomy Picture of the Day by date or random sample.
nasa_search_media — search NASA's image, video, and audio library.
nasa_media_asset — retrieve downloadable files for a NASA media ID.
nasa_earth_events — current/recent wildfires, storms, volcanoes, icebergs, floods, and other EONET events.
nasa_space_weather — DONKI notifications or event feeds such as flares, CMEs, and geomagnetic storms.
nasa_epic_earth — recent DSCOVR/EPIC full-disc Earth imagery with direct image URLs.
nasa_power_daily — historical daily weather, solar-resource, and agricultural data for a latitude/longitude in compact columnar series.
nasa_power_climatology — monthly and annual climate normals for a location using NASA POWER's standard 2001–2020 baseline.
NASA POWER tools provide weather, solar, and agriculture presets, or up to ten explicitly selected parameter codes. The agriculture preset defaults to POWER's AG community; other requests default to RE, with SB also available when community-specific units are needed. Daily requests are limited to 366 calendar days and 2,000 parameter-day values, radiation parameters begin on 1984-01-01, and responses clearly identify the data as historical rather than a forecast.
Related MCP server: NASA MCP Server
npm install
npm test
npm run smokeThe smoke test always exercises the six keyless live tools. It exercises APOD, DONKI, and the combined daily brief only when a registered NASA_API_KEY is configured; degraded API-keyed sections do not receive a false green.
NASA_API_KEY is optional. Without it, the server uses NASA's DEMO_KEY (30 requests/hour and 50/day per IP). EONET, EPIC, NASA POWER, and the NASA media library are keyless. For regular use, create a free key at https://api.nasa.gov/ and expose it as NASA_API_KEY in the MCP server environment.
NASA_API_KEY=... node dist/index.jsThe server speaks MCP over stdio. Logs go to stderr; stdout is reserved for protocol frames.
Date ranges, numeric limits, enum values, and extra arguments are strictly validated.
Free-text and ID inputs are length-limited; outputs are normalized, truncated, and capped to avoid context flooding.
Requests are restricted to fixed NASA HTTPS origins, use 20-second timeouts, and retry transient 5xx responses once.
nasa_daily_brief returns partial results when one upstream API is unavailable, including shared DEMO_KEY throttling.
NASA API keys are redacted from returned source URLs; rate-limit headers are surfaced when available.
Sources: NASA Open APIs, NASA Image and Video Library, EONET v3, DONKI, EPIC, and NASA POWER.
Get NASA's Astronomy Picture of the Day for a date, or a small random sample. Returns image/video URLs, title, credit, and a bounded explanation.
| Name | Required | Description | Default |
|---|---|---|---|
| date | No | Optional date in YYYY-MM-DD format. | |
| count | No | Optional random sample size. Cannot be combined with date. | |
| include_hd | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description partially carries the transparency burden. It discloses the output shape (image/video URLs, title, credit, bounded explanation) and notes the sample is 'small,' implying a capped count. However, it omits details like error handling, rate limits, or what happens on invalid input, leaving some behavioral aspects opaque.
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 entire description is one well-structured, front-loaded sentence. It communicates the core purpose, parameters, and return type without extraneous words, making it easy for an agent to quickly parse.
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 (three optional parameters, no output schema), the description covers the main behavior and return contents adequately. It doesn't mention include_hd's purpose or explicitly restate the date/count exclusivity, but the schema already documents the latter. Overall, it is nearly complete for a straightforward read-only API.
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 67% (date and count have descriptions, include_hd does not). The description's phrase 'for a date, or a small random sample' reinforces the date/count parameters but adds no specifics about include_hd or date format. It slightly compensates for the missing include_hd description but does not fully clarify its effect.
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 function with an explicit verb ('Get') and specific resource ('NASA's Astronomy Picture of the Day'). It also defines the two operating modes (by date or random sample) and the expected return contents, which distinguishes it from sibling NASA tools like search or media asset.
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 clear context for when to use the tool: for a specific date or a random sample. It does not explicitly mention alternatives or exclusions relative to siblings, but the intended use case is evident. The schema also reinforces the mutual exclusivity of date and count, adding to usage clarity.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get a compact NASA daily brief: today's astronomy image, recent space-weather notices, active Earth events, and the latest DSCOVR full-disc Earth image. Returns partial results if an upstream NASA service is down.
| Name | Required | Description | Default |
|---|---|---|---|
| lookback_days | No | Days of space-weather and Earth-event history to include. | |
| earth_event_limit | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the behavioral transparency burden. It discloses the partial-results behavior when an upstream service is down, which is useful. It doesn't cover other aspects like error handling, but the disclosed trait adds significant value.
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: the first lists what the brief includes, the second notes partial-result behavior. Every word earns its place 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?
Despite having no output schema, the description gives a solid sense of what is returned (list of content areas) and the failure behavior. It doesn't fully describe the return structure, but for an aggregation-style tool this is adequate.
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 50%, with one parameter (earth_event_limit) lacking any description. The tool description doesn't elaborate on either parameter's effect, so it fails to compensate for the missing schema documentation.
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 gets a 'compact NASA daily brief' and enumerates the specific content (astronomy image, space-weather notices, Earth events, DSCOVR image). This distinguishes it from sibling tools that each target a single NASA data source.
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 use case is implied: use this for a consolidated daily summary. However, it doesn't explicitly contrast with alternatives like nasa_apod or nasa_space_weather, or state when not to use it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Find current or recent natural events from NASA EONET, including storms, wildfires, volcanoes, floods, sea/lake ice, dust, drought, and landslides. Returns latest coordinates and source links.
| Name | Required | Description | Default |
|---|---|---|---|
| bbox | No | Optional [west, north, east, south] bounding box. | |
| days | No | ||
| limit | No | ||
| status | No | open | |
| category | No | Optional EONET category ID, such as wildfires, severeStorms, volcanoes, floods, or seaLakeIce. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the burden of behavior disclosure. It adds value by stating that the tool returns 'latest coordinates and source links' and implies a time filter ('current or recent'), but it does not mention default values like days=14, status='open', or pagination behavior. For a simple read-only tool, this is adequate but not rich.
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 two sentences, front-loaded with the core purpose and followed by a concise statement about return data. Every word adds value, with no repetition of schema defaults or other filler, making it an ideal size.
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 (5 optional parameters, no output schema), the description is mostly complete: it states the source (NASA EONET), what it returns (coordinates, links), and the event categories. It omits some details like default day range or status filtering, but those are present in the schema defaults, so the description is sufficient for selection and basic invocation.
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 low (40%), yet the description adds little to explain parameters. It repeats category examples already present in the schema (e.g., 'wildfires, severeStorms') but does not clarify 'days', 'limit', 'status', or 'bbox' beyond what the schema defaults provide. The description should compensate for low schema coverage but does not.
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 ('Find') and resource (NASA EONET natural events), then lists explicit categories (storms, wildfires, volcanoes) that distinguish it from sibling tools like nasa_apod or nasa_power_daily. It also notes the output includes coordinates and source links, leaving no ambiguity about what the tool does.
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 clear context for when to use the tool by specifying it returns current or recent natural events and enumerating the event types covered. However, it does not explicitly name alternatives or state when not to use this tool, though the sibling tools are clearly different enough that the intended use case is evident.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get DSCOVR/EPIC full-disc Earth images with direct PNG/JPG/thumbnail URLs and spacecraft geometry. Keyless NASA endpoint.
| Name | Required | Description | Default |
|---|---|---|---|
| date | No | Optional YYYY-MM-DD archive date. Omit for the latest images. | |
| limit | No | ||
| collection | No | natural |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It discloses that the endpoint is keyless and that the output includes URLs and geometry, which is useful. However, it does not mention rate limits, error behavior, or explicitly state that it is a read-only operation beyond the word 'Get'. Some behavioral context is added but significant gaps remain.
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, front-loaded with the primary purpose, and no filler. Every word contributes to understanding the tool's function and output. Excellent conciseness and structure.
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 3 optional parameters, no annotations, and no output schema, the description provides a high-level overview but lacks details on response structure, collection option meanings, and error handling. It adequately covers the main function but is not fully complete for an agent to invoke without additional inference.
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 only 33% (only 'date' has a description). The description adds no parameter information whatsoever, failing to explain the 'collection' enum values or 'limit' semantics. Since coverage is low, the description needed to compensate but did not, leaving the agent to infer parameter meanings from names and enum values 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 uses a specific verb ('Get') and resource ('DSCOVR/EPIC full-disc Earth images') and explicitly mentions direct PNG/JPG/thumbnail URLs and spacecraft geometry, which clearly distinguishes it from sibling tools like nasa_apod or nasa_search_media that serve different content.
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 for EPIC imagery but does not explicitly state when to prefer this tool over alternatives or provide exclusion criteria. It lacks comparison to sibling tools or guidance on when not to use this tool, though the specificity of the content gives some context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Resolve a NASA media ID to its downloadable image, video, audio, caption, and metadata files.
| Name | Required | Description | Default |
|---|---|---|---|
| nasa_id | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It does disclose that the tool returns downloadable files of several types, but it does not describe the return format, possible multiple assets, error behavior, or any side effects. It is not misleading, but it is minimal.
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 a single, front-loaded sentence with no filler or repetition. Every word contributes to explaining the tool's function and output.
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?
This is a simple one-parameter tool with no output schema, and the description covers the main output categories (image, video, audio, caption, metadata). It could be more complete by noting that the ID typically comes from nasa_search_media or describing the exact response structure, but it is adequate for a simple resolver.
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?
There is one parameter, nasa_id, with 0% schema description coverage. The description adds meaning by saying it is a NASA media ID that resolves to files, but it does not explain where to obtain the ID, its format, or provide examples. The description partially compensates for the low schema 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 uses a specific verb ('Resolve') and resource ('NASA media ID'), and clearly states the output: downloadable image, video, audio, caption, and metadata files. This distinguishes it from sibling tools like nasa_search_media, which searches instead of resolving.
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 the tool should be used when you already have a NASA media ID to resolve, but it does not explicitly state when to use it vs. alternatives such as nasa_search_media, nor does it mention any exclusions or prerequisites. The usage context is implied rather than explicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get NASA POWER monthly and annual climatology for one latitude/longitude using the standard 2001-2020 baseline. Useful for typical weather, rainfall, wind, solar potential, and growing conditions; not a forecast.
| Name | Required | Description | Default |
|---|---|---|---|
| profile | No | Preset parameter group. Defaults to weather when parameters is omitted. | |
| latitude | Yes | ||
| community | No | POWER user community controlling community-specific units. Defaults to AG for the agriculture profile and RE otherwise. | |
| longitude | Yes | ||
| parameters | No | Optional NASA POWER parameter codes; overrides the default profile and cannot be combined with profile. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the burden and does well by disclosing the baseline period (2001-2020), the climatological nature (monthly/annual averages), single-point limitation, and the 'not a forecast' caveat. 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?
Two tightly composed sentences: the first states the core functionality and baseline, the second adds use cases and a critical exclusion. No fluff or redundant phrases.
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?
The description covers the essential context: what data is returned (climatology for a point), the baseline, use cases, and what it isn't. It doesn't describe return format, but given the schema's parameter details and the tool's simplicity, it's adequate for an agent to select and invoke it 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 already covers descriptions for profile, community, and parameters (60% coverage). The description adds use-case context but doesn't clarify individual parameters beyond what the schema provides; latitude/longitude are self-explanatory. Adequate but not compensating beyond baseline.
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 NASA POWER monthly and annual climatology for a single latitude/longitude with a specific baseline (2001-2020). It distinguishes from daily or forecast tools via the 'not a forecast' note, making it highly specific.
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 gives clear context: useful for typical weather, rainfall, wind, solar potential, and growing conditions, and explicitly excludes forecasts. It doesn't name alternative tools but the sibling nasa_power_daily is implied for daily data. No explicit alternatives, so not a 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get historical daily NASA POWER weather, solar-resource, or agricultural data for one latitude/longitude. This is analysis-ready historical data, not a forecast. Returns compact columnar series with units.
| Name | Required | Description | Default |
|---|---|---|---|
| profile | No | Preset parameter group. Defaults to weather when parameters is omitted. | |
| end_date | Yes | End date in YYYY-MM-DD format; range is capped at 366 calendar days and 2,000 returned parameter-day values. | |
| latitude | Yes | ||
| community | No | POWER user community controlling community-specific units. Defaults to AG for the agriculture profile and RE otherwise. | |
| longitude | Yes | ||
| parameters | No | Optional NASA POWER parameter codes; overrides the default profile and cannot be combined with profile. | |
| start_date | Yes | Start date in YYYY-MM-DD format. Meteorological parameters begin 1981-01-01; radiation parameters and the solar profile begin 1984-01-01. | |
| time_standard | No | LST |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It does usefully state that the return format is 'compact columnar series with units' and asserts that the data is 'analysis-ready', but it omits important operational details such as date range limits, data source caveats, or the fact that data is point-based only. This is some transparency but not comprehensive.
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 at two sentences, with the key action and resource front-loaded. Every sentence adds information: purpose, temporal scope, data type, and return format. There is no fluff or 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 moderate complexity (8 parameters, no output schema), the description is fairly complete: it states what the tool returns and that it is historical point data. The schema fills in parameter details. It lacks an explicit distinction from nasa_power_climatology, but the context signals and the word 'daily' provide some implicit differentiation, making the description adequate for a single-point data retrieval 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 63%, which is moderate. The description adds meaning by clarifying that the tool handles 'weather, solar-resource, or agricultural data' which maps to the 'profile' parameter, and 'one latitude/longitude' reinforces the coordinate parameters. However, it does not explain individual parameter codes or the community parameter, relying mostly on 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 uses a specific verb ('Get') and clearly identifies the resource ('historical daily NASA POWER weather, solar-resource, or agricultural data') with a clear scope ('for one latitude/longitude'). It also distinguishes from the sibling tool nasa_power_climatology by specifying 'daily' 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?
The description provides clear context for when to use the tool: it is for historical data ('analysis-ready historical data') and explicitly states it is 'not a forecast', which guides an agent away from misusing it for future predictions. However, it does not explicitly mention alternatives or exclusion criteria for the sibling climatology tool, so it falls short of a full 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Search NASA's public image, video, and audio library. Returns compact metadata plus preview/original links and NASA media IDs.
| Name | Required | Description | Default |
|---|---|---|---|
| page | No | ||
| limit | No | ||
| query | Yes | Free-text search query. | |
| year_end | No | ||
| media_type | No | image | |
| year_start | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the burden of behavioral disclosure. It adds useful information not in the schema: the search is over NASA's 'public' library, returns 'compact metadata', and provides 'preview/original links and NASA media IDs'. It does not mention rate limits or pagination, but the added context is meaningful.
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 a single, front-loaded sentence that efficiently conveys purpose and return contents. It is not verbose, but it does not fully earn its place by omitting usage guidance or parameter hints. Still, it is appropriately compact.
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 6 parameters and no output schema, the description is moderately complete: it states the search scope and return format, but does not cover pagination, parameter behavior, or when to prefer this over siblings. It is adequate but leaves gaps for the agent to infer.
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 only 17% (only 'query' is described). The description does not describe page, limit, media_type, year_start, or year_end. The mention of 'image, video, and audio library' loosely hints at media_type, but the description fails to compensate for the low schema coverage, leaving most parameter semantics undocumented.
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 uses a specific verb ('Search') and clearly identifies the resource ('NASA's public image, video, and audio library'). It distinguishes from sibling tools like nasa_media_asset by focusing on the search action over a broad media collection, and mentions return contents.
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 this tool is for searching the NASA media library, but provides no explicit 'when to use' vs alternatives, no exclusions, and no mention of how it relates to nasa_media_asset or other NASA tools. The usage context is only weakly implied by the verb 'Search'.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get recent NASA DONKI space-weather reports: notifications, solar flares, CMEs, geomagnetic storms, solar energetic particles, interplanetary shocks, magnetopause crossings, radiation-belt enhancements, or high-speed streams.
| Name | Required | Description | Default |
|---|---|---|---|
| days | No | Lookback used when start_date is omitted. | |
| limit | No | ||
| end_date | No | Optional YYYY-MM-DD end date. Defaults to today UTC. | |
| event_type | No | notifications | |
| start_date | No | Optional YYYY-MM-DD start date. Defaults from days. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It only says 'Get ... reports', disclosing no additional behavioral traits such as response format, pagination, or any restrictions. It does not go beyond what the tool name implies, leaving the agent without knowledge of side effects or output structure.
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 a single sentence that front-loads the core purpose and then enumerates the subtypes. It is somewhat list-heavy but still compact and avoids redundant wording. It earns its place by packing all relevant report types into one readable line.
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 there is no output schema and no annotations, the description should explain what the tool returns, but it only says 'reports' without describing the response structure or any limitations. With 5 parameters, a bit more context about defaults or usage would help, but the tool is a simple read operation, so this is minimally adequate.
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 description adds meaning by listing all event_type enum values, which is not explicitly spelled out in the schema for the parameter. It also uses 'recent' to imply the time window controlled by days/start_date. However, limit and date format semantics are left to the schema, which already covers 60% of parameters.
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 uses the specific verb 'Get' and identifies the resource as 'NASA DONKI space-weather reports', then lists the nine report types, making it clear exactly what the tool returns. It distinguishes itself from siblings like nasa_apod and nasa_epic_earth by its unique domain (space weather).
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 the tool is for retrieving recent space-weather data and enumerates the event types, which tells the user what kind of information they can request. However, it does not explicitly state when to use this tool versus alternatives, though no direct alternative among siblings exists, so the context is clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
v1.0.0nasa_apodnasa_daily_briefnasa_earth_eventsnasa_epic_earthnasa_media_assetnasa_power_climatologynasa_power_dailynasa_search_medianasa_space_weatherScored across 9 tools
Most tools target a distinct NASA dataset or service. nasa_daily_brief aggregates content from several other tools, which could cause minor overlap, but it serves a distinct purpose as a summary. Search vs. asset and daily vs. climatology are clearly separated.
All tools share the nasa_ prefix and use descriptive snake_case, but the structure varies: some are noun phrases (nasa_earth_events), one is verb+noun (nasa_search_media), and others are acronym-based (nasa_apod). This mixed convention is readable but not a strict pattern.
Nine tools is well within the ideal 3-15 range. Each tool represents a distinct NASA data source or function, making the set neither bloated nor thin.
The server provides solid coverage of popular NASA data: imagery, media, Earth events, space weather, and climate/weather data. It lacks some notable datasets (e.g., Mars Rover photos, exoplanets) but for a general NASA MCP it covers the core areas without dead ends.
NASA MCP — wraps NASA Open APIs (api.nasa.gov)
Gateway between LLM agents and world data through eight tools and a bundled endpoint catalog.
Live space data for AI agents - rocket launches, ISS passes, launch news. Free, no auth.
NASA data: near-Earth objects, space weather, and astronomy pictures
