Elite Dangerous MCP
Server Configuration
Describes the environment variables required to run the server.
| Name | Required | Description | Default |
|---|---|---|---|
| INARA_API_KEY | No | API key for Inara (optional, but required for Inara tools) | |
| ED_JOURNAL_DIR | No | Directory containing Elite Dangerous journal files (optional, overrides default locations) |
Instructions
Guidance the server publishes about itself, which clients place ahead of the tool catalog so the model reads it before choosing anything.
This server publishes no instructions, or was last inspected before Glama recorded them.
Capabilities
Features and capabilities supported by this server
Protocol revision2025-11-25
| Capability | Details |
|---|---|
| tools | {
"listChanged": false
} |
| prompts | {
"listChanged": false
} |
| resources | {
"subscribe": false,
"listChanged": false
} |
| experimental | {} |
Tools
Functions exposed to the LLM to take actions
| Name | Description |
|---|---|
| get_commander_statusC | Commander name, current system/station, ship, credits from local journals. |
| get_current_locationB | Current system + coords + station from latest Location/FSDJump/Docked event. |
| get_ship_loadoutB | Current ship + modules from latest Loadout event. |
| get_journal_historyC | Recent relevant journal events, newest first (FSDJump, Docked, Loadout, ...). |
| edsm_sphere_systemsC | Systems within radius_ly of a system name or x/y/z coords (EDSM). |
| edsm_system_infoC | Population/government/stations for one system + claimable assessment (EDSM). |
| spansh_find_nearby_stationsC | Stations nearest to galactic coords, slimmed for shopping lists (Spansh). |
| spansh_query_systemsC | Flexible Spansh systems search, e.g. {"population": {"value": [0,0]}}. |
| inara_search_nearestC | Nearest stations/systems via Inara API (needs INARA_API_KEY). |
| eddn_live_sampleB | Bounded sample of live EDDN relay messages (needs pyzmq + network). |
| find_colonisation_candidatesB | Zero-pop, claimable systems near a constellation/centre. centre: 'teapot' (Sagittarius asterism) or an EDSM system name or 'x,y,z'. Workflow: resolve Teapot anchor stars -> EDSM sphere search per anchor -> batch detail lookup -> filter zero-pop/uncontrolled/stationless -> dedupe. |
| build_cargo_shopping_listC | Anaconda max-cargo module list + where to buy near your current location. Uses journals for current system/coords + owned modules, Spansh for nearby stations with outfitting, EDSM sphere as fallback. Prices/stock rotate; verify at the station. |
Prompts
Interactive templates invoked by user choice
| Name | Description |
|---|---|
| colonisation_survey | |
| anaconda_cargo_refit |
Resources
Contextual data attached and managed by the client
| Name | Description |
|---|---|
No resources | |
TDQS
Scored across 12 tools
Several tools retrieve similar data from different providers (e.g., inara_search_nearest vs spansh_find_nearby_stations vs edsm_sphere_systems; get_commander_status vs get_current_location), so an agent may need descriptions to choose correctly. Core distinctions exist by provider/granularity, but overlap remains.
All names are snake_case and follow recognizable source/action prefixes: get_* for local journal tools, provider_* for external API calls, and verb_noun for composite tools. Minor deviations like edsm_sphere_systems (noun phrase) and find_colonisation_candidates (no source prefix) keep it from perfect consistency.
12 tools is well within the ideal 3-15 range and each tool maps to a distinct data source or workflow (local journals, EDSM, Spansh, Inara, EDDN, colonisation, shopping list). No tool feels like filler.
The surface covers the apparent colonisation/shopping/status domain well, including candidate finding, system assessment, and shopping-list generation. Minor gaps exist for standalone station market/outfitting or shipyard queries, but agents can work around them via existing external-search tools.