NASA MCP Server

JPL NHATS human-accessible NEOs

jpl_nhats

Read-onlyIdempotent

Find near-Earth objects accessible to human missions by filtering launch window, delta-V, duration, stay, magnitude, and orbit condition; or query one object by designation/SPK-ID.

Instructions

Near-Earth objects accessible to human missions (NHATS): a constrained summary list, or one object by des/spk.

Input Schema

Name	Required	Description
`h`	No	Maximum absolute magnitude H (16-30).
`dv`	No	Maximum total delta-V in km/s (4-12).
`des`	No	Object designation, e.g. 99942 (object mode).
`dur`	No	Maximum total mission duration in days (60-450).
`occ`	No	Maximum orbit condition code (0-8).
`spk`	No	Object SPK-ID (object mode).
`plot`	No	Include a base64 plot (object mode; large).
`stay`	No	Minimum stay at the NEO in days (8, 16, 24 or 32).
`launch`	No	Launch window.

Schema Changelog

Changes observed during successful MCP inspections.

Changed30 schema fields changedv1.2.0Oct 1, 2026

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

changedInput schema / properties / des / description

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

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

changedInput schema / properties / dur / description

Previous value: -"Minimum total mission duration (days). Values: 60-450, default: 450"New value: +"Maximum total mission duration in days (60-450)."

addedInput schema / properties / dur / maximum
```
Added value: +450
```
addedInput schema / properties / dur / minimum
```
Added value: +60
```

changedInput schema / properties / dur / type

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

changedInput schema / properties / dv / description

Previous value: -"Minimum total delta-V (km/s). Values: 4-12, default: 12"New value: +"Maximum total delta-V in km/s (4-12)."

addedInput schema / properties / dv / maximum
```
Added value: +12
```
addedInput schema / properties / dv / minimum
```
Added value: +4
```

changedInput schema / properties / dv / type

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

changedInput schema / properties / h / description

Previous value: -"Object's maximum absolute magnitude (mag). Values: 16-30"New value: +"Maximum absolute magnitude H (16-30)."

addedInput schema / properties / h / maximum
```
Added value: +30
```
addedInput schema / properties / h / minimum
```
Added value: +16
```

changedInput schema / properties / h / type

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

changedInput schema / properties / launch / description

Previous value: -"Launch window (year range). Values: 2020-2025, 2025-2030, 2030-2035, 2035-2040, 2040-2045, 2020-2045, default: 2020-2045"New value: +"Launch window."

addedInput schema / properties / launch / enum

Added value: +[
+  "2020-2025",
+  "2025-2030",
+  "2030-2035",
+  "2035-2040",
+  "2040-2045",
+  "2020-2045"
+]

changedInput schema / properties / occ / description

Previous value: -"Object's maximum orbit condition code. Values: 0-8"New value: +"Maximum orbit condition code (0-8)."

addedInput schema / properties / occ / maximum
```
Added value: +8
```
addedInput schema / properties / occ / minimum
```
Added value: +0
```

changedInput schema / properties / occ / type

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

changedInput schema / properties / plot / description

Previous value: -"Include base-64 encoded plot image"New value: +"Include a base64 plot (object mode; large)."

changedInput schema / properties / spk / description

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

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"

addedInput schema / properties / stay / anyOf

Added value: +[
+  {
+    "const": 8,
+    "type": "number"
+  },
+  {
+    "const": 16,
+    "type": "number"
+  },
+  {
+    "const": 24,
+    "type": "number"
+  },
+  {
+    "const": 32,
+    "type": "number"
+  }
+]

changedInput schema / properties / stay / description

Previous value: -"Minimum stay time (days). Values: 8, 16, 24, 32, default: 8"New value: +"Minimum stay at the NEO in days (8, 16, 24 or 32)."

removedInput schema / properties / stay / type
```
Removed value: -"number"
```

First observedAug 18, 2025

TDQS

B3.2/5.0

Behavior3/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 externally. The description adds only a light behavioral note that the list is 'constrained' and that object mode exists; it says nothing about filtering behavior, result size, or the cost of the plot option beyond what the schema notes.

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. It is efficient, though the deliberately terse phrasing leaves useful detail (mode switching rules) on the table.

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?

For a 9-parameter, no-required-arg tool with a rich schema but no output schema, the description should clarify how filters apply only in summary mode and how des/spk trigger object mode. It gestures at the two modes but does not fully explain the parameter-to-mode relationship.

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 9 parameters, so the schema already documents ranges, enums, and modes (des/spk for object mode). The description only echoes the des/spk names and adds no syntax or interaction detail, which is the expected baseline when the schema does the heavy lifting.

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 specific resource (NHATS-accessible NEOs) and verb-ish operation (list or fetch one by des/spk), which is enough to distinguish it from nearby siblings like jpl_neo and jpl_scout. It is clear but does not explicitly contrast itself with those siblings.

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?

The description notes two modes ('constrained summary list, or one object by des/spk') but gives no when-to-use guidance, no prerequisites, and never names an alternative tool for comparison. The mode distinction reads as capability, not usage direction.

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

JPL NHATS human-accessible NEOs

Instructions

Input Schema

Schema Changelog

TDQS

Other Tools