Provides tools to interact with NASA's General Mission Analysis Tool (GMAT), enabling AI agents to run mission scripts, retrieve curated knowledge of GMAT idioms, list and fetch sample scripts, and search GMAT documentation for autonomous mission design and validation.
Click on "Install Server".
Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state.
In the chat, type @ followed by the MCP server name and your instructions, e.g., "@gmat-mcp-server write a GMAT script for a two-burn phasing rendezvous and run it"
That's it! The server will respond to your query, and you can continue using it as needed.
Here is a step-by-step guide with screenshots.
An MCP (Model Context Protocol) server that turns NASA's GMAT (General Mission Analysis Tool) into a tool an AI agent can actually use — not just talk about. Any MCP client (Claude Code, Claude Desktop, Cursor, custom apps) gets:
runGmat — the validation loop. Runs a GMAT mission script headless via GmatConsole and returns a classified outcome (completed | parse | convergence | run) with extracted errors and report-file contents. The agent writes a script, runs it, reads what broke, and fixes it — the same loop a mission designer uses.
getGmatIdioms — curated knowledge. A hand-built knowledge base of GMAT gotchas discovered through that loop (cumulative ElapsedSecs, no parentheses in conditionals, Propagate Synchronized for two-spacecraft burns, …), so the agent stops making the classic mistakes.
listGmatSamples / getGmatSample — known-good templates. The NASA sample-script corpus as a retrieval source for vetted mission patterns, plus an optional local corpus of community scripts (harvested from public repos, kept only if they pass a headless runGmat validation; listed with a community/ prefix). The harvested corpus stays local — it is gitignored because licenses vary.
searchDocs — semantic search over the GMAT documentation, embedded locally and cached in data/embeddings.json.
Example of what this enables: asked for a two-burn phasing rendezvous (700 km circular orbit, 30° separation), the agent derived the textbook solution, verified it exactly under two-body dynamics, discovered it misses by 47 km under J2 gravity by actually running it, and re-targeted the burns with GMAT's differential corrector to converge at 2.96 km — autonomously, in a handful of tool calls.
Node.js 18+ (ESM)
pnpm (project uses pnpm@10 per package.json)
A local GMAT install (R2025a tested) — for the runGmat and sample tools
An OpenAI API key — only if you want to rebuild the docs-search cache from scratch; the repo ships a prebuilt data/embeddings.json and queries are embedded with a local model
Related MCP server: Planet MCP
Clone the repo
git clone https://github.com/ginomoretta-creator/gmat-mcp-server.git
cd gmat-mcp-serverInstall dependencies
pnpm installConfigure environment
Create a .env.local at the repo root pointing at your GMAT install:
echo "GMAT_BIN=C:\Path\To\GMAT_R2025a\bin" > .env.localSee .env.example for all variables. The server loads .env.local / .env from the repo root automatically, so it works even when an MCP client spawns it with an empty environment.
Build the project
pnpm build(Optional) Rebuild the docs cache from the live docs — requires OPENAI_API_KEY in .env.local; skip this to use the prebuilt cache
pnpm run setupStart the MCP server
pnpm startThe server runs over stdio and exposes the searchDocs tool to your MCP client.
pnpm build: compile TypeScript to dist/
pnpm start: run server from dist/index.js (loads .env.local)
pnpm dev: run server in watch mode with ts-node
pnpm run setup: build cache from live docs (requires OpenAI API key)
pnpm run setup:test: build a smaller test cache using pages-test.json
Pass --force to setup to rebuild the cache from scratch:
pnpm run setup -- --forceGMAT_BIN (required for runGmat/samples): GMAT bin folder containing GmatConsole(.exe)
GMAT_SAMPLES (optional): samples dir (default: <GMAT_BIN>\..\samples)
GMAT_IDIOMS (optional): idioms file (default: ./data/gmat_idioms.md)
OPENAI_API_KEY (setup only): used to rebuild the docs-embedding cache
CACHE_DIR (optional): directory for embeddings.json (default: ./data)
BASE_URL (optional): docs base URL (default: https://documentation.help/gmat/)
NODE_ENV (optional): set to test to use pages-test.json during setup
MCP_PORT (optional): for wrappers/adapters that expose this stdio server via TCP/SSE. This server itself communicates over stdio and does not bind to a port; some clients or adapters may read MCP_PORT to decide which port to listen on.
Files read for env values:
Setup reads both .env and .env.local
Runtime reads .env.local (via pnpm start) or your shell env
claude mcp add gmat -- node C:\path\to\gmat-docs-mcp-server\dist\index.js(.env.local at the repo root is picked up automatically.)
This server communicates via stdio. Point your MCP client to execute the server in your project directory. Two common approaches:
pnpm startYour MCP client should spawn this command in the repo root (ensures .env.local is picked up).
There is a convenience wrapper that ensures env loading, then starts the compiled server:
node start-mcp.jsNote: If you run the server behind an adapter that serves MCP over SSE/TCP, you can set MCP_PORT to guide that adapter. The server code here still talks over stdio.
Inputs:
query (string, required)
topK (number, default 10, 1–50)
minScore (number, default 0.1, 0–1)
Output: formatted text with page name, source URL, similarity score, and extracted content.
Beyond doc search, the server exposes the GMAT validation loop and curated knowledge so an MCP client (Claude) can write → run → diagnose → fix GMAT missions autonomously:
runGmat — runs a GMAT .script (passed as text) headless via GmatConsole.exe and
returns { ok, stage, errors, reports, raw_tail }. stage ∈ completed | parse | convergence | run.
Inputs: script (string, required), timeoutSec (number, default 600 — raise for multi-day
low-thrust propagations). This is the closed validation loop.
getGmatIdioms — returns the curated GMAT idioms/gotchas knowledge base
(data/gmat_idioms.md). Read it before generating scripts to avoid common pitfalls.
listGmatSamples — lists the bundled NASA sample .script names plus any validated
community scripts (prefixed community/) — a retrieval corpus of known-good patterns.
getGmatSample — returns one sample's full text by name, to seed a phase from a vetted template.
These require a local GMAT install; see GMAT_BIN / GMAT_SAMPLES / GMAT_EXTRA_SAMPLES /
GMAT_IDIOMS in .env.example (defaults match a standard GMAT R2025a install).
The retrieval corpus is extensible. scripts/harvest-corpus.mjs turns a manifest of public-repo
pointers into a validated local corpus, using the same runGmat the MCP uses as the gate:
node scripts/harvest-corpus.mjs --manifest data/community-scripts/manifest.example.json --validatePipeline: download each script → scan (reject Python/MATLAB interface calls) →
normalize (rewrite hardcoded absolute ReportFile paths — the #1 portability killer) →
validate headless (keep only scripts that reach stage completed) → index each
survivor by detected technique into data/community-scripts/INDEX.md.
Without --validate it downloads, scans and normalizes only — nothing is executed.
--validate runs untrusted scripts through GmatConsole, so vet the manifest and prefer a
sandbox. The harvested scripts stay local (gitignored — licenses vary); only the pipeline and
the example manifest of public-repo pointers are committed, so the corpus is reproducible
without redistributing anyone's code.
The skills/ directory holds Claude skills
that teach an agent how to drive these tools — the procedural layer on top of the MCP's tools:
gmat-mission-design — the design-and-verify workflow: read the idioms first, seed from a
sample, write analytic expectations as the acceptance test, run, triage failures by stage,
and never cite a number that didn't come from a GMAT report. Benchmarked against a no-skill
baseline across three mission scenarios (Hohmann→GEO, electric orbit-raise, drag decay): 100%
vs 92% assertion pass rate, with far lower run-to-run variance.
gmat-improve — a run→diagnose→fix loop for existing scripts: baseline run as a
regression test, diagnosis against the failure catalog (hardcoded paths, non-ASCII, magic-number
burns, degenerate stop conditions), one re-run per change, before/after delivery.
Point your skill-aware client at the skills/ directory to load them.
Cache file: data/embeddings.json (or ${CACHE_DIR}/embeddings.json)
To rebuild: pnpm run setup -- --force
To use a smaller test set: pnpm run setup:test
The list of pages to scrape is defined in:
pages.json (full set)
pages-test.json (smaller set for tests)
You can edit these files to change the crawl scope. The parser attempts to extract meaningful sections by headings and convert them to Markdown for embedding.
Error: OPENAI_API_KEY environment variable is required
Create .env.local (and optionally .env) with OPENAI_API_KEY
Cache not found at data/embeddings.json. Run setup first.
Run pnpm build && pnpm run setup to generate the cache
Network timeouts while scraping
The scraper retries with exponential backoff; rerun setup or adjust your network
MCP client can’t see tools
Ensure the server is started from the project directory and connected via stdio
Confirm pnpm start logs show the server is running and the cache is loaded
src/
index.ts # MCP server entry (stdio)
setup.ts # Setup pipeline: scrape → parse/chunk → embed → cache
tools/ # MCP tool definitions and handlers
utils/ # scraper, parser, embedder, cache, search
data/ # Default cache directory (embeddings.json)
pages.json # Full list of pages to scrape
pages-test.json # Smaller list for testing
dist/ # Compiled JavaScript (after pnpm build)
start-mcp.js # Wrapper to load env and run the serverThe documentation-search foundation (scrape → parse/chunk → embed → cache pipeline) was originally built by Ignacio García as gmat-docs-mcp-server. The GMAT execution copilot tools (runGmat, idioms knowledge base, sample corpus) and the local-embedding runtime were added on top.
ISC
Return the curated GMAT idioms & gotchas knowledge base - hard-won rules that prevent common script errors (parameter dependencies, ElapsedSecs being cumulative, no parentheses in conditionals, ImpulsiveBurn vs FiniteBurn, Propagate Synchronized for two-spacecraft burns, etc.). Read this before writing GMAT scripts.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description bears the full burden of behavioral disclosure. It fully describes the content and purpose, implying read-only behavior and no side effects. While it doesn't detail caching or access requirements, these are not critical for this simple retrieval tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence with embedded examples, effectively front-loading the purpose. While slightly long, every phrase adds value and no redundancy exists.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given zero parameters, no output schema, and sibling tools focusing on other operations, the description is complete enough. It explains what the tool returns and why it is useful, though it could hint at return format for completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has no parameters, so the description need not explain parameter semantics. The description adds value by detailing the content returned, surpassing the baseline expectation for a parameterless tool.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool returns a curated knowledge base of GMAT idioms and gotchas, with specific examples. It distinguishes itself from sibling tools (getGmatSample, listGmatSamples, runGmat, searchDocs) by focusing on preventing script errors.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly advises reading this before writing GMAT scripts, providing clear context for use. However, it does not specify when not to use it or mention alternative tools, though the sibling tools serve different purposes.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Return the full text of one NASA sample script by file name (from listGmatSamples). Use as a known-good template to seed a phase.
| Name | Required | Description | Default |
|---|---|---|---|
| name | Yes | Sample file name, e.g. 'Ex_SafetyEllipse.script' or 'community/daniestevez__jupyter_notebooks__tcm3.script'. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It correctly identifies the operation as a read ('Return the full text'), but does not disclose error handling, authentication requirements, or potential side effects. The 'seed a phase' hint adds mild context.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences, immediately front-loading the primary purpose. Every word serves a purpose; there is no redundancy or extraneous information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the simplicity of the tool (single parameter, no output schema, no nested objects), the description covers the essential aspects: what it returns, how to identify the file, and a suggested use case. It feels complete for the agent's decision-making.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, and the description adds meaningful examples showing filename format (e.g., 'Ex_SafetyEllipse.script') and supports the 'from listGmatSamples' hint, going beyond the schema's basic 'Sample file name' description.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Return') and resource ('NASA sample script'), and distinguishes from sibling tools by stating it retrieves by file name from 'listGmatSamples'. This leaves no ambiguity about the tool's core function.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly states to 'Use as a known-good template to seed a phase', providing a clear use case. It also implicitly advises that filenames come from 'listGmatSamples', but does not mention when not to use or alternatives like 'getGmatIdioms' or 'runGmat'.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List the available known-good GMAT sample scripts, each tagged with the techniques it demonstrates (targeting, optimization, finite-burn, OD/estimation, B-plane, interplanetary, libration-point, drag, attitude, ...). Covers NASA's official samples plus a locally validated community corpus (real-mission scripts harvested from public repos that pass a headless run; prefixed 'community/'). Scan the tags to pick the right seed for a mission, then getGmatSample to read it.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It explains the scope (NASA official plus community corpus), tagging, and naming convention. It's clear what the tool does and what the output represents. Minor omission: no mention of ordering or pagination, but for a parameterless list it's largely transparent.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Single paragraph, well-structured with clear information. Could be slightly more concise by removing the ellipsis at the end, but overall it's efficient and front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no parameters and no output schema, the description provides sufficient context: it explains what the tool lists, the source of samples, and how to use it in conjunction with getGmatSample. It is complete for the tool's purpose.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
There are no parameters (schema coverage 100%), so the baseline is 4. The description adds value by explaining what the output contains (tags, community prefix), which compensates for the lack of parameters.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it lists available GMAT sample scripts with tags for techniques. It distinguishes from siblings like getGmatSample and runGmat by explicitly mentioning that the list is for browsing and then using getGmatSample to read.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicit guidance: 'Scan the tags to pick the right seed for a mission, then getGmatSample to read it.' This tells when to use this tool (to browse/list and select) and when to use getGmatSample (to read the actual content).
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Run a GMAT mission script (text) headless and return the validated outcome: {ok, stage, errors, reports, raw_tail}. This is the validation loop - write a script, run it, read the errors/results, fix, repeat. 'stage' is one of completed | parse | convergence | run.
| Name | Required | Description | Default |
|---|---|---|---|
| script | Yes | The full GMAT .script text to run. | |
| timeoutSec | No | Max seconds before aborting (default 600). Use higher for multi-day low-thrust propagations. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It states the tool runs 'headless' and returns a validated outcome, implying no persistent side effects. However, it does not explicitly disclose safety, resource usage, or whether the script modifies system state, leaving some ambiguity.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is three sentences with no wasted words. It front-loads the core purpose and output shape, then clarifies the usage pattern and stage values. Every sentence is informative and earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite lacking an output schema, the description specifies the return structure ({ok, stage, errors, reports, raw_tail}) and defines the possible stage values. This covers the essential information for the agent to understand the tool's behavior. The tool is moderately complex with two parameters, and the description is adequate.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the baseline is 3. The description adds value by advising to increase timeout for 'multi-day low-thrust propagations', which is useful guidance beyond the schema's default value description.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'Run' and the resource 'GMAT mission script (text)', and explains the outcome as a validated result with specific fields. It distinguishes itself from sibling tools like getGmatIdioms or listGmatSamples by focusing on execution.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly frames the tool as part of a validation loop ('write, run, read, fix, repeat'), which gives context for when to use it. However, it does not explicitly state when not to use or compare with alternatives beyond the implied purpose.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Semantic search over GMAT documentation. Returns relevant sections with full content and sources.
| Name | Required | Description | Default |
|---|---|---|---|
| query | Yes | The search query - can be a question, topic, or keyword related to GMAT | |
| topK | No | Maximum number of results to return (default: 5). Keep small - each result includes the full section text. | |
| minScore | No | Minimum cosine similarity threshold (0-1, default: 0.3). Lower it only if a query returns nothing. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It does not explicitly state read-only behavior, authentication needs, rate limits, or what happens on empty results. The description is too brief for full transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Single sentence that front-loads the purpose and result, with no wasted words. Efficient and to the point.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
No output schema exists, so description should convey return format. It mentions 'full content and sources' but does not specify structure (list, array, etc.) or pagination. Adequate but not detailed.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with clear descriptions for query, topK, and minScore. The description adds no extra semantics beyond 'returns relevant sections,' so baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it performs semantic search over GMAT documentation and returns relevant sections with content and sources, distinguishing it from sibling tools focused on idioms, samples, and running GMAT.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies use for general search but does not explicitly state when to use this tool over alternatives or provide exclusions. Sibling tools suggest specific purposes, but no direct guidance is given.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Each tool has a clearly distinct purpose: idioms for rules, samples for templates, run for execution, and search for documentation. No functional overlap.
All names use camelCase with verb prefixes (get, list, run, search), but 'list' and 'run' differ from the predominant 'get' pattern. Still predictable and readable.
5 tools cover the essential operations for GMAT script development without overload. Each tool earns its place for a focused server.
Core lifecycle (access knowledge, fetch samples, run scripts, search docs) is covered. Minor gap: no tool for modifying or saving scripts, but that fits the intended workflow.
Unclaimed servers have limited discoverability.
If you are the server author, to access and configure the admin panel.
Persistent memory and knowledge management for AI agents with semantic search and 50+ tools.
Build, validate, and deploy multi-agent AI solutions from any AI environment.
Create and manage AI agents that collaborate and solve problems through natural language interacti…
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/ginomoretta-creator/gmat-mcp-server'
If you have feedback or need assistance with the MCP directory API, please join our Discord server
