NASA MCP Server

JPL Horizons ephemerides (file input)

jpl_horizons_file

Read-onlyIdempotent

Submit Horizons parameters as an input file to generate ephemeris or vector data from NASA/JPL. Use when you need file-based queries instead of URL parameters.

Instructions

Same as jpl_horizons, but submits the parameters as a Horizons input file (POST to horizons_file.api).

Input Schema

Name	Required	Description	Default
`CENTER`	No	Coordinate center, e.g. '500@399' (geocentric).
`format`	No	Response format.	json
`COMMAND`	Yes	Target, e.g. '499' (Mars), '1;' (Ceres), 'C/2020 F3'.
`OBJ_DATA`	No	Include object data.
`OUT_UNITS`	No	Output units for vector/element tables.
`STEP_SIZE`	No	Step size, e.g. '1d' or '1h'.
`STOP_TIME`	No	Stop time, e.g. '2024-01-02'.
`EPHEM_TYPE`	No	Ephemeris type.
`MAKE_EPHEM`	No	Generate an ephemeris.
`QUANTITIES`	No	Observer quantities, e.g. 'A' or '1,2,20,23'.
`START_TIME`	No	Start time, e.g. '2024-01-01'.

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 / CENTER / description

Previous value: -"Coordinate center (e.g., '500@399' for Earth)"New value: +"Coordinate center, e.g. '500@399' (geocentric)."

addedInput schema / properties / CENTER / maxLength
```
Added value: +200
```
addedInput schema / properties / CENTER / minLength
```
Added value: +1
```

changedInput schema / properties / COMMAND / description

Previous value: -"Target object identifier (e.g., '499' for Mars, '1' for Ceres, 'C/2020 F3' for Comet NEOWISE)"New value: +"Target, e.g. '499' (Mars), '1;' (Ceres), 'C/2020 F3'."

addedInput schema / properties / COMMAND / maxLength
```
Added value: +200
```
addedInput schema / properties / COMMAND / minLength
```
Added value: +1
```

changedInput schema / properties / EPHEM_TYPE / description

Previous value: -"Type of ephemeris (OBSERVER, VECTORS, ELEMENTS)"New value: +"Ephemeris type."

changedInput schema / properties / MAKE_EPHEM / description

Previous value: -"Generate ephemeris"New value: +"Generate an ephemeris."

changedInput schema / properties / OBJ_DATA / description

Previous value: -"Include object data"New value: +"Include object data."

changedInput schema / properties / OUT_UNITS / description

Previous value: -"Output units for vector tables"New value: +"Output units for vector/element tables."

changedInput schema / properties / QUANTITIES / description

Previous value: -"Observable quantities to include (e.g., 'A' for all, or '1,2,20,23' for specific ones)"New value: +"Observer quantities, e.g. 'A' or '1,2,20,23'."

addedInput schema / properties / QUANTITIES / maxLength
```
Added value: +200
```
addedInput schema / properties / QUANTITIES / minLength
```
Added value: +1
```

changedInput schema / properties / START_TIME / description

Previous value: -"Start time for ephemeris (e.g., '2023-01-01')"New value: +"Start time, e.g. '2024-01-01'."

addedInput schema / properties / START_TIME / maxLength
```
Added value: +200
```
addedInput schema / properties / START_TIME / minLength
```
Added value: +1
```

changedInput schema / properties / STEP_SIZE / description

Previous value: -"Step size for ephemeris points (e.g., '1d' for daily, '1h' for hourly)"New value: +"Step size, e.g. '1d' or '1h'."

addedInput schema / properties / STEP_SIZE / maxLength
```
Added value: +200
```
addedInput schema / properties / STEP_SIZE / minLength
```
Added value: +1
```

changedInput schema / properties / STOP_TIME / description

Previous value: -"Stop time for ephemeris (e.g., '2023-01-02')"New value: +"Stop time, e.g. '2024-01-02'."

addedInput schema / properties / STOP_TIME / maxLength
```
Added value: +200
```
addedInput schema / properties / STOP_TIME / minLength
```
Added value: +1
```
addedInput schema / properties / format / default
```
Added value: +"json"
```

changedInput schema / properties / format / description

Previous value: -"Response format (json, text)"New value: +"Response format."

First observedAug 18, 2025

TDQS

B3.4/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. The description adds the transport detail (POST to horizons_file.api), which is useful but not behaviorally rich, and says nothing about the expected payload structure or rate limits.

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 tight sentence with the distinguishing constraint front-loaded; no filler. It is efficiently sized, though its brevity is partly what leaves the file-format payload unexplained.

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 an 11-parameter tool with full schema coverage and no output schema, the description is barely adequate. The one genuinely distinguishing feature – what a 'Horizons input file' payload must contain – is asserted but never described, relying entirely on the sibling tool.

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% with 11 documented parameters and 5 enums, so the schema carries the semantic burden. The description adds no parameter-level meaning beyond what the schema provides, making the 3 baseline correct.

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?

The description identifies the resource (JPL Horizons ephemerides) and precisely differentiates it from its sibling, stating it is 'same as jpl_horizons, but submits the parameters as a Horizons input file'. An agent can tell the two apart by the submission mechanism, though the core verb (query/fetch) is implied via the cross-reference rather than stated directly.

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

Usage Guidelines3/5

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

The 'but submits ... as a Horizons input file' clause implies the scenario for choosing this over jpl_horizons (file-based input), but it never explicitly states when to prefer one over the other or any prerequisites. Usage is inferable from the sibling comparison but not spelled out.

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

JPL Horizons ephemerides (file input)

Instructions

Input Schema

Schema Changelog

TDQS

Other Tools