Skip to main content
Glama
Sign In
ProgramComputer

NASA MCP Server

by ProgramComputer
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Remote

JPL Scout NEOCP hazard assessment

jpl_scout
Read-onlyIdempotent

Analyze unconfirmed near-Earth objects from the Minor Planet Center confirmation page to retrieve trajectory, orbit, close-approach, and hazard assessment data.

Instructions

JPL Scout trajectory analysis and hazard assessment for unconfirmed objects on the Minor Planet Center NEO Confirmation Page.

Input Schema

NameRequiredDescriptionDefault
fileNoObject mode: include the observation file as a list or in MPC format.
plotNoObject mode: base64 plots to include: el (elements), ca (close approach), sr (systematic ranging), colon-separated.
tdesNoNEOCP temporary designation (object mode).
limitNoList mode: return at most this many objects. Applied by this server; Scout has no limit parameter.
orbitsNoObject mode: include sampled orbits.
n_orbitsNoObject mode: number of sampled orbits (1-1000).

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed16 schema fields changedv1.2.0
    • addedInput schema / additionalProperties
      Added value: +false
    • changedInput schema / properties / file / description
      Previous value: -"Type of data file to return (summary, ephem, obs, crit, all)"New value: +"Object mode: include the observation file as a list or in MPC format."
    • changedInput schema / properties / file / enum
      Previous value: -[
-  "summary",
-  "ephem",
-  "obs",
-  "crit",
-  "all"
-]New value: +[
+  "list",
+  "mpc"
+]
    • changedInput schema / properties / limit / description
      Previous value: -"Limit number of results"New value: +"List mode: return at most this many objects. Applied by this server; Scout has no limit parameter."
    • addedInput schema / properties / limit / maximum
      Added value: +1000
    • addedInput schema / properties / limit / minimum
      Added value: +1
    • changedInput schema / properties / limit / type
      Previous value: -"number"New value: +"integer"
    • addedInput schema / properties / n_orbits
      Added value: +{
+  "description": "Object mode: number of sampled orbits (1-1000).",
+  "maximum": 1000,
+  "minimum": 1,
+  "type": "integer"
+}
    • removedInput schema / properties / orbit_id
      Removed value: -{
-  "description": "Scout internal orbit ID",
-  "type": "string"
-}
    • addedInput schema / properties / orbits
      Added value: +{
+  "description": "Object mode: include sampled orbits.",
+  "type": "boolean"
+}
    • changedInput schema / properties / plot / description
      Previous value: -"Include plots in the response"New value: +"Object mode: base64 plots to include: el (elements), ca (close approach), sr (systematic ranging), colon-separated."
    • addedInput schema / properties / plot / pattern
      Added value: +"^(el|ca|sr)(:(el|ca|sr))*$"
    • changedInput schema / properties / plot / type
      Previous value: -"boolean"New value: +"string"
    • removedInput schema / properties / summary
      Removed value: -{
-  "description": "Include summary data in the response",
-  "type": "boolean"
-}
    • changedInput schema / properties / tdes / description
      Previous value: -"Object temporary designation (e.g., P21Eolo)"New value: +"NEOCP temporary designation (object mode)."
    • addedInput schema / properties / tdes / pattern
      Added value: +"^[A-Za-z0-9]{1,16}$"
  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, idempotent, openWorld, and non-destructive, so the safety profile is covered. The description adds the useful context that the objects are unconfirmed NEOCP entries (implying unstable/short-lived data), but says nothing about response shape, plot encoding, or compute cost of sampling orbits.

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 that identifies the domain, the data source, and the analytical output with zero filler.

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?

With no output schema and a dual-mode design (list mode via limit vs object mode via tdes/file/plot/orbits), the description should explain the two invocation modes and what each returns. It never mentions modes at all, leaving an agent to infer everything from parameter names.

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 six parameters are already documented, including the list/object mode distinctions and enum constraints. The description adds no parameter detail beyond what the schema provides, which is the expected baseline.

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?

Specific verb+resource ('trajectory analysis and hazard assessment') applied to a specific target set ('unconfirmed objects on the NEOCP'). It is clearly distinct from confirmed-object siblings like jpl_sentry or jpl_sbdb, though it never names those siblings to sharpen the boundary.

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 statement of when to use this tool versus jpl_sentry, jpl_nhats, or jpl_sbdb, and no mention of prerequisites (e.g., that NEOCP objects are unconfirmed and may vanish). The implicit list-vs-object mode split is left entirely to the schema.

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