Skip to main content
Glama
melgoldstein

space-defense-osint

by melgoldstein
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Python
Remote

mcp-space-defense-osint

Portfolio: melgoldstein.com

A stdio MCP server for public orbital context, geomagnetic conditions and structured airspace envelopes. Built on the official MCP SDK, Skyfield/SGP4 and HTTPX. MIT licensed; Python 3.11+. No API keys required.

Quickstart (30 Seconds)

git clone https://github.com/melgoldstein/mcp-space-defense-osint.git
cd mcp-space-defense-osint
python -m venv .venv
.venv/bin/python -m pip install '.[dev]'
.venv/bin/space-defense-osint --check

Windows equivalents are .venv\Scripts\python.exe and .venv\Scripts\space-defense-osint.exe. --check performs a local parser check. Without arguments the CLI serves MCP over stdio; logs go to stderr.

Related MCP server: mcp-celestrak

Claude Desktop configuration

Add this to claude_desktop_config.json, selecting the absolute Python path of the environment where the package is installed. Restart the host after saving.

{
  "mcpServers": {
    "space-defense-osint": {
      "command": "/absolute/path/to/.venv/bin/python",
      "args": ["-m", "space_defense_osint.server"]
    }
  }
}

Windows command example: C:\\Users\\you\\tools\\.venv\\Scripts\\python.exe. Configuration paths: %APPDATA%\Claude\claude_desktop_config.json on Windows and ~/Library/Application Support/Claude/claude_desktop_config.json on macOS. Cursor accepts the same mcpServers entry in .cursor/mcp.json. See the SDK host guide and Cursor documentation.

Tools

Tool

Inputs

Result

fetch_celestrak_tle

Catalog ID, location, horizon, minimum elevation

TLE, epoch age, next pass, source and retrieval timestamp

query_noaa_swpc_kp

None

Latest observed Kp, SWPC alerts, age and cache metadata

analyze_notam_tfr

Notice with ICAO center/radius

GeoJSON bounding envelope, bbox, center and radius

Pass defaults: Cape Canaveral 28.4158, -80.6048, ISS 25544, 24-hour horizon and 10-degree minimum elevation. The horizon is bounded to 72 hours. Results identify ongoing passes and truncated search windows. A null pass means no qualifying pass was found. These are geometric passes, not optical-visibility forecasts.

TLE requests are cached for one hour, NOAA for 60 seconds. Cache hits retain original retrieval timestamps. Requests have a 15-second timeout and two-megabyte body budget. Errors do not silently substitute stale results. NOAA observation age is reported separately; values older than six hours are marked stale. Current object-based and legacy table-based Kp layouts are both supported.

The NOTAM parser supports Q-line coordinates such as 2825N08036W010 with radius in nautical miles. Dateline crossings produce a MultiPolygon. This is a bounding envelope, not a legal TFR boundary. Arbitrary polygons and free-form descriptions are rejected. The tool parses supplied notices; it does not fetch current airspace restrictions.

Python API

from space_defense_osint.server import fetch_celestrak_tle
from space_defense_osint.airspace import analyze_notam_tfr

geometry = analyze_notam_tfr("Q) KZMA/QWALW/IV/M/W/000/999/2825N08036W010")
pass_context = fetch_celestrak_tle(catalog_id=25544)

Benchmark comparison

Local medians over 1,000 iterations on Windows x64:

Operation

Median, us

Network included

Cached feed read

0.30

No

Reparse small JSON fixture

0.90

No

Q-line to GeoJSON

2.80

No

Caching avoids repeated decoding and upstream requests. These operations differ in semantics; their timings do not estimate live-feed or orbital-prediction latency. Run python benchmarks/bench_local.py. Results record the platform.

Validation and sources

python -m pytest runs offline geometry, caching, Kp-layout, pass-ordering and real MCP stdio handshake/tool-call tests. Live NOAA and CelesTrak checks also passed during development. Live availability varies; consumers should inspect TLE epoch age before using predictions. Legacy TLE catalog identifiers above 99999 require an OMM interface and are not supported.

Available Tools

3 tools
analyze_notam_tfrC

Convert an ICAO Q-line center/radius to a GeoJSON bounding envelope.

NameRequiredDescriptionDefault
noticeYes

Output Schema

NameRequiredDescription

No output parameters

TDQS

C2.8/5.0
Behavior2/5

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

No annotations are provided, so the description carries the full burden of behavioral disclosure. It states the output type as a GeoJSON bounding envelope, but does not explain whether the operation is read-only, what validation or parsing occurs, or how errors are handled.

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?

The description is a single, front-loaded sentence with no wasted words. It states the input abstraction and output format directly.

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?

Although the tool is simple and has an output schema, the description leaves a critical gap: the required 'notice' parameter is undocumented. An agent knows the transformation type but cannot confidently determine what to pass in.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters2/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The single parameter 'notice' has 0% schema description coverage, and the description does not define what the parameter should contain. The mention of 'ICAO Q-line center/radius' gives a weak hint that the input relates to Q-line data, but does not clarify whether 'notice' is full NOTAM text, a Q-line string, or an identifier.

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 states a specific verb and transformation: converting an ICAO Q-line center/radius into a GeoJSON bounding envelope. It is clear what the tool does, but it does not differentiate from sibling tools or mention the NOTAM/TFR context implied by the name.

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?

The description gives no explicit when-to-use guidance, prerequisites, or alternatives. The conversion operation implies a use case, but an agent must infer that this tool is appropriate when it has ICAO Q-line center/radius data.

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

fetch_celestrak_tleB

Fetch one TLE and predict the next topocentric pass; returns source and epoch age.

NameRequiredDescriptionDefault
latitudeNo
longitudeNo
catalog_idNo
horizon_hoursNo
minimum_elevation_degNo

Output Schema

NameRequiredDescription

No output parameters

TDQS

B3/5.0
Behavior3/5

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

No annotations, so the description carries the burden. It usefully discloses that results include the data source and epoch age (i.e., TLE staleness matters), which is real behavioral value. It says nothing about network fetching from Celestrak, failure modes when no pass occurs within the horizon, or whether fetching and prediction always happen together.

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 sentence with three distinct payloads: the fetch, the prediction, and the returned metadata. No filler, action front-loaded.

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?

Output schema covers the return shape, but for a compound tool with five undescribed parameters and no annotations, the description omits essential context: defaults, whether a pass prediction is always computed, and the no-pass case. An agent cannot confidently parameterize it from this text alone.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters2/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

All five parameters have 0% schema description coverage and the description never names them. 'Topocentric' hints that observer coordinates drive the prediction, but latitude/longitude units, the meaning of horizon_hours, minimum_elevation_deg thresholds, and the hidden defaults (Norfolk coordinates, catalog 25544 = ISS) are undocumented.

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: fetch a TLE (orbital elements) and compute the next topocentric pass, plus a note that source and epoch age are returned. This is clearly distinct from the space-weather and NOTAM siblings. It stops short of 5 only because TLE/topocentric jargon is unexplained for a non-expert caller.

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 indication of when to prefer this over querying other sources, no prerequisites, and no note on what happens when no pass exists in the horizon. Usage must be inferred entirely from the tool name and the word 'pass'.

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

query_noaa_swpc_kpA

Fetch observed planetary Kp and current SWPC alerts with retrieval timestamps.

NameRequiredDescriptionDefault

No parameters

Output Schema

NameRequiredDescription

No output parameters

TDQS

A3.5/5.0
Behavior3/5

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

With no annotations, the description must carry the behavioral load. 'Observed' usefully distinguishes measured values from predicted ones, and 'with retrieval timestamps' tells the agent data freshness is returned, but it omits any mention of auth, rate limits, update cadence, or whether alerts may be empty.

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?

One sentence, front-loaded with the verb and the primary data product, with the secondary product and output note trailing. No wasted words.

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

Completeness4/5

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

Output schema exists, so return values need no explanation, and a no-parameter tool needs no input discussion. What remains thin is operational context (freshness/update cadence of SWPC data), but nothing required for a correct call is missing.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The tool takes zero parameters, so there is nothing to disambiguate; the baseline applies. No parameter text is needed.

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 verb (Fetch) and two specific resources (observed planetary Kp, current SWPC alerts) plus an output property (retrieval timestamps). It is unambiguous against the space-weather-unrelated siblings (analyze_notam_tfr, fetch_celestrak_tle), though it never names or contrasts them explicitly.

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 guidance on when to use this versus an alternative source of geomagnetic data, and no mention of conditions such as alert-only checks or historical Kp. 'observed' and 'current' imply present-time monitoring but the agent must infer that.

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

Tool Schema Changelog

Recent tool additions, removals, and schema changes observed during successful MCP inspections.

  1. 3 tool updatesv0.1.0
    • First observedanalyze_notam_tfr
    • First observedfetch_celestrak_tle
    • First observedquery_noaa_swpc_kp
Deploy Server
One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

TDQS

B3.3/5.0

Scored across 3 tools

Disambiguation5/5

Each tool targets a clearly different data source and task: space-weather Kp/alerts, NOTAM TFR geometry conversion, and satellite TLE/pass prediction. There is no meaningful overlap that would cause misselection.

Naming Consistency5/5

All names use snake_case and follow a verb_source_or_data pattern: query_noaa_swpc_kp, analyze_notam_tfr, fetch_celestrak_tle. The differing verbs reflect genuinely different operations rather than inconsistent conventions.

Tool Count4/5

Three tools is a reasonable minimal set, and each has a distinct purpose. For a broad 'space-defense-osint' server it still feels somewhat thin, but the count is not excessive or clearly mismatched.

Completeness2/5

The surface provides only narrow primitives: current Kp/alerts, a NOTAM Q-line conversion, and a single TLE pass prediction. It lacks obvious OSINT operations such as fetching NOTAM/TFR records, querying multiple satellites, historical/forecast space weather, or cross-source correlation.

Maintenance

ActivityActive
ResponsivenessNo issues

Resources

Related MCP Connectors

Related MCP Servers