Skip to main content
Glama

get_collections

Read-onlyIdempotent

Search NASA CMR collections and return up to 10 lightweight normalized results.

Key return fields in each item:

  • concept_id: CMR collection concept ID

  • native_id: native ID of the collection record

  • revision_id: revision ID of the collection metadata

  • provider_id: provider ID of the collection

  • short_name: collection short name

  • entry_title: collection title

  • time_start / time_end: temporal coverage bounds

  • processing_level_id: processing level (e.g., L3, L4)

  • doi: digital object identifier

  • collection_data_type: data type (e.g., SCIENCE_QUALITY, NEAR_REAL_TIME)

  • temporal_resolution / spatial_resolution: extracted resolution strings

  • related_urls: links to landing pages, documentation, and tools

Unfiltered searches are supported when you need broad exploration.

IMPORTANT — relevance and coverage: A keyword-only search returns all collections whose metadata mentions those terms, regardless of whether they actually hold data for the user's region or time period. Collection declared extents are often global or multi-decadal, so a collection appearing in results does not mean it has granules for a specific area or date. When the user's question involves a time period or geographic region, include temporal_start_date/temporal_end_date and/or spatial_wkt_geometry to restrict results to collections that overlap that window. Follow up with get_granules (with the same filters) to confirm actual data availability.

IMPORTANT — keyword AND logic: CMR treats each space-separated keyword as an independent term and requires ALL of them to appear somewhere in a collection's metadata (title, summary, science keywords, instruments, platforms, etc.). Words do not need to appear in the same field or adjacent to each other. Because every term must match, adding more words makes the search STRICTER, not broader — the opposite of typical web search engines. Prefer 2–4 precise scientific terms. If a search returns 0 results, try removing the least essential word before broadening other filters. Phrase search (exact word sequence) is available by wrapping the value in escaped double quotes, but you cannot mix a phrase with additional standalone keywords.

Key parameters:

  • keyword: free-text keyword search over collection metadata (AND logic; see above)

  • concept_id: exact collection concept ID

  • short_name: collection short name

  • provider: data provider short name

  • temporal_start_date / temporal_end_date: restrict to collections whose declared range overlaps this window; set when the user specifies a time period

  • spatial_wkt_geometry: restrict to collections whose declared extent intersects this area; set when the user specifies a geographic region

Iteration & Refinement:

  • Results are strictly capped at 10 items to optimize context window usage.

  • If total_hits exceeds 10 and you lack the necessary results, do not attempt to page. Refine your search by adding tighter spatial, temporal, or keyword constraints.

Tips:

  • Use scientific terms (variables, instruments, platforms) for better keyword relevance

  • Keep keyword queries to 2–4 precise terms; more words = stricter filter

  • If 0 results, drop the least essential keyword and retry before broadening other filters

  • Combine keyword + temporal + spatial filters for highest precision

  • Use short_name when you already know the target product

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
limitNoMaximum 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.
cursorNoPagination 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.
fieldsNo
keywordNoFree-text keyword search. Case insensitive. IMPORTANT — CMR uses AND logic: each space-separated word is matched independently and ALL words must appear somewhere in a collection's indexed fields (title, summary, short name, GCMD science keywords, platform and instrument names, project names, processing level, archive centers, additional attributes, etc.). Words do NOT need to appear in the same field or as a contiguous phrase. Because every word must match, adding more words makes the search STRICTER, not broader — the opposite of typical web search engines. Prefer 2–4 precise terms over long queries. Example: 'soil moisture' (2 terms, broad) vs 'soil moisture SMAP L3' (4 terms, narrow). Phrase search: wrap the entire value in escaped double quotes to require an exact phrase (e.g., '\"sea surface temperature\"'). Only a single phrase is supported; you cannot mix a phrase with additional standalone words. Wildcards supported: * (zero or more chars), ? (any single char). Use scientific terms: geophysical variable names ('sea surface temperature', 'soil moisture'), instrument names (MODIS, ASCAT, VIIRS, AIRS, Landsat, etc.), or platform names (Terra, Aqua, SMAP, Sentinel-1, etc.). For known product short names use the short_name parameter instead.
platformNo
providerNoData provider short name (e.g., PODAAC, NSIDC_ECS, GES_DISC, ORNL_DAAC, LAADS, GHRC_DAAC, ASDC). Restricts results to collections from that provider. WARNING: NASA DAACs are actively migrating assets to the cloud under new provider IDs (e.g., LPDAAC_ECS → LPCLOUD, PODAAC → POCLOUD). If you know the exact short_name of a product, do NOT include the provider parameter — a stale provider ID will silently return 0 results. Use provider only when the user explicitly filters by archive center.
concept_idNoExact CMR concept ID (format: C<number>-<PROVIDER>, e.g., C2036882064-POCLOUD). Use for direct lookup of a known collection.
instrumentNo
short_nameNoCollection short name (e.g., MOD11A1, SPL3SMP, MUR-JPL-L4-GLOB-v4.1). Exact match by default; wildcards * and ? are supported.
has_granulesNoWhen True, filters to collections that have actual granule data. Prevents returning metadata-only shells.
temporal_end_dateNoEnd of temporal filter in ISO 8601 format (e.g., 2020-12-31T23:59:59Z). Restricts results to collections whose declared temporal range overlaps this window. Set this whenever the user specifies a time period — omitting it returns collections regardless of when their data was collected.
processing_level_idNo
temporal_start_dateNoStart of temporal filter in ISO 8601 format (e.g., 2020-01-01T00:00:00Z). Restricts results to collections whose declared temporal range overlaps this window. Set this whenever the user specifies a time period — omitting it returns collections regardless of when their data was collected.
spatial_wkt_geometryNoSpatial filter as WKT geometry. Supported types: POLYGON((lon lat, ...)), POINT(lon lat), or LINESTRING(lon lat, ...).Restricts results to collections whose declared extent intersects this area. CMR returns any collection that touches this shape, so precise geometries are preferred to prevent false positives. Set this whenever the user specifies a geographic region — omitting it returns collections with global or unspecified coverage.

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault
statusYesStatus of the tool execution
total_hitsNoTotal number of matching items
collectionsNoNormalized collection results mapped from UMM-C
next_cursorNoPagination token for the next page of results
error_messageNoError details when status is error

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observed

TDQS

A4.5/5.0
Behavior4/5

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

Goes well beyond the readOnly/idempotent annotations by disclosing the non-obvious CMR AND keyword logic, the 10-item result cap, and that collections appearing in results may not have granules for a given region/time. Minor inconsistency: the body says results are 'strictly capped at 10' and 'do not attempt to page', while the schema exposes a limit up to 50 and a cursor parameter.

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?

Headings make it skimmable, but there is meaningful duplication: the 11 return fields are listed even though an output schema exists, and the AND-logic explanation appears in both the body and the keyword param description. The 10-result cap claim also needs reconciling with the limit/cursor params, so the length is not entirely earned.

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?

For a 14-parameter open-world search tool, it covers the failure modes an agent actually hits: filter semantics, AND-logic surprise, zero-result recovery, refinement over paging, and the handoff to get_granules. Return values need not be enumerated further given the output schema, so nothing essential is missing.

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?

Schema coverage is 71%, and the description adds real meaning on top of it: the rationale for temporal_start_date/temporal_end_date and spatial_wkt_geometry (overlap/intersection semantics, not availability), why provider should be omitted when short_name is known, and how to formulate keyword values. It does not restate every param, but the key discriminators are covered.

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?

Opens with a specific verb+resource ('Search NASA CMR collections') and immediately states output shape ('up to 10 lightweight normalized results'). It also names the downstream sibling (get_granules) so the agent can distinguish collection-level search from granule-level lookup.

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

Usage Guidelines5/5

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

Explicitly covers when to search unfiltered ('broad exploration') versus when to add temporal/spatial filters, and tells the agent to confirm data availability with get_granules using the same filters. It also gives a concrete recovery rule for zero-result searches (drop the least essential keyword) and guidance on short_name vs keyword.

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

Try in Browser

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources