NASA MCP Server

JPL close approaches

jpl_cad

Read-onlyIdempotent

Retrieve past and future close approaches of asteroids and comets to planets, filtered by date, distance, body, or NEO status, using JPL SBDB data.

Instructions

Asteroid and comet close approaches to the planets, past and future, from the JPL SBDB Close-Approach Data API.

Input Schema

Name	Required	Description
`des`	No	Only this object (designation).
`neo`	No	Limit to NEOs (default true upstream).
`spk`	No	Only this object (SPK-ID).
`body`	No	Close-approach body (Earth, Mars, ALL, ...). Default Earth.
`sort`	No	Sort field, prefix - for descending. Default date.
`h_max`	No	Maximum absolute magnitude H.
`h_min`	No	Minimum absolute magnitude H.
`limit`	No	Maximum number of records (1-1000).
`date_max`	No	End date (YYYY-MM-DD, now, or +/-days). Default +60.
`date_min`	No	Start date (YYYY-MM-DD, now, or +/-days). Default now.
`dist_max`	No	Maximum approach distance, e.g. 0.05 (au) or 10LD. Default 0.05 au.
`dist_min`	No	Minimum approach distance.
`fullname`	No	Include full object names.

Schema Changelog

Changes observed during successful MCP inspections.

Changed25 schema fields changedv1.2.0Oct 1, 2026

addedInput schema / additionalProperties
```
Added value: +false
```

changedInput schema / properties / body / description

Previous value: -"Body to find close approaches to (e.g., Earth, Mars, ALL). Default: Earth"New value: +"Close-approach body (Earth, Mars, ALL, ...). Default Earth."

addedInput schema / properties / body / pattern
```
Added value: +"^[A-Za-z]+$"
```

changedInput schema / properties / date_max / description

Previous value: -"End date for search (YYYY-MM-DD). Default: +60 days"New value: +"End date (YYYY-MM-DD, now, or +/-days). Default +60."

addedInput schema / properties / date_max / pattern

Added value: +"^(now|[+-]\\d{1,5}|\\d{4}-\\d{2}-\\d{2}(T\\d{2}:\\d{2}(:\\d{2})?)?)$"

changedInput schema / properties / date_min / description

Previous value: -"Start date for search (YYYY-MM-DD). Default: now"New value: +"Start date (YYYY-MM-DD, now, or +/-days). Default now."

addedInput schema / properties / date_min / pattern

Added value: +"^(now|[+-]\\d{1,5}|\\d{4}-\\d{2}-\\d{2}(T\\d{2}:\\d{2}(:\\d{2})?)?)$"

changedInput schema / properties / des / description

Previous value: -"Object designation (e.g., '2000 SG344' or '433')"New value: +"Only this object (designation)."

addedInput schema / properties / des / maxLength
```
Added value: +100
```
addedInput schema / properties / des / minLength
```
Added value: +1
```

changedInput schema / properties / dist_max / description

Previous value: -"Maximum approach distance (e.g., 0.05, 10LD). Default: 0.05 au"New value: +"Maximum approach distance, e.g. 0.05 (au) or 10LD. Default 0.05 au."

addedInput schema / properties / dist_max / pattern
```
Added value: +"^\\d+(\\.\\d+)?(LD|au|AU)?$"
```

changedInput schema / properties / dist_min / description

Previous value: -"Minimum approach distance. Default: none"New value: +"Minimum approach distance."

addedInput schema / properties / dist_min / pattern
```
Added value: +"^\\d+(\\.\\d+)?(LD|au|AU)?$"
```

changedInput schema / properties / fullname / description

Previous value: -"Include full object name in result. Default: false"New value: +"Include full object names."

addedInput schema / properties / h_max

Added value: +{
+  "description": "Maximum absolute magnitude H.",
+  "type": "number"
+}

addedInput schema / properties / h_min

Added value: +{
+  "description": "Minimum absolute magnitude H.",
+  "type": "number"
+}

addedInput schema / properties / limit

Added value: +{
+  "description": "Maximum number of records (1-1000).",
+  "maximum": 1000,
+  "minimum": 1,
+  "type": "integer"
+}

changedInput schema / properties / neo / description

Previous value: -"Limit to NEOs. Default: true"New value: +"Limit to NEOs (default true upstream)."

changedInput schema / properties / sort / description

Previous value: -"Sort field: date, dist, dist-min, v-inf, v-rel, h, object. Default: date"New value: +"Sort field, prefix - for descending. Default date."

addedInput schema / properties / sort / pattern

Added value: +"^-?(date|dist|dist-min|v-inf|v-rel|h|object)$"

changedInput schema / properties / spk / description

Previous value: -"Object SPK-ID (e.g., '2000433')"New value: +"Only this object (SPK-ID)."

addedInput schema / properties / spk / exclusiveMinimum
```
Added value: +0
```
addedInput schema / properties / spk / maximum
```
Added value: +9007199254740991
```

changedInput schema / properties / spk / type

Previous value: -"string"New value: +"integer"

First observedAug 18, 2025

TDQS

C2.9/5.0

Behavior2/5

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

Annotations already declare readOnlyHint, idempotentHint, openWorldHint, and destructiveHint=false, so the safety profile is covered. The description adds almost nothing beyond naming the source and temporal scope; it does not disclose that results default to Earth-bound approaches within 60 days, which is meaningful behavior for an open-world query.

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

Conciseness4/5

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

A single front-loaded sentence with no filler or redundancy. It is efficient, though it is arguably too terse to carry any real signal for a 13-parameter tool.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness3/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given 13 optional parameters, no output schema, and an open-world query, the description is thin. The schema documents defaults and formats, but nothing tells the agent what the response contains (record fields, distance units in output) or how the heavily parameterized filtering composes.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100% across all 13 parameters, including defaults, units, and patterns, so the schema does the heavy lifting. The description contributes no additional parameter meaning, which is the baseline-3 case.

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

Purpose4/5

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

States a concrete resource (asteroid/comet close approaches to planets), the temporal scope (past and future), and the upstream source (JPL SBDB Close-Approach Data API). It does not explicitly distinguish itself from the sibling jpl_sbdb beyond the 'close approaches' framing, so it falls short of a 5.

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

Usage Guidelines2/5

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

No when-to-use guidance, no prerequisites, and no mention of alternatives such as jpl_sbdb for general small-body lookups. The agent must infer that this is the close-approach query tool from the description text alone.

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

JPL close approaches

Instructions

Input Schema

Schema Changelog

TDQS

Other Tools