Skip to content

FAQ

Stdio vs HTTP — which should I use?

Stdio is the default for desktop chat clients. The client launches astrodynamics-mcp stdio as a subprocess and speaks MCP over its stdin/stdout. No port to manage, no network auth, runs as the user, lives only while the client is up; any upstream credential rides along as an environment variable on the subprocess. Pick stdio unless you have a specific reason otherwise.

Streamable HTTP is for remote agents — pipelines, hosted services, long-running automation that can't or shouldn't co-locate with a chat client. Start astrodynamics-mcp http --port 8000; clients reach the server at http://<host>:8000/mcp using the official MCP SDK's Streamable HTTP transport.

The tool surface is identical across the two. The Streamable HTTP transport currently ships no built-in auth — bind to 127.0.0.1 (the default) and put your own proxy in front when exposing it to the network.

What astrodynamics-mcp is not

  • Not a general-purpose astrodynamics framework. We wrap vetted upstream libraries (sgp4, lamberthub, skyfield, astropy, interplanetary-porkchop, spiceypy). We don't ship propagators, integrators, or coordinate systems of our own. No new physics.
  • Not an agent framework. astrodynamics-mcp exposes MCP tools; LangGraph, AutoGen, CrewAI, and the LLM clients themselves consume them.
  • Not a SaaS. There is no astrodynamics.cloud, no hosted offering, no managed multi-tenant deployment. You run the server locally or in your own infrastructure.
  • Not a script-authoring tool. Mission-script linting and authoring belong to a separate project. astrodynamics-mcp computes on demand; it doesn't write .script files.
  • Not a catalogue or database. We don't ship a Hubble image archive, an asteroid tracker, or a conjunction database. We compute state vectors, access windows, and trajectories — what's in the catalogues we query lives at the upstream.
  • Not a web UI. Tool consumption is through MCP clients. There is no browser frontend, no desktop app, no notebook widget. Use whatever MCP-capable client you already use.

Where do I get the underlying libraries directly?

If your work doesn't need an LLM in the loop, reach for the libraries that back each tool:

  • SGP4 / TLE propagation → sgp4.
  • Lambert's problem → lamberthub.
  • Ground-station / observer geometry → skyfield.
  • Time scales and coordinate frames → astropy.
  • Porkchop scans (interplanetary) → composed in-repo from lamberthub plus the JPL Horizons adapter — no single upstream. For a standalone generator see interplanetary-porkchop.
  • SPICE kernels and ephemerides → spiceypy.

astrodynamics-mcp is the LLM-callable front-end for these libraries. Their pip install is the recommended fallback when you need surface area we haven't exposed yet.

What about LeoLabs / Space-Track / DISCOS?

Space-Track and DISCOSweb are supported through credential passthrough: you provide your own per-user account and the server reaches the upstream as you. Space-Track backs tle_lookup's deeper-catalogue path; DISCOSweb backs satellite_metadata. The no-auth core still works with no credential, so the quick-start is still pip install astrodynamics-mcp plus a one-block client config — the credential only enters when you call a tool that needs it. See Credentials for how to provide one.

LeoLabs's commercial ToS prohibits redistribution of derived products, so passthrough credentialling for individual paid subscribers is deliberately not in any current plan.

How do I trust the numbers?

Four layers of validation:

  • The upstream libraries (sgp4, lamberthub, skyfield, astropy, etc.) have their own test suites. We don't re-verify their numerical correctness; we delegate.
  • Reference-output regression tests pin a small set of fixed inputs to committed golden JSON. Pinning the upstream version is a deliberate action; goldens regenerate at the same time.
  • Frame and unit equivalence tests cross-check that the same physical quantity computed through two different tool paths agrees to numerical tolerance.
  • The eval suite checks that an LLM, under prompt variation, picks the right tool and reads the right answer back. This is the regression contract on tool-description quality.

Together these guard against the numerical, schema, and tool-description regression modes independently.

How are upstream-library versions pinned?

Hard runtime dependencies are pinned to a minimum version in pyproject.toml; every release pins a specific minor version of sgp4, lamberthub, skyfield, astropy, and interplanetary-porkchop. Bumping a pin triggers a re-run of the reference-output regression suite and the eval suite — golden values move only when the wrapping contract genuinely changed.

Will there be a hosted version?

No. astrodynamics-mcp ships as a CLI you run locally or in your own infrastructure. The cache layer is process-local and per-machine; we do not store user data, we do not aggregate analytics, we do not run a hosted MCP server.

How do I report a bug or request a tool?

  • Bug → open an issue with the failing tool's input arguments and the typed error code from the response envelope. The error code is the fastest path to a diagnosis.
  • Tool request → open an issue under the "tool request" template describing the natural-language question you'd like to ask, and what upstream library would back the tool.
  • Open-ended question / usage help → a Discussion in the astro-tools community space.