Skip to main content
Glama
chazzawarner

space-stds

by chazzawarner
OverviewSchemaRelated ServersScoreDiscussions
Python
Local

space-stds

Local-first, read-only MCP retrieval for authorised CCSDS and ECSS standards. The repository contains code only. Standards files, extracted text, indexes, credentials, logs, and SANA personal data stay outside Git.

The first runnable slice supports:

  • local PDF ingestion with source-path and official-host restrictions;

  • idempotent SQLite FTS5 indexing;

  • citation-rich standards search and passage retrieval;

  • revision-aware metadata and corpus/status/document filters;

  • atomic whole-corpus rebuilds from a validated JSON manifest;

  • MCP stdio tools plus document and passage resources;

  • native uv installation and an optional Docker image.

SANA is not yet connected. Its API requires authenticated documentation and a confirmed reuse/rate-limit policy. The server does not scrape its HTML pages.

Recommended native setup

Requirements: Python 3.11 or newer and uv.

./scripts/bootstrap.sh

The script installs locked runtime dependencies and creates these local paths:

  • ~/.local/share/space-stds/index.sqlite3

  • ~/.local/share/space-stds/corpus/

Override them before setup if required by work policy:

export SPACE_STDS_DATA_DIR=/approved/private/index-directory
export SPACE_STDS_CORPUS_DIR=/approved/private/standards-directory
./scripts/bootstrap.sh

Place an authorised PDF beneath the corpus directory, then index it with explicit provenance:

uv run space-stds ingest "$SPACE_STDS_CORPUS_DIR/131x0b6ec1.pdf" \
  --source CCSDS \
  --document-id "CCSDS 131.0-B-6" \
  --title "TM Synchronization and Channel Coding" \
  --revision "6" \
  --status active \
  --official-url "https://ccsds.org/.../131x0b6ec1.pdf"

The command rejects PDFs outside the configured corpus root. ECSS documents must be acquired separately under an applicable ECSS licence.

Related MCP server: Atlas

Official-source acquisition

The acquisition helper discovers files without downloading them by default:

uv run python scripts/download_official_sources.py --source all

To download the active CCSDS catalogue PDFs and the ECSS bulk archives/TM snapshot into source-specific directories beneath the configured corpus:

uv run python scripts/download_official_sources.py \
  --source all \
  --download \
  --prepare \
  --accept-ccsds-reuse-terms \
  --accept-ecss-license

Use --list to inspect every discovered record first. Use --manifest PATH to save a discovery plan. Repeat --ccsds-book-type or --ecss-collection to select a subset; select --ccsds-book-type "Silver Book" explicitly for historical/obsolete CCSDS publications. Downloads are bounded and atomic, redirects remain on official hosts, existing files are revalidated, and the resulting local manifest records source URLs, SHA-256 hashes, sizes, and verification times. Keep the destination outside the repository.

Use --refresh on a later run to re-fetch existing filenames. The helper keeps the existing file when its SHA-256 is unchanged and atomically replaces it when the publisher content changed. A partial or failed run writes a separate failed-attempt report and does not replace the last complete manifest.

With --prepare, ZIP members are validated before extraction, archive paths and links are rejected, decompressed sizes are bounded, and the completed archive is published atomically beneath the corpus directory. The command then writes ingestion-manifest.generated.json. ECSS archive entries do not contain complete catalogue metadata. When any values are inferred, the generated file contains "metadata_review_required": true, which makes it invalid for ingestion. Reconcile each ECSS title, identifier, revision, status, and canonical document URL against the official catalogue. Then remove that review marker before indexing:

uv run space-stds ingest-manifest \
  "$SPACE_STDS_CORPUS_DIR/ingestion-manifest.generated.json"

An existing acquisition manifest can be prepared separately:

uv run space-stds prepare-corpus \
  "$SPACE_STDS_CORPUS_DIR/acquisition-manifest.json"

The ECSS bulk PDF archive is a dated standards snapshot, and the handbook and technical-memoranda sources are not complete current catalogues. The CCSDS site provides no documented API or all-publications ZIP; the helper reads its official active-and-obsolete catalogue and will fail if that page's embedded data contract changes. Review the acquisition research before relying on bulk synchronisation.

PDF extraction backends

pypdf remains the default. PDF Inspector is an optional, exactly pinned native dependency. Install it before selecting that backend for a complete manifest rebuild:

uv sync --extra pdf-inspector
export SPACE_STDS_PDF_BACKEND=pdf-inspector
uv run space-stds ingest-manifest /approved/private/manifest.json

PDF Inspector runs locally and reports OCR-risk, table, and multi-column pages. It does not perform OCR. The automated 11-document, 60-query A/B benchmark retained pypdf as the default. pypdf indexed all 1,180 pages, achieved 100% passage hit-rate@3, 80% top-1, 0.787 nDCG@3, and took 9.7 seconds with a 131.5 MiB peak. PDF Inspector indexed 1,178 pages, achieved 63.6% hit-rate@3, 50.9% top-1, 0.515 nDCG@3, and took 45.8 seconds with a 210.8 MiB peak. Both achieved 100% no-answer accuracy and citation-field completeness. PDF Inspector identified a vector-text CCSDS cover and an ECSS change-log page as OCR risks. A visual check confirmed those classifications, but broader sampled review of clause boundaries, tables, symbols, and page furniture remains required.

Re-run the benchmark after changing the corpus or either parser:

uv run --extra pdf-inspector python scripts/benchmark_extractors.py \
  --manifest /approved/private/manifest.json

Aggregate results are recorded in benchmarks/extractor-results.json; no standards text is written to that file.

For repeatable whole-corpus setup, copy examples/manifest.example.json outside the repository, edit it, and run:

uv run space-stds ingest-manifest /approved/private/manifest.json

Each file is relative to SPACE_STDS_CORPUS_DIR. Manifest ingestion builds and validates a complete staged database before replacing the current index. If any document fails, the previous index remains available. Stop the MCP server before rebuilding the index.

Run a diagnostic query:

uv run space-stds search "attached sync marker"
uv run space-stds search "interface requirement" --source ECSS --status active
uv run space-stds document "CCSDS 131.0-B-6" --revision 6

MCP client configuration

Use the installed executable directly. Replace /absolute/path/to/space-stds and the data paths with real absolute paths:

{
  "mcpServers": {
    "space-stds": {
      "command": "/absolute/path/to/space-stds/.venv/bin/space-stds",
      "args": ["serve"],
      "env": {
        "SPACE_STDS_DATA_DIR": "/approved/private/index-directory",
        "SPACE_STDS_CORPUS_DIR": "/approved/private/standards-directory"
      }
    }
  }
}

The exact configuration file depends on the MCP host used at work. The server writes protocol messages only to stdout; diagnostics from the SDK use stderr.

For Codex, register the native server with the CLI. Use absolute paths:

codex mcp add space-stds \
  --env SPACE_STDS_DATA_DIR=/approved/private/index-directory \
  --env SPACE_STDS_CORPUS_DIR=/approved/private/standards-directory \
  -- /absolute/path/to/space-stds/.venv/bin/space-stds serve
codex mcp get space-stds

Codex stores this user-level configuration in ~/.codex/config.toml. Restart Codex after adding the server, then use /mcp to confirm that its tools are available. See the official Codex MCP configuration guide.

The MCP surface is:

  • search_standards(query, source?, document_id?, revision?, status?, limit?)

  • get_document(document_id, revision?, source?)

  • get_passage(passage_id)

  • space-stds://documents/{document_key}

  • space-stds://passages/{passage_id}

Optional Docker setup

Docker is supported but is not required. Native execution is usually simpler for a desktop MCP client. Build the image once:

docker build -t space-stds:local .
docker volume create space-stds-data

Initialise it, mounting the authorised corpus read-only:

docker run --rm \
  --mount source=space-stds-data,target=/data \
  --mount type=bind,source=/approved/private/standards-directory,target=/corpus,readonly \
  space-stds:local ingest-manifest /corpus/manifest.json

For MCP stdio, retain stdin with -i:

docker run --rm -i \
  --mount source=space-stds-data,target=/data \
  --mount type=bind,source=/approved/private/standards-directory,target=/corpus,readonly \
  space-stds:local serve

Use that docker run command and arguments in the MCP host if native execution is prohibited.

Development checks

UV_CACHE_DIR=/tmp/space-stds-uv-cache uv sync --frozen --extra dev
UV_CACHE_DIR=/tmp/space-stds-uv-cache uv run pytest
UV_CACHE_DIR=/tmp/space-stds-uv-cache uv run ruff check .
UV_CACHE_DIR=/tmp/space-stds-uv-cache uv run mypy

Run the local-corpus retrieval benchmark after ingestion:

uv run python scripts/evaluate_retrieval.py \
  --output benchmarks/retrieval-results.json

The checked corpus passes all 55 graded positive questions at passage hit-rate@3 and correctly abstains on all five no-answer questions. Passage-level top-1 accuracy is 80%, MRR is 0.888, nDCG@3 is 0.787, and every returned result has a page, section, official source URL, and stable MCP resource URI. The cases support multiple graded passages for valid cross-standard answers. See benchmarks/retrieval.json, benchmarks/retrieval-results.json, and benchmarks/coverage-gaps.json.

See the proposal, corpus policy, MCP research, and acquisition research.

Available Tools

3 tools
get_documentA

Get authoritative metadata for one indexed document edition. Specify revision when more than one edition is indexed.

ParametersJSON Schema
NameRequiredDescriptionDefault
sourceNo
revisionNo
document_idYes

Output Schema

ParametersJSON Schema
NameRequiredDescription

No output parameters

TDQS

A3.6/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 burden of behavioral disclosure. It states the result is 'authoritative metadata' and limited to an 'indexed document edition,' but it does not mention whether missing documents cause errors, how revisions are resolved, or any other side effects or constraints.

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?

Two short sentences with no filler. The core action and resource are front-loaded, and the revision guidance is placed exactly where it belongs.

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

Completeness3/5

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

For a straightforward single-document metadata retrieval tool, the description is close to adequate, and an output schema exists to document return values. However, without annotations or schema parameter descriptions, the source parameter remains unexplained and usage guidance relative to sibling tools is thin.

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 schema has 0% description coverage, so the description must compensate. It adds useful semantics for revision ('when more than one edition is indexed') but does not explain the meaning or role of source, which is a nontrivial optional parameter with an enum of CCSDS/ECSS.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description names a specific verb ('Get'), a specific resource ('authoritative metadata for one indexed document edition'), and clarifies it targets a single document rather than a search or passage. This clearly distinguishes it from sibling tools like search_standards and get_passage.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description gives concrete guidance: specify revision when more than one edition is indexed. It implies this tool is for retrieving metadata for a known document rather than searching, but it does not explicitly state when to prefer this over search_standards or get_passage.

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

get_passageA

Retrieve one exact passage by the opaque identifier returned by search_standards.

ParametersJSON Schema
NameRequiredDescriptionDefault
passage_idYes

Output Schema

ParametersJSON Schema
NameRequiredDescription

No output parameters

TDQS

A4.3/5.0
Behavior3/5

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

No annotations are present, so the description must carry behavioral weight. It usefully discloses that the identifier is opaque and that retrieval is for exactly one passage, which signals a direct lookup rather than search. However, it does not mention behavior on missing/invalid IDs, auth requirements, or read-only guarantees.

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, tightly written sentence with no filler. It front-loads the action and resource, then gives the essential provenance of the identifier.

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

Completeness5/5

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

For a simple one-parameter get-by-id tool with an output schema available, the description provides the necessary context: what to retrieve and exactly where the identifier comes from. Nothing critical is missing for an agent to select and call it correctly.

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?

With schema description coverage at 0%, the description compensates well for the single parameter passage_id by explaining that it is an opaque identifier returned by search_standards. This adds semantics beyond the schema's bare string type.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description states a specific verb ('Retrieve'), a clear resource ('one exact passage'), and a precise identifier source ('opaque identifier returned by search_standards'). This distinguishes it from get_document (document-level) and search_standards (search operation) without needing to open schemas.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description clearly implies usage after search_standards, since the passage_id is produced by that tool. It does not explicitly discuss when to prefer get_document, but the passage vs. document distinction is reasonably evident from the wording.

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

search_standardsA

Rank locally indexed CCSDS and ECSS passages by meaningful query terms. Returns exact source provenance; an empty list means no passage matched enough distinct meaningful terms.

ParametersJSON Schema
NameRequiredDescriptionDefault
limitNo
queryYes
sourceNo
statusNo
revisionNo
document_idNo

Output Schema

ParametersJSON Schema
NameRequiredDescription
resultYes

TDQS

A3.9/5.0
Behavior4/5

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

With no annotations provided, the description carries the full behavioral disclosure burden. It transparently explains that results are locally indexed, ranking is based on meaningful query terms, provenance is returned, and an empty list has a specific meaning. It does not cover all behavioral details like pagination or threshold specifics, but it is notably more transparent than typical tool descriptions.

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?

Two sentences, no filler, and every phrase adds value: local indexing, ranking criterion, provenance, and empty-list semantics are all packed in efficiently. The core purpose is front-loaded.

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?

The description is strong for a search tool: it explains what is searched, how results are ranked, what provenance is returned, and how to interpret an empty result. It does not describe the filtering parameters or output shape, but the output schema exists and parameter names are mostly self-explanatory, so the description is reasonably complete.

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?

Schema description coverage is 0%, so the description must compensate for six parameters, but it only adds meaning around the query concept ('meaningful query terms'). It does not explain source, status, revision, document_id, or limit beyond what their names and schema defaults imply, leaving a significant semantic gap.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description states a specific action—ranking locally indexed CCSDS and ECSS passages—and clearly identifies the resource being searched. The mention of provenance and empty-list semantics further distinguishes it from the sibling fetch tools get_document and get_passage.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description implies this tool is for searching/ranking standards passages, but it does not explicitly state when to use it instead of get_document or get_passage. There are no direct alternatives or exclusion conditions, so the usage context is only inferred rather than stated.

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. Dates show when Glama detected each change.

  1. 3 tool updatesv0.1.0
    • First observedget_document
    • First observedget_passage
    • First observedsearch_standards
Install Server
RayrunBuild, deploy, and operate MCP servers without becoming an infrastructure team.ray.runAd

TDQS

A4.1/5.0
Disambiguation5/5

Each tool has a clearly distinct role: search_standards finds passages, get_document returns metadata, and get_passage retrieves a specific passage by ID. There is no meaningful overlap between them.

Naming Consistency5/5

All tool names follow the same verb_noun snake_case pattern: search_standards, get_document, get_passage. The naming is uniform and predictable.

Tool Count5/5

Three tools is well-scoped for a focused standards-search and retrieval server. Each tool covers a necessary step in the workflow without unnecessary bloat.

Completeness4/5

The search-to-passage retrieval workflow is complete, but there is no tool to list all indexed documents or fetch full document content. These are minor gaps that can be worked around via search and metadata access.

Maintenance

ActivityMaintained
ResponsivenessNo issues

Resources

Unclaimed servers have limited discoverability.

Looking for Admin?

If you are the server author, to access and configure the admin panel.

Related MCP Connectors

Related MCP Servers

  • ragi

    SusuTawar
    A
    license
    A
    quality
    D
    maintenance
    Local-first RAG indexing and semantic search MCP server. Enables document retrieval and context-aware queries using local embedding models.
    3
    16
    MIT

Latest Blog Posts

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/chazzawarner/space-stds'

If you have feedback or need assistance with the MCP directory API, please join our Discord server