Provides access to the NASA Planetary Data System (PDS) Registry API for searching and exploring missions, celestial bodies, spacecraft, instruments, data collections, and product relationships.
Click on "Deploy Server".
Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state.
In the chat, type @ followed by the MCP server name and your instructions, e.g., "@NASA PDS Registry MCP Server Search for Mars rover Curiosity data products"
That's it! The server will respond to your query, and you can continue using it as needed.
Here is a step-by-step guide with screenshots.
An MCP server and reproducible evaluation of multistep natural-language search over the NASA Planetary Data System (PDS) Registry -- the digital data archive for all of NASA's planetary missions, flight and ground-based observations, and laboratory experiments from the 1960s to the present. With more than 1.85 petabytes from 70+ missions, 4,500 datasets, and 700 instruments all peer-reviewed by JPL and other research institutions.
Evaluation study · Results · Dataset · Data engine · Benchmark and reproducibility · MCP server · Development guide
https://github.com/user-attachments/assets/1d6b7035-c07a-4ca3-8bd2-9c19d68c3d5c
The NASA Planetary Data System (PDS) serves as a high-quality, hand-curated data source for the whole community of planetary research. However, searching the PDS Registry is difficult, requiring knowledge of exact PDS4 ontology fields and context identifiers to manually construct queries for its public search APIs. The research chain of scientific question -> experimentation -> findings/results is thus bottlenecked by current PDS search capabilities.
We introduce PDS-MCP, an agentic search interface on top of the NASA PDS Registry. From natural language questions, our agent can iteratively resolve PDS entities, inspect relationships, construct valid filters, and retrieve matching products autonomously constructing PDS API queries with no manual human intervention. We evaluate this on our 300-question benchmark, constructed from our scalable data engine, with results achieving 98.02% macro F1 and 95.67% exact result-set match on our full system, compared with 12.29% and 8.33% for single-call MCP and 0.33% on both metrics without PDS access, demonstrating that it can reliably bridge natural-language questions and structured PDS retrieval.
By releasing PDS-MCP publically, we aim to support the researchers of the Planetary Data Science community by making it easier to access NASA PDS data. Our goal is to provide enhanced search capabilities that enable more effective data exploration and improve accessibility for future research endeavors.
Related MCP server: NASA MCP Server
Can a language-model agent reliably translate natural-language planetary-data requests into complete PDS Registry result sets, and does multistep MCP search outperform the same model with one or zero PDS tool calls?
The benchmark dataset contains 300 independent questions:
Dimension | Coverage |
Multihop questions with two or three context constraints | 225 |
Single-constraint controls | 75 |
Archive-collection retrieval questions | 294 |
Context lookups | 6 |
Target result-set size | 1–98 PDS identifiers |
The complete benchmark data engine and its dataset documentation are included in this repository.
Ground truth was constructed as follows:
Select compatible PDS context objects → Build a PDS API query → Compile and execute it against the live PDS API → Save search results as target → Derive a natural-language questions as inputs
For each benchmark item,
input: the natural-language question
target: the desired search results (from the intermediary PDS query)
Thus, the job of the agent run on the benchmark is to use the NLQ to build a PDS API query (without knowledge of the original one used in the data engine) and get the target search results.
Condition | Model | PDS access | Purpose |
Baseline | GPT-5.6 Luna | None | The same LLM without PDS-MCP or access to the PDS search interface. |
Single-call MCP | GPT-5.6 Luna | At most one live MCP call | Tests whether tool availability without iterative search is sufficient. |
Multistep MCP (ours) | GPT-5.6 Luna | Iterative live MCP calls | Tests entity resolution, refinement, and collection retrieval. |
Condition | Macro precision | Macro recall | Macro F1 | Exact match | Mean calls | Mean latency |
Baseline | 0.33% | 0.33% | 0.33% | 0.33% | 0.00 | 8.00 s |
Single-call MCP | 13.62% | 11.71% | 12.29% | 8.33% | 1.01 | 29.86 s |
Multistep MCP (ours) | 98.18% | 97.97% | 98.02% | 95.67% | 5.28 | 47.24 s |
A request such as:
Find PDS collections from the New Horizons Kuiper Belt Extended Mission 1, collected by the Radio Science Experiment, targeting Arrokoth.
requires the agent to resolve several ontology objects before retrieving data:
Resolve the KEM1 investigation identifier.
Resolve the New Horizons REX instrument identifier.
Resolve Arrokoth and its PDS target identifier.
Search collections using the compatible investigation, instrument, and target constraints.
Return the complete normalized collection-identifier set.
This mirrors the work a user would otherwise perform manually when discovering PDS4 context identifiers and exact Registry filters.
Readers interested in the benchmark can start with the
research/data guide. The underlying
pds_research data engine samples compatible PDS entities,
builds and validates typed query plans, executes live API requests, and writes
the resulting questions and target identifier sets.
Artifact | Description |
Dataset documentation and links to its construction pipeline. | |
Questions, typed query plans, API requests, ground-truth identifiers, difficulty labels, and provenance. | |
Benchmark-generation, validation, query-compilation, and evaluation code. | |
Raw baseline predictions from the LLM without PDS-MCP or PDS search access. | |
Raw single-call predictions. | |
Raw multistep predictions. | |
Graph-ready aggregate comparison. | |
Machine-readable metrics and resource measurements. | |
Multistep hop-count distribution and exact accuracy by call count. | |
Headline, difficulty, retrieval-error, and trajectory-length figures in PNG and SVG formats. | |
Dependency-free script that regenerates the supporting SVG figures from committed metrics. |
Recompute identifier-set metrics with:
pds-research score \
research/data/main-300-live.jsonl \
research/results/codex-live-main-300-gpt-5.6-luna.jsonlSee DEVELOPMENT.md for environment setup, server execution, MCP client configuration, and test commands.
The FastMCP server in src/pds_mcp_server.py exposes
live PDS Registry operations for:
Investigation, target, instrument-host, and instrument search.
Context-product traversal.
Collection search by investigation, target, instrument, and host.
Detailed product retrieval by PDS identifier.
The server can be used from Claude Desktop, Cursor, Codex, or another MCP-compatible host. Setup instructions are in DEVELOPMENT.md.
Find Apollo 17 collections produced by the Lunar Surface Experiments Package Heat Flow Experiment and targeting the Moon.
Find InSight collections produced by the Auxiliary Payload Sensor Subsystem temperature and wind sensor and targeting Mars.
Find Cassini collections produced by the Imaging Science Subsystem Wide Angle camera and hosted on the Cassini Orbiter.
Find New Horizons KEM1 radio-science collections targeting Arrokoth.
These examples are drawn from the released benchmark; the complete set is
available in main-300-live.jsonl.
Code is released under the MIT License.
PDS Registry API: contact pds-operator@jpl.nasa.gov or open an issue in the
PDS API repository.
This server and study: open an issue in this repository.
Crawl a single PDS Context product and return other PDS Context products it is associated with. Ex. Mars 2020: Perseverance Rover (Investigation) is associated with Mars (Target) and Mastcam (Instrument), so it returns Mars and Mastcam.
WARNING: Takes a long time to run and performs several sequential API calls. Use wisely.
| Name | Required | Description | Default |
|---|---|---|---|
| urn | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must carry the behavioral burden, and it does disclose the most consequential trait: long runtime and several sequential API calls. It also implies a read (it 'returns' associated products). It stops short of stating auth requirements, failure behavior, or result size limits.
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 the verb and resource, followed by a compact illustrative example and a warning. Three sentences, each carrying information; the example is slightly verbose but justifies its length by clarifying the associative return.
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?
There is no output schema or annotation, yet the description conveys what is returned (associated products) and the cost profile, which is sufficient for a single-parameter tool. The URN input itself remains unexplained, which is the main incompleteness.
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 0% and there is one parameter, 'urn'. The description never explains what a URN is, its format, or where to obtain one, only naming PDS product types (Investigation/Target/Instrument) inside an example. Since coverage is low, the description should have compensated and largely does not.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb (crawl) and resource (a single PDS Context product) plus what is returned (other associated products). The Mars 2020 example makes the operation concrete and clearly separates it from the search_* and get_product siblings.
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 WARNING ('takes a long time... use wisely') implies this is an expensive operation to invoke sparingly, which is contextual guidance. However, it never says when to prefer this over get_product or the search_* tools, nor does it give a precondition for choosing this tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get a single PDS product by its URN identifier.
| Name | Required | Description | Default |
|---|---|---|---|
| urn | Yes |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. 'Get' implies a read, but there is nothing about permissions, whether an unknown URN errors or returns empty, or any rate/access constraints. For a zero-annotation tool this is a thin 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?
One short sentence, front-loaded with the verb and resource, with zero filler. Appropriate size for a single-parameter lookup tool.
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 return values need not be explained, and one simple required parameter keeps the surface small. However, with no annotations and no note on lookup failure behavior or what a 'PDS product' encompasses, it is only minimally complete.
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 0% for the single 'urn' parameter, so the description must compensate. It only restates that the identifier is a 'URN', which the parameter name already conveys, adding no format, source, or example detail.
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 ('Get a single PDS product') plus the lookup key ('by its URN identifier'). This distinguishes it from the search_* siblings by being a direct-by-id fetch, though it never names or contrasts those alternatives explicitly.
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?
No when-to-use guidance at all. With siblings like search_investigations, search_collections, and crawl_context_product available, the description never says when to prefer this exact-URN fetch over a search or crawl, leaving the agent to infer the routing.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Search PDS data collections filtered by instrument, target, instrument host, or investigation. Example: Mars Reconnaissance Orbiter HiRISE data collections targeting Mars.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | Max results (default 10) | |
| ref_lid_target | No | URN identifier for target (e.g. urn:nasa:pds:context:target:planet.mars) | |
| ref_lid_instrument | No | URN identifier for instrument (e.g. urn:nasa:pds:context:instrument:mars2020.mastcamz) | |
| ref_lid_investigation | No | URN identifier for investigation (e.g. urn:nasa:pds:context:investigation:mission.mars2020) | |
| ref_lid_instrument_host | No | URN identifier for instrument host (e.g. urn:nasa:pds:context:instrument_host:spacecraft.mars2020) |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full behavioral burden. It never states that this is a read-only lookup, how filters combine (AND vs OR), how the limit interacts with result sets, or any rate/auth constraints — 'search' implies read-only but nothing is 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?
Two sentences, front-loaded with the purpose and followed by a single illustrative example; nothing is padded. The example sentence earns its place by grounding abstract filter names in a real query.
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 return values need no explanation, and all 0-required params are documented in the schema. However, for a 5-parameter search tool with five sibling search tools, the description omits filter-combination behavior, result-set size expectations, and routing guidance — leaving meaningful gaps.
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 100% with URN examples for each ref_lid_* parameter, so the schema already does the heavy lifting. The description's filter list mirrors the parameter names and adds no URN syntax or combination semantics beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb and resource (search PDS data collections) and enumerates the four filter dimensions, which maps directly onto the schema. It is clearly distinguishable from siblings like search_investigations or search_targets, which operate on different context entity types, though it never names them explicitly.
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 concrete example ('Mars Reconnaissance Orbiter HiRISE data collections targeting Mars') implies a usage scenario and shows how filters combine, but there is no explicit when-to-use/when-not guidance and no mention of the sibling search_* tools that cover adjacent entity types.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Search PDS Context products that are Instrument Hosts (spacecraft, rovers, telescopes).
Instrument Hosts are platforms that carry scientific instruments: spacecraft, rovers, landers, telescopes. Example: Cassini Orbiter - urn:nasa:pds:context:instrument_host:spacecraft.cassini
Use for queries about specific spacecraft, rovers, or platforms that carry instruments.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | Max results (default 10) | |
| keywords | No | Space-delimited search terms (e.g. 'mars rover', 'voyager spacecraft') | |
| instrument_host_type | No | Filter by type (found in resource://instrument_host_type) |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the burden; 'Search' implies a safe read, but nothing is said about result limits, ordering, or whether the call can fail on bad input. It adds useful context via the example URN and by declaring what an instrument host is, but not richer behavioral traits.
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 and definition are front-loaded, and the usage sentence comes last. It is slightly repetitive, restating 'spacecraft, rovers, telescopes' twice and re-explaining 'platforms that carry instruments'.
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 return values need not be explained, and 100% schema coverage means parameters are handled. The description supplies the domain concept plus example URN, which is enough for an agent to use this correctly; only explicit sibling routing 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 100%, so all three parameters (limit, keywords, instrument_host_type) are already documented in the schema, including format hints. The description adds no parameter-level detail beyond that baseline.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb and resource ('Search PDS Context products that are Instrument Hosts') and then defines the resource precisely, including an example URN. The framing 'platforms that carry scientific instruments' implicitly separates it from the sibling search_instruments, so an agent can pick correctly without opening a schema.
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 final sentence gives clear positive guidance ('Use for queries about specific spacecraft, rovers, or platforms that carry instruments') and the keywords examples ('mars rover', 'voyager spacecraft') reinforce the intended context. There are no explicit exclusions or named alternatives, so it falls short of a 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Search the latest-versioned instances of PDS Context products that are Instruments.
Instruments are scientific devices (cameras, spectrometers, etc.) used on spacecraft to collect data. Example: Cassini RADAR - urn:nasa:pds:context:instrument:radar.cassini
Use for queries about specific instruments, instrument types, or instruments on missions/spacecraft.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | Max results (default 10) | |
| keywords | No | Space-delimited search terms (e.g. 'camera mars', 'spectrometer cassini') | |
| instrument_type | No | Filter by type (found in resource://instrument_type) |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It usefully discloses the versioning scope ("latest-versioned instances"), which is real behavioral context, but says nothing about pagination, ordering, result size limits, or auth requirements. Adequate but leaves notable gaps for an unannotated 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?
Three short blocks, front-loaded with the core definition, no repetition or filler. Every sentence earns its place by either defining the resource, giving an example, or specifying when to use it.
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 return values need not be explained, and all parameters are documented. The description supplies the domain definition and example URN that an agent needs to interpret results. Only minor gaps remain around result ordering and empty-result behavior.
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 100%, so all three parameters are already documented with examples in the schema. The description alludes to instrument types and mission/spacecraft phrasing that maps to keywords, but adds no syntax, format, or matching-behavior detail beyond the schema. Baseline 3 applies.
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 (latest-versioned PDS Context products that are Instruments), then defines the domain term and gives a concrete example URN. An agent can distinguish this from search_instrument_hosts and search_targets purely from the description.
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 for queries about specific instruments, instrument types, or instruments on missions/spacecraft" gives clear triggering contexts, with each clause mapping loosely to the available parameters. It stops short of naming alternatives or exclusions, e.g. routing host/spacecraft queries to search_instrument_hosts.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Search PDS Context products that are Investigations (missions/projects).
Investigations are organized missions or projects that collect scientific data. Example: Cassini-Huygens - urn:nasa:pds:context:investigation:mission.cassini-huygens
Use for queries about space missions, mission timelines, or finding missions that studied specific targets.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | Max results (default 10) | |
| keywords | No | Space-delimited search terms (e.g. 'mars rover', 'jupiter cassini') |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the burden. 'Search' implies a read-only, non-destructive operation, and an output schema covers the response shape, but nothing is said about result ordering, pagination behavior beyond the limit param, or data source freshness.
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 the core purpose, then a definition, an example, and use cases. Four short lines, each earning its place, though the full URN example is slightly more verbose than needed for selection.
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 simple two-parameter search tool with a full output schema and 100% schema coverage, the description covers purpose, definition, and usage contexts adequately. The main remaining gap is explicit routing against the five sibling search tools.
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 100%, so both parameters (limit, keywords) are already documented with defaults and a keyword syntax example. The description adds no further parameter-level detail, so the baseline 3 applies.
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 PDS Context products that are Investigations'), then defines what an Investigation is (missions/projects) with a concrete URN example. This makes the resource distinguishable in practice from search_targets/search_instruments, though no sibling is named explicitly.
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 says when to use it: 'queries about space missions, mission timelines, or finding missions that studied specific targets.' Clear positive context, but no exclusions or named alternatives to disambiguate from the other search_* tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Search PDS Context products that are Targets (celestial bodies, phenomena).
Targets are objects of scientific study: planets, moons, asteroids, comets, etc. Example: Mars - urn:nasa:pds:context:target:planet.mars
Use for queries about specific celestial bodies, finding targets by type, or targets studied by missions.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | Max results (default 10) | |
| keywords | No | Space-delimited search terms (e.g. 'jupiter moon', 'asteroid belt') | |
| target_type | No | Filter by type (found in resource://target_type) |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full behavioral burden. It establishes that this is a read/search operation and clarifies the domain vocabulary, but says nothing about matching semantics, pagination, result ordering, or empty-result behavior. Output schema exists, so return values need not be explained, but other traits remain undisclosed.
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?
Four short sentences, front-loaded with the core purpose before the definition and usage guidance. The Mars URN example is compact and genuinely useful for grounding the identifier format; overall there is very little waste.
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 and 100% parameter coverage, the description only needs to establish domain and usage, which it does well, including a canonical identifier example. The remaining gap is behavioral (pagination/result limits) rather than conceptual.
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 100%, so limit, keywords, and target_type are already fully documented in the schema, including the resource://target_type reference. The description's mention of 'finding targets by type' and the Mars URN example add domain flavor but no syntax or format beyond what the schema supplies. Baseline 3 is appropriate.
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 PDS Context products that are Targets') and then defines the resource domain ('planets, moons, asteroids, comets') with a concrete URN example. This definitional detail implicitly separates it from siblings like search_instruments and search_investigations, but no sibling is named explicitly.
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 final sentence gives clear usage contexts: queries about specific celestial bodies, finding targets by type, or targets studied by missions. It stops short of naming an alternative tool or stating when NOT to use this one, so it is a 4 rather than a 5.
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.
v0.2.0crawl_context_productget_productsearch_collectionssearch_instrument_hostssearch_instrumentssearch_investigationssearch_targetsScored across 7 tools
The four search_* tools map cleanly onto distinct PDS Context product types (Investigations, Targets, Instrument Hosts, Instruments), and descriptions reinforce the boundaries. crawl_context_product, search_collections, and get_product each target clearly different operations, leaving little room for misselection.
All tool names follow a predictable verb_noun snake_case pattern (search_investigations, crawl_context_product, get_product). The search_ prefix is used consistently for the five query tools, and the verb choices accurately reflect each operation.
Seven tools is well-scoped for a specialized registry query server, with each tool earning its place by covering a distinct resource or operation. Nothing feels redundant or missing count-wise.
Core workflows are covered: search across the four context types, search collections, traverse associations, and fetch by URN. Minor gaps exist—no dedicated search_products or bundle search, and the only product retrieval is by exact URN, but agents can largely work around these.
Discover, verify, and access NASA Earth science datasets via the Common Metadata Repository (CMR)
Public tools to understand Dynamik, discover datasets, and connect account-scoped capabilities.
NASA MCP — wraps NASA Open APIs (api.nasa.gov)
Gateway between LLM agents and world data through eight tools and a bundled endpoint catalog.
