NASA MCP

by jdalbright

Overview Schema Related Servers Score Discussions

TypeScript

Local

Server Quality Checklist

Profile completionA complete profile improves this server's visibility in search results.

Latest release: v1.0.0
Disambiguation4/5
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.
Naming Consistency3/5
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.
Tool Count5/5
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.
Completeness4/5
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.
Average 3.9/5 across 9 of 9 tools scored.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 2 commits in the last 12 weeks
- No stable releases found
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI status not available
Add a LICENSE file by following GitHub's guide. Once GitHub recognizes the license, the system will automatically detect it within a few hours.
If the license does not appear after some time, you can manually trigger a new scan using the MCP server admin interface.
MCP servers without a LICENSE cannot be installed.
This repository includes a README.md file.
No tool usage detected in the last 30 days. Usage tracking helps demonstrate server value.
Tip: use the "Try in Browser" feature on the server page to seed initial usage.
Add a glama.json file to provide metadata about your server.
If you are the author, simply .
If the server belongs to an organization, first add glama.json to the root of your repository:
```
{
  "$schema": "https://glama.ai/mcp/schemas/server.json",
  "maintainers": [
    "your-github-username"
  ]
}
```
Then . Browse examples.
Add related servers to improve discoverability.

How to sync the server with GitHub?

Servers are automatically synced at least once per day, but you can also sync manually at any time to instantly update the server profile.

To manually sync the server, click the "Sync Server" button in the MCP server admin interface.

How is the quality score calculated?

The overall quality score combines two components: Tool Definition Quality (70%) and Server Coherence (30%).

Tool Definition Quality measures how well each tool describes itself to AI agents. Every tool is scored 1–5 across six dimensions: Purpose Clarity (25%), Usage Guidelines (20%), Behavioral Transparency (20%), Parameter Semantics (15%), Conciseness & Structure (10%), and Contextual Completeness (10%). The server-level definition quality score is calculated as 60% mean TDQS + 40% minimum TDQS, so a single poorly described tool pulls the score down.

Server Coherence evaluates how well the tools work together as a set, scoring four dimensions equally: Disambiguation (can agents tell tools apart?), Naming Consistency, Tool Count Appropriateness, and Completeness (are there gaps in the tool surface?).

Tiers are derived from the overall score: A (≥3.5), B (≥3.0), C (≥2.0), D (≥1.0), F (<1.0). B and above is considered passing.

Tool Scores

Behavior3/5
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.
Conciseness5/5
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.
Completeness3/5
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.
Parameters2/5
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.
Purpose5/5
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.
Usage Guidelines3/5
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.
Behavior4/5
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.
Conciseness4/5
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.
Completeness3/5
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.
Parameters2/5
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.
Purpose5/5
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.
Usage Guidelines3/5
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.
Behavior3/5
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.
Conciseness5/5
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.
Completeness4/5
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.
Parameters3/5
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.
Purpose5/5
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.
Usage Guidelines3/5
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.
Behavior2/5
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.
Conciseness4/5
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.
Completeness3/5
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.
Parameters4/5
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.
Purpose5/5
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.
Usage Guidelines4/5
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.
Behavior4/5
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.
Conciseness5/5
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.
Completeness4/5
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.
Parameters2/5
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.
Purpose5/5
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.
Usage Guidelines3/5
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.
Behavior3/5
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.
Conciseness5/5
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.
Completeness4/5
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.
Parameters2/5
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.
Purpose5/5
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.
Usage Guidelines4/5
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.
Behavior3/5
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.
Conciseness5/5
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.
Completeness4/5
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.
Parameters3/5
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.
Purpose5/5
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.
Usage Guidelines4/5
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.
Behavior3/5
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.
Conciseness5/5
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.
Completeness4/5
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.
Parameters3/5
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.
Purpose5/5
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.
Usage Guidelines4/5
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.
Behavior4/5
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.
Conciseness5/5
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.
Completeness4/5
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.
Parameters3/5
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.
Purpose5/5
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.
Usage Guidelines4/5
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.

GitHub Badge

Glama performs regular codebase and documentation scans to:

Confirm that the MCP server is working as expected.
Confirm that there are no obvious security issues.
Evaluate tool definition quality.

Our badge communicates server capabilities, safety, and installation instructions.

Card Badge

Copy to your README.md:

[![nasa-mcp MCP server](https://glama.ai/mcp/servers/jdalbright/nasa-mcp/badges/card.svg)](https://glama.ai/mcp/servers/jdalbright/nasa-mcp)

Score Badge

Copy to your README.md:

[![nasa-mcp MCP server](https://glama.ai/mcp/servers/jdalbright/nasa-mcp/badges/score.svg)](https://glama.ai/mcp/servers/jdalbright/nasa-mcp)

Latest Blog Posts

Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)
By Om-Shree-0709 on July 25, 2026.
mcp
Agent Identity
OAuth 2.1
Your AI Chatbot Just Exposed Your CEO's Salary to an Intern
By Om-Shree-0709 on July 2, 2026.
Agent Identity
MCP Security
OAuth Delegation
Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)
By Om-Shree-0709 on June 30, 2026.
Agentic Ai
Prompt Injection
WebAssembly

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/jdalbright/nasa-mcp'

If you have feedback or need assistance with the MCP directory API, please join our Discord server