Discover, verify, and access NASA Earth science datasets via the Common Metadata Repository (CMR)
Scored across 7 tools
Each tool maps to a distinct CMR entity type (collections, granules, citations, keywords, services, tools, variables), eliminating overlap. get_collections versus get_granules is a clear parent-child split, and all other tools operate on separate resource classes.
All seven tools follow the same verb_noun snake_case pattern with the get_ prefix. There are no mixed conventions or ambiguous verbs.
Seven tools is well-scoped for a read-only NASA CMR discovery server. Each tool covers a distinct entity, and none feels redundant or missing from the set.
The surface covers the main CMR discovery entities: collections, granules, variables, services, tools, citations, and keyword vocabulary. Minor gaps exist, such as retrieving a single granule or citation by concept_id without a parent collection, and no provider-level metadata tool.
Discover citation records directly associated with a collection, or look up a citation by identifier (e.g. DOI). Use this tool to evaluate citation relevance for a collection.
Key fields in each returned item:
concept_id: CMR citation concept ID
name: The title or name of the citation
identifier: The primary DOI or identifier
abstract: Abstract text
citation_metadata: Nested metadata including Year, Publisher, and Author list
| Name | Required | Description | Default |
|---|---|---|---|
| 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 | ||
| provider | No | ||
| identifier | No | ||
| collection_concept_id | No |
| Name | Required | Description |
|---|---|---|
| status | Yes | Status of the tool execution |
| citations | No | Normalized citation results mapped from UMM-Citations |
| 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 |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations at all, the description carries the full disclosure burden, yet it says nothing about read-only safety, permissions/authentication, pagination limits, or rate behavior. It pivots immediately to listing returned fields, which is output content rather than behavioral disclosure.
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?
Purpose is front-loaded in a single efficient sentence, which is good. The subsequent bulleted list of key return fields largely duplicates the existing output schema, spending real estate on information the agent already has.
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 tool has six parameters at 0% required, 33% schema coverage, and no annotations, so the description should clarify query construction and mode selection. Instead it details return fields that the output schema already covers, leaving the calling semantics under-specified.
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%, so the description needs to compensate — and it does not. It alludes to 'identifier (e.g. DOI)' and 'associated with a collection,' but is silent on limit, cursor, fields, and provider, leaving more than half the parameters undocumented in both places.
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 opens with a concrete verb+resource ('Discover citation records') and distinguishes two access modes: association with a collection vs. lookup by identifier (e.g. DOI). It is clearly the citation-oriented sibling among get_collections/get_granules/get_variables, though it never explicitly contrasts itself with them.
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?
'Use this tool to evaluate citation relevance for a collection' gives an implied use case, and the two modes hint at when each applies. However, there is no explicit when-not guidance, no mention of prerequisites, and no routing to alternatives for citation lookup vs. collection-scoped discovery.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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
| Name | Required | Description | Default |
|---|---|---|---|
| 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 | Free-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. | |
| platform | No | ||
| provider | No | Data 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_id | No | Exact CMR concept ID (format: C<number>-<PROVIDER>, e.g., C2036882064-POCLOUD). Use for direct lookup of a known collection. | |
| instrument | No | ||
| short_name | No | Collection short name (e.g., MOD11A1, SPL3SMP, MUR-JPL-L4-GLOB-v4.1). Exact match by default; wildcards * and ? are supported. | |
| has_granules | No | When True, filters to collections that have actual granule data. Prevents returning metadata-only shells. | |
| temporal_end_date | No | End 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_id | No | ||
| temporal_start_date | No | Start 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_geometry | No | Spatial 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. |
| Name | Required | Description |
|---|---|---|
| status | Yes | Status of the tool execution |
| total_hits | No | Total number of matching items |
| collections | No | Normalized collection results mapped from UMM-C |
| next_cursor | No | Pagination token for the next page of results |
| error_message | No | Error details when status is error |
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.
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.
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.
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.
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.
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.
Search NASA CMR granules for a specific parent collection and return up to 10 lightweight normalized results.
Key return fields in each item:
concept_id: CMR granule concept ID
native_id: native ID of the granule record
revision_id: revision ID of the granule metadata
provider_id: provider ID of the granule
granule_ur: primary granule identifier
time_start / time_end: temporal coverage bounds
access_urls: actionable data access URLs
cloud_cover: cloud cover percentage
day_night_flag: DAY, NIGHT, BOTH, or UNSPECIFIED
size_mb: file size in megabytes
data_format: file format (e.g., NetCDF-4, GeoTIFF)
bounding_box: [West, South, East, North] Minimum Bounding Rectangle (MBR) footprint. Note: for swath data or irregular polygons, this bounding box fully encloses the data but may contain empty space at the corners.
IMPORTANT — data availability checks: Without temporal and/or spatial filters, results represent ALL granules ever archived in the collection, which may span decades and the entire globe. total_hits without filters tells you the full archive size, NOT whether data exists for a specific area or time period. To verify availability for a specific region and/or period, apply the corresponding spatial or temporal filters. Single-filter queries (e.g., temporal-only) are completely valid and should be used when the user only specifies one constraint, but combining both provides the most precise availability answer.
Key parameters:
collection_concept_id: required parent collection concept ID
temporal_start_date / temporal_end_date: filter to granules overlapping this time window — always set when the user specifies a time period
spatial_wkt_geometry: filter to granules intersecting this area — always set when the user specifies a geographic region
cloud_cover_min / cloud_cover_max: filter optical imagery by cloud cover percentage (0–100). Only set for optical/visible imagery collections (Landsat, MODIS, VIIRS, Sentinel-2 via CMR). Do NOT set for non-optical data (SAR, altimetry, model output, etc.)
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 query by adding tighter spatial or temporal constraints.
Tips:
For the most precise availability check, provide both temporal and spatial filters if the user specifies both; otherwise, apply whichever constraint they provided
total_hits in the response reflects the filtered count — zero means no data for that combination
When users ask for "clear" or "cloud-free" imagery, set cloud_cover_max to a low value (e.g., 10 or 20)
| Name | Required | Description | Default |
|---|---|---|---|
| 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 | ||
| sort_key | No | Sort key for granule results. e.g., '-start_date' (newest first), 'start_date' (oldest first). CMR default is relevance score. For ongoing or near-real-time (NRT) missions where the user wants the most recent data, always use '-start_date' — CMR's default relevance scoring may return historical data first if sort_key is not explicitly set. | |
| day_night_flag | No | Filter granules by day/night acquisition flag. Values: 'DAY', 'NIGHT', 'UNSPECIFIED'. | |
| cloud_cover_max | No | Maximum cloud cover percentage (0–100, inclusive). Use with cloud_cover_min to filter optical/visible imagery granules by cloud cover. For example, set cloud_cover_max=20 to find mostly clear scenes. Only applicable to collections that report cloud cover (e.g., Landsat, MODIS, etc). Omit for non-optical data (SAR, altimetry, etc.). | |
| cloud_cover_min | No | Minimum cloud cover percentage (0–100, inclusive). Use with cloud_cover_max to filter optical/visible imagery granules by cloud cover. Only applicable to collections that report cloud cover (e.g., Landsat, MODIS, etc). Omit for non-optical data (SAR, altimetry, etc.). | |
| temporal_end_date | No | End of temporal filter in ISO 8601 format (e.g., 2024-01-31T23:59:59Z). Finds granules whose temporal extent overlaps this window. Set this whenever the user specifies a time period — omitting it returns granules from the entire collection archive regardless of date. | |
| temporal_start_date | No | Start of temporal filter in ISO 8601 format (e.g., 2024-01-01T00:00:00Z). Finds granules whose temporal extent overlaps this window. Set this whenever the user specifies a time period — omitting it returns granules from the entire collection archive regardless of date. | |
| spatial_wkt_geometry | No | Spatial filter as WKT geometry. Supported types: POLYGON((lon lat, ...)), POINT(lon lat), or LINESTRING(lon lat, ...).Finds granules with spatial extent intersecting this area. CMR returns any granule 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 granules from the entire globe regardless of location. | |
| collection_concept_id | Yes | Parent collection concept ID (format: C<number>-<PROVIDER>, e.g., C2723758340-GES_DISC). Required to scope granule search. |
| Name | Required | Description |
|---|---|---|
| status | Yes | Status of the tool execution |
| granules | No | Normalized granule results mapped from UMM-G |
| total_hits | No | Total number of matching items |
| next_cursor | No | Pagination token for the next page of results |
| error_message | No | Error details when status is error |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnly/idempotent/non-destructive, and the description adds substantial behavior beyond them: the 10-item cap, the total_hits semantics ('full archive size, NOT whether data exists'), and filter-interaction rules. However, 'Results are strictly capped at 10 items... do not attempt to page' sits awkwardly against the schema's limit parameter (max 50) and cursor parameter, creating ambiguity about actual paging behavior.
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?
Front-loaded with purpose, then organized under clear headers (return fields, parameters, iteration, tips), so it is scannable. It is nonetheless long and repeats schema content, e.g., the temporal filter explanation appears both in the body and in temporal_start_date's schema description.
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?
Covers filters, limits, availability semantics, and refinement strategy, which is more than enough for an 11-parameter tool. Since an output schema exists, the enumerated return fields are somewhat redundant, and the cap-versus-limit/cursor tension leaves a small gap about how to legitimately retrieve more than 10 results.
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 91%, so the baseline is 3, but the description adds intent-to-parameter mapping the schema lacks: which filters to set given what the user specified, the temporal+spatial combination rule, and the practical tip to set cloud_cover_max to 10-20 for 'clear' imagery requests. Much of the per-parameter text overlaps the schema, limiting it to a 4.
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?
States a specific verb and resource ('Search NASA CMR granules for a specific parent collection') and the scope ('up to 10 lightweight normalized results'). It is clearly distinguishable from siblings like get_collections, which operate at the collection rather than granule level.
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?
Explicit when-to-use guidance throughout: always set temporal/spatial filters when the user specifies those constraints, single-filter queries are valid, cloud_cover filters must NOT be set for non-optical data, and refinement (not paging) is prescribed when total_hits exceeds 10. Alternatives and exclusions are named rather than implied.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Discover official Earthdata vocabulary (like 'ATMOSPHERIC WATER VAPOR') directly from NASA's Keyword Management System (KMS). Use this to find the exact preferred labels to construct successful get_collections searches.
Key fields in each returned item:
prefLabel: The preferred label to use in searches
uuid: The KMS concept UUID
definition: Context and expanded acronyms
scheme: The vocabulary scheme (e.g. sciencekeywords, platforms)
| Name | Required | Description | Default |
|---|---|---|---|
| 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. | |
| query | Yes | ||
| 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 | ||
| scheme | No |
| Name | Required | Description |
|---|---|---|
| status | Yes | Status of the tool execution |
| keywords | No | List of matched KMS terms |
| 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 |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations, so the description carries full behavioral burden. It usefully explains the returned structure and confirms a read-only discovery character, but says nothing about ranking, matching behavior, or how broad a 'query' should be. A solid but not rich disclosure for a no-annotation tool.
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?
Opens with the core purpose sentence, then a clean field glossary. Well front-loaded, though the field list duplicates what an output schema already encodes, so a small amount is non-essential.
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?
Since an output schema exists, the description needn't explain return values, yet it helpfully glosses key fields to interpret them. Combined with the sibling routing note, it is nearly complete; only the vague query/fields semantics leave an agent with a minor open question.
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 40%: limit and cursor are well-documented in the schema, but query, fields, and scheme have no schema descriptions. The description covers query indirectly via the 'exact preferred labels' framing and names scheme values (sciencekeywords, platforms), partially compensating, yet fields and query syntax remain unexplained.
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?
States a specific verb+resource ('Discover official Earthdata vocabulary... from NASA's Keyword Management System'), names the exact system behind it, and explicitly distinguishes its role relative to a sibling ('to construct successful get_collections searches').
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?
Gives clear intended context (finding exact preferred labels before searching) and points to the related get_collections search. Contains no explicit when-not-to-use framing or query-scoping caveats that belong to this workflow.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Search NASA CMR services for a specific parent collection and return all associated normalized UMM-S records.
Key fields in each returned item:
concept_id: CMR service concept ID
native_id: native ID of the service record
revision_id: revision ID of the service metadata
provider_id: provider ID of the service
name: service name
type: service type (e.g., OPeNDAP, WCS, Harmony, WMS, WMTS, ESI, EGI - No Processing)
version: service version string
description: human-readable service description
url: Primary endpoint URL information
service_options: supported output formats, projections, subset types, and interpolation methods
operation_metadata: operation names (e.g., GetCapabilities, GetMap) and distributed computing platform
Key parameters:
collection_concept_id: required parent collection concept ID
Iteration & Refinement:
All services associated with the collection are fetched in a single request. Paging is not supported.
Note: A collection may be associated with multiple services of different types. Check type to distinguish between data access services (e.g., OPeNDAP, WCS) and discovery/visualization services (e.g., WMS, WMTS).
| Name | Required | Description | Default |
|---|---|---|---|
| type | No | ||
| 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 |
| Name | Required | Description |
|---|---|---|
| status | Yes | Status of the tool execution |
| services | No | Normalized service results mapped from UMM-S |
| total_hits | No | Total number of matching items |
| next_cursor | No | Pagination token for the next page |
| error_message | No | Error details when status is error |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already cover the read-only/idempotent/non-destructive profile, but the description adds real behavioral context: all services for a collection come back in a single request and paging is not supported. That said, this note sits awkwardly against the schema's limit/cursor pagination parameters, creating minor internal tension.
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?
Well front-loaded and sectioned, but the ten-item 'Key fields in each returned item' list is largely redundant given an output schema exists, and the 'required' parameter claim conflicts with the schema. The list consumes tokens without adding value an agent cannot get from the output schema.
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?
Purpose is complete and the no-paging behavior is disclosed, but with an output schema present the field enumeration is redundant, most parameters are undocumented, and the 'paging is not supported' statement contradicts the presence of limit/cursor params an agent may try to use.
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 only 33% (limit and cursor are documented). The description adds meaning for collection_concept_id ('parent collection concept ID'), which the schema leaves untyped, but it labels it 'required' while the schema declares zero required parameters, and it says nothing about type, keyword, or fields.
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?
States a specific verb (search) and resource (NASA CMR services) scoped to a parent collection, and names the return type (normalized UMM-S records). This clearly distinguishes it from siblings like get_collections, get_granules, and get_tools.
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 scope 'for a specific parent collection' implies when the tool applies, and the closing note about distinguishing data-access vs discovery/visualization service types is helpful context. However, there is no explicit when-to-use/when-not guidance nor any named alternative tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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.
| Name | Required | Description | Default |
|---|---|---|---|
| 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 |
| 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 |
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.
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.
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.
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.
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.
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.
Discover scientific variables and measurements associated with a collection, or look up variables by keyword. Use this tool to understand dataset variables, dimensions, and data processing parameters (such as scale, offset, and fill values) before downloading or analyzing data.
Key fields in each returned item:
concept_id: CMR variable concept ID
name: Variable short name
long_name: Variable long name
definition: Variable definition
data_type: Data type of the variable
units: Units of measurement
scale: Scale factor
offset: Offset value
fill_values: Values indicating missing or invalid data
valid_ranges: Valid data ranges
dimensions: Variable dimensions
| Name | Required | Description | Default |
|---|---|---|---|
| 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 |
| Name | Required | Description |
|---|---|---|
| status | Yes | Status of the tool execution |
| variables | No | Normalized variable results mapped from UMM-V |
| 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 |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must carry the behavioral burden. It implies a read-only discovery/lookup operation and enumerates the returned fields, but says nothing about permissions, whether cursors are query-scoped (left to the schema), or result ordering. The behavior is inferable but not fully disclosed.
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 opening sentences are well front-loaded, but the ten-line bullet list of return fields largely duplicates the existing output schema and consumes substantial space without adding selection guidance. Roughly half the text is redundant with structured data.
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?
An output schema exists, so the field glossary is not strictly necessary; the more valuable missing content is how to choose between keyword and collection lookups and what the fields parameter does. Adequate for a simple read tool, but leaves real gaps for a 5-parameter 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 40%, so the description must compensate. It clarifies the keyword lookup mode, but says nothing about 'fields' semantics beyond the vague phrase 'key fields,' and nothing about collection_concept_id or how the two lookup modes interact. The richer parts of the schema (limit, cursor) already carry their own 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 names a specific resource (scientific variables/measurements) and two concrete retrieval modes (by collection, by keyword), so an agent knows exactly what it returns. It does not explicitly contrast itself with siblings like get_collections or get_granules, so it falls short of the 5-level sibling differentiation bar.
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?
It gives a clear usage context: 'understand dataset variables, dimensions, and data processing parameters ... before downloading or analyzing data,' which tells the agent when this tool belongs in a workflow. It stops short of naming alternatives or stating when not to use it (e.g., when only collection metadata is needed).
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.
get_citationsget_collectionsget_granulesget_keywordsget_servicesget_toolsget_variablesIEEE Xplore MCP — BYOK wrapper over the IEEE Xplore Metadata Search API
Geospatial AI MCP server — satellite imagery, embeddings, weather, GNS governance
Search public Australian environmental evidence with provenance across authoritative catalogues.
