Skip to main content
Glama
Sign In
ProgramComputer

NASA MCP Server

by ProgramComputer
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Remote

JPL Small-Body Database lookup

jpl_sbdb
Read-onlyIdempotent

Retrieve orbital, physical, and close-approach data for an asteroid or comet from NASA JPL's Small-Body Database using name, designation, or SPK-ID.

Instructions

Orbital and physical data for one asteroid or comet from the JPL Small-Body Database (SBDB).

Input Schema

NameRequiredDescriptionDefault
cadNoDEPRECATED alias for ca_data.
desNoPrimary designation or IAU number.
satNoInclude satellite data.
spkNoSPK-ID of the object.
sstrNoSearch string: name, designation or number (e.g. Ceres, 433, 2019 OK).
ca_bodyNoLimit close approaches to this body (e.g. Earth); needs ca_data.
ca_dataNoInclude close-approach data.
vi_dataNoInclude Sentry virtual-impactor data.
phys_parNoInclude physical parameters.
discoveryNoInclude discovery circumstances.
full_precNoFull-precision orbital elements.
alt_orbitsNoInclude alternate orbits.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed16 schema fields changedv1.2.0
    • addedInput schema / additionalProperties
      Added value: +false
    • addedInput schema / properties / alt_orbits
      Added value: +{
+  "description": "Include alternate orbits.",
+  "type": "boolean"
+}
    • addedInput schema / properties / ca_body
      Added value: +{
+  "description": "Limit close approaches to this body (e.g. Earth); needs ca_data.",
+  "maxLength": 40,
+  "minLength": 1,
+  "type": "string"
+}
    • addedInput schema / properties / ca_data
      Added value: +{
+  "description": "Include close-approach data.",
+  "type": "boolean"
+}
    • changedInput schema / properties / cad / description
      Previous value: -"Include close approach data"New value: +"DEPRECATED alias for ca_data."
    • addedInput schema / properties / des
      Added value: +{
+  "description": "Primary designation or IAU number.",
+  "maxLength": 100,
+  "minLength": 1,
+  "type": "string"
+}
    • addedInput schema / properties / discovery
      Added value: +{
+  "description": "Include discovery circumstances.",
+  "type": "boolean"
+}
    • addedInput schema / properties / full_prec
      Added value: +{
+  "description": "Full-precision orbital elements.",
+  "type": "boolean"
+}
    • addedInput schema / properties / phys_par
      Added value: +{
+  "description": "Include physical parameters.",
+  "type": "boolean"
+}
    • addedInput schema / properties / sat
      Added value: +{
+  "description": "Include satellite data.",
+  "type": "boolean"
+}
    • addedInput schema / properties / spk
      Added value: +{
+  "description": "SPK-ID of the object.",
+  "exclusiveMinimum": 0,
+  "maximum": 9007199254740991,
+  "type": "integer"
+}
    • changedInput schema / properties / sstr / description
      Previous value: -"Search string (e.g., asteroid name, number, or designation)"New value: +"Search string: name, designation or number (e.g. Ceres, 433, 2019 OK)."
    • addedInput schema / properties / sstr / maxLength
      Added value: +200
    • addedInput schema / properties / sstr / minLength
      Added value: +1
    • addedInput schema / properties / vi_data
      Added value: +{
+  "description": "Include Sentry virtual-impactor data.",
+  "type": "boolean"
+}
    • removedInput schema / required
      Removed value: -[
-  "sstr"
-]
  2. First observed

TDQS

B3.2/5.0
Behavior3/5

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

Annotations already declare readOnly, openWorld, idempotent, and non-destructive, covering the safety profile. The description adds only the single-object scope, and omits whether an identifier is mandatory, how missing objects are reported, or the deprecated-flag behavior.

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

Conciseness5/5

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

A single front-loaded sentence with no filler. Every word carries information about resource, scope, and source.

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?

For a 12-parameter tool with no required fields and no output schema, the description is far too thin: it never says how to identify the object (sstr/des/spk) or how the boolean include-flags interact. An agent would have to reverse-engineer invocation from the schema alone.

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%, so all 12 parameters are already documented, including the deprecation of 'cad'. The description adds no parameter syntax or interaction detail (e.g. that ca_body needs ca_data), so baseline 3 applies.

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 (orbital and physical data) and scope (one asteroid or comet) from a named database, so the agent knows what it gets. It does not differentiate from siblings such as jpl_sentry, jpl_cad, or jpl_horizons, which surface overlapping small-body data.

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?

There is no when-to-use guidance, no mention of prerequisites (e.g. that an identifier must be supplied), and no routing to alternatives like jpl_horizons or jpl_sentry. The agent must infer usage entirely.

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