NASA Earthdata MCP

by io.github.nasa

Overview Discussions Admin

get_tools

Read-onlyIdempotent

Search NASA CMR tools for a specific parent collection and return all associated normalized UMM-T records.

Key fields in each returned item:

concept_id: CMR tool concept ID
native_id: native ID of the tool record
revision_id: revision ID of the tool metadata
provider_id: provider ID of the tool
name: tool name
type: tool type (e.g., Downloadable Tool, Web User Interface, Web Portal, Model)
version: tool version string
description: human-readable tool description
url: Primary URL for directly accessing the tool
supported_input_formats: file formats the tool can read (e.g., HDF5, NETCDF-4, GeoTIFF)
supported_output_formats: file formats the tool can produce
supported_operating_systems: OS compatibility (name and version)
supported_browsers: browser compatibility (name and version)
supported_software_languages: programming language compatibility
tool_keywords: Earth science keyword taxonomy for the tool
organizations: providers, developers, or publishers of the tool
potential_action: smart handoff definition for parameterized deep links (e.g., 'Open in Giovanni')

Key parameters:

collection_concept_id: required parent collection concept ID

Iteration & Refinement:

All tools associated with the collection are fetched in a single request. Paging is not supported.

Note: A collection may be associated with multiple tools of different types. Check type to distinguish between downloadable tools, web user interfaces, and web portals.

Tool call template

This tool declares no required parameters. Add optional parameters from the input schema as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {},
    "name": "get_tools"
  }
}

Input Schema

Name	Required	Description
`limit`	No	Maximum number of results to return (default 10, max 50). Keep this small to avoid context window bloat. When using limit > 10, always specify the fields parameter.
`cursor`	No	Pagination token for the next page of results. Pass the exact next_cursor string returned by the previous tool call. Cursors are query-scoped: they lock in the original search parameters and cannot be reused across different tools or different queries. If you need to change any search parameter, start a new search without a cursor.
`fields`	No
`keyword`	No
`collection_concept_id`	No

Output Schema

Name	Required	Description
`tools`	No	Normalized tool results mapped from UMM-T
`status`	Yes	Status of the tool execution
`total_hits`	No	Total number of matching items
`next_cursor`	No	Pagination token for the next page; None when no more results
`error_message`	No	Error details when status is error

Schema Changelog

Changes observed during successful MCP inspections.

First observedSep 11, 2026

TDQS

B3.1/5.0

Behavior3/5

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

Annotations already declare read-only, idempotent, open-world, non-destructive behavior, so the safety profile is covered. The description adds result-structure context, but the claim 'Paging is not supported' directly conflicts with the schema's cursor 'Pagination token' parameter and the limit max-50 rule, which misleads about behavior.

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

Conciseness3/5

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

The purpose is front-loaded and the sections are organized, but the long enumeration of returned fields largely duplicates what an existing output schema already provides, adding length without proportional value.

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?

With an output schema present, the field list is redundant, and the description leaves gaps around most parameters and gives inaccurate paging guidance. It does supply useful orientation on tool types, but is not complete enough to call the tool confidently.

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 40%, so the description carries substantial burden, yet it documents only collection_concept_id (and calls it 'required' when the schema marks it optional with a null default). The fields and keyword parameters are undocumented in both places, and limit/cursor are only explained by the schema itself.

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

Purpose4/5

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

The opening sentence states a specific verb (Search), resource (NASA CMR tools), and scope (associated with a specific parent collection). It is distinct from siblings like get_services, get_variables, and get_citations by resource type, though it never explicitly names them for contrast.

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?

Usage is implied by the scoping to a parent collection, and the closing Note hints at how to interpret multiple results by type. However, there is no explicit when-to-use vs alternatives (e.g., when to use get_services or get_collections instead), nor any stated preconditions or exclusions.

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

All NASA Earthdata MCP tools Inspect

Try in Browser

One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources

Need Help?