Skip to main content
Glama
Sign In
ProgramComputer

NASA MCP Server

by ProgramComputer
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Remote

JPL Horizons ephemerides

jpl_horizons
Read-onlyIdempotent

Query the JPL Horizons API to retrieve ephemerides and object data for solar-system bodies. Specify a target, time range, and center to generate observer, vector, or element tables.

Instructions

Ephemerides and object data for solar-system bodies from the JPL Horizons API (GET).

Input Schema

NameRequiredDescriptionDefault
CENTERNoCoordinate center, e.g. '500@399' (geocentric).
formatNoResponse format.json
COMMANDYesTarget, e.g. '499' (Mars), '1;' (Ceres), 'C/2020 F3'.
OBJ_DATANoInclude object data.
OUT_UNITSNoOutput units for vector/element tables.
STEP_SIZENoStep size, e.g. '1d' or '1h'.
STOP_TIMENoStop time, e.g. '2024-01-02'.
EPHEM_TYPENoEphemeris type.
MAKE_EPHEMNoGenerate an ephemeris.
QUANTITIESNoObserver quantities, e.g. 'A' or '1,2,20,23'.
START_TIMENoStart time, e.g. '2024-01-01'.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed25 schema fields changedv1.2.0
    • 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."
  2. First observed

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, destructiveHint=false and openWorldHint, so the safety profile is fully covered. The description adds essentially nothing beyond corroborating the GET/read nature; it does not mention rate limits, that MAKE_EPHEM must be set to get an ephemeris, or response size characteristics.

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 efficient sentence with the resource front-loaded and no filler. It is appropriately sized, though it is arguably too terse for an 11-parameter NASA API tool.

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

Completeness2/5

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

This is a complex tool with 11 parameters, 5 enums, and no output schema, yet the description never explains how the parameters combine (e.g., MAKE_EPHEM=YES plus EPHEM_TYPE to get an ephemeris). Full schema coverage and annotations mitigate somewhat, but the description leaves meaningful behavioral gaps for a tool of this complexity.

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 enums and examples on every parameter, so the schema carries the full semantic load. The description adds no parameter guidance beyond what is already documented, 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 specific resource and action: 'Ephemerides and object data for solar-system bodies from the JPL Horizons API (GET)'. An agent can tell it serves Horizons queries, but it does not distinguish itself from the closely related sibling jpl_horizons_file or explain what 'object data' covers versus a pure ephemeris.

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, prerequisites, or exclusions. With siblings like jpl_horizons_file, jpl_sbdb and jpl_cad all serving solar-system body queries, the description offers no routing signal for choosing this tool over them.

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

Deploy Server

Other Tools