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., "@EVE Online MCP Find profitable mining systems near Jita using current market data and risks."
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.
A read-only Model Context Protocol server for the complete EVE Online ESI API surface. It lets an AI assistant discover live ESI capabilities, inspect exact parameters and OAuth requirements, retrieve public or character data, and turn that context into practical plans for your next adventure.
The server is generated at runtime from a pinned copy of CCP's OpenAPI 3.1 document. Today it exposes all GET/HEAD routes plus an explicitly audited allowlist of semantically read-only POST lookups (bulk ID/name resolution, affiliations, CSPA calculation, and asset name/location lookup). Every state-changing operation is excluded.
search_esi_operations finds endpoints using ordinary keywords, ESI tags, and authentication requirements.
get_esi_operation returns exact parameters, request-body schema, OAuth scopes, cache hints, and rate-limit metadata.
call_esi invokes only catalogued read operations. It rejects undeclared parameters, validates values, fixes the origin to ESI, supplies compatibility headers, and never accepts an Authorization header from a tool call.
eve-esi://catalog describes the pinned API coverage and excluded operation count.
plan_eve_adventure is a prompt for evidence-based recommendations with costs, preparation, risk, travel, and a concrete first action.
ESI cache headers are respected in memory, pagination/rate-limit headers are returned to the model, errors remain structured, responses are limited to 5 MB by default, and a descriptive User-Agent is sent as recommended by ESI. It is derived from the installed package version and has the form eve-online-mcp/<version> (adam@hammo.dev; +https://github.com/HammoTime/eve-online-mcp).
Related MCP server: Open API MCP Server
All project commands are intended to run in the devcontainer. In VS Code, choose Dev Containers: Reopen in Container. The container installs the locked dependencies automatically.
From another devcontainer-capable editor, open this repository using .devcontainer/devcontainer.json. If you only have Docker, the equivalent environment is:
docker build --target development -f .devcontainer/Dockerfile -t eve-online-mcp-dev .
docker run --rm -it -v "$PWD:/workspace" -w /workspace eve-online-mcp-dev npm ciThe supported commands are:
npm run dev # serve MCP over stdio from TypeScript
npm run validate # formatting, lint, typecheck, tests/coverage, build
npm run schema:check # compare the pinned and current upstream schemas
npm run schema:update # replace the pin with canonical current OpenAPI JSONOnce published, configure your MCP host to run the npm package directly:
{
"mcpServers": {
"eve-online": {
"command": "npx",
"args": ["-y", "eve-online-mcp"]
}
}
}For a local checkout, build in the devcontainer and use node /absolute/path/to/eve-online-mcp/dist/index.js instead.
Public ESI routes need no credentials and never trigger login. On the first operation that needs character or corporation data, the server automatically opens EVE SSO in the browser. After consent it stores only the refresh credential in the user's OS configuration directory, rotates it when EVE returns a replacement, and manages short-lived access tokens in memory. No client secret or manual token handling is required.
The package ships with this public PKCE client configuration:
Client ID: 6a65f1e650d240659dafbad29fb55e05
Callback URL: http://localhost:52765/callback
The callback must match the EVE application registration exactly. PKCE is intended for local applications that cannot keep a client secret, so never distribute or commit the client secret. The login can also be started or managed explicitly:
npx eve-online-mcp auth login
npx eve-online-mcp auth status
npx eve-online-mcp auth logoutThe default login requests the complete authenticated read-only scope set from the pinned schema. A narrower login can be requested with auth login --scopes "scope.one scope.two", though operations outside that grant will remain unavailable.
esi-alliances.read_contacts.v1
esi-assets.read_assets.v1
esi-assets.read_corporation_assets.v1
esi-calendar.read_calendar_events.v1
esi-characters.read_agents_research.v1
esi-characters.read_blueprints.v1
esi-characters.read_contacts.v1
esi-characters.read_corporation_roles.v1
esi-characters.read_fatigue.v1
esi-characters.read_fw_stats.v1
esi-characters.read_loyalty.v1
esi-characters.read_medals.v1
esi-characters.read_notifications.v1
esi-characters.read_standings.v1
esi-characters.read_titles.v1
esi-clones.read_clones.v1
esi-clones.read_implants.v1
esi-contracts.read_character_contracts.v1
esi-contracts.read_corporation_contracts.v1
esi-corporations.read_blueprints.v1
esi-corporations.read_contacts.v1
esi-corporations.read_container_logs.v1
esi-corporations.read_corporation_membership.v1
esi-corporations.read_divisions.v1
esi-corporations.read_facilities.v1
esi-corporations.read_fw_stats.v1
esi-corporations.read_medals.v1
esi-corporations.read_standings.v1
esi-corporations.read_starbases.v1
esi-corporations.read_structures.v1
esi-corporations.read_titles.v1
esi-corporations.track_members.v1
esi-fittings.read_fittings.v1
esi-fleets.read_fleet.v1
esi-industry.read_character_jobs.v1
esi-industry.read_character_mining.v1
esi-industry.read_corporation_jobs.v1
esi-industry.read_corporation_mining.v1
esi-killmails.read_corporation_killmails.v1
esi-killmails.read_killmails.v1
esi-location.read_location.v1
esi-location.read_online.v1
esi-location.read_ship_type.v1
esi-mail.read_mail.v1
esi-markets.read_character_orders.v1
esi-markets.read_corporation_orders.v1
esi-markets.structure_markets.v1
esi-planets.manage_planets.v1
esi-planets.read_customs_offices.v1
esi-search.search_structures.v1
esi-skills.read_skillqueue.v1
esi-skills.read_skills.v1
esi-universe.read_structures.v1
esi-wallet.read_character_wallet.v1
esi-wallet.read_corporation_wallets.v1EVE_ACCESS_TOKEN, EVE_REFRESH_TOKEN, EVE_CLIENT_ID, and EVE_CLIENT_SECRET remain supported as non-default overrides for automation or existing credentials. The server reports missing JWT scopes before spending an ESI request.
Optional settings:
Variable | Purpose |
| Optional override for a downstream app's identity/contact |
| Overrides the 5,000,000-byte response ceiling |
| Loads a different local OpenAPI document for development |
| Overrides the OS credential file location |
| Set to |
| Overrides the localhost callback for a custom application |
Do not commit tokens or client secrets. Tool responses never include the token, and callers cannot override the ESI origin or inject arbitrary headers.
Select the plan_eve_adventure prompt in your MCP host, or ask something like:
Using my current location, skills, wallet, assets, and the nearby market, give me three two-hour exploration plans. Explain risk and startup cost, then recommend the best first step.
The model can discover the relevant endpoints instead of relying on memorized route names. Large paginated datasets should be requested one page at a time using the returned x-pages header.
esi-schema-monitor.yml runs daily and on demand. It downloads CCP's current schema, canonicalizes it, compares SHA-256 hashes and operation definitions, and creates one deduplicated GitHub issue describing added, removed, and modified routes. Further detections comment on the open issue rather than creating noise.
After reviewing an update:
npm run schema:update
npm run validateReview any new non-GET operation manually. Read-only POST routes are deliberately allowlisted in src/openapi.ts; a new route is not exposed until its semantics are verified.
release.yml runs on every push to main. Release Please maintains a release pull request using Conventional Commit history; use subjects such as fix: repair release workflow or feat: add route planning. That pull request updates package.json and CHANGELOG.md together. Merging it creates the matching Git tag and GitHub Release, then validates and packs the project inside the devcontainer and publishes that exact version to npm. A guarded assertion compares the release version, Git tag, and the tagged package.json before publishing. The workflow also bootstraps an existing matching GitHub Release when its package version is still absent from npm.
Publishing uses npm trusted publishing through GitHub OIDC and produces provenance. On npm, configure the trusted publisher as repository HammoTime/eve-online-mcp, workflow release.yml, with direct publishing allowed. Because an unclaimed package cannot have trusted publishing configured yet, its first release requires a granular npm automation token stored as the NPM_TOKEN GitHub secret. That one-time bootstrap publish does not request provenance, which also permits recovery of a historical tag whose repository metadata predates the current GitHub owner. After the initial publish, configure trusted publishing and remove the secret; subsequent OIDC releases publish provenance.
Vitest covers catalog filtering, local $ref resolution, safe URL and header construction, schema validation, OAuth refresh and scopes, caching, response limits, error handling, schema diffing, and end-to-end MCP tool/resource/prompt calls over an in-memory transport. Coverage gates require at least 80% for statements, lines, functions, and branches. GitHub CI executes the same npm run validate command inside the devcontainer image.
Licensed under the GNU AGPL v3.
Execute an ESI GET/HEAD operation selected by operationId. Only parameters declared by the pinned OpenAPI schema are accepted. Mutating ESI operations cannot be selected.
| Name | Required | Description | Default |
|---|---|---|---|
| body | No | JSON body for explicitly audited, semantically read-only bulk lookup POST operations | |
| path | No | Path parameter values keyed by their schema names | |
| query | No | Query parameter values keyed by their schema names | |
| headers | No | Optional declared ESI headers (for example Accept-Language or If-None-Match); Authorization cannot be supplied here | |
| operationId | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already cover read-only, idempotent, and non-destructive behavior, so the description adds some value by stating the declared-parameters constraint and the inability to select mutating operations. However, it misrepresents the allowed method set by saying 'GET/HEAD' while the schema's body parameter supports read-only POST operations, which is a meaningful behavioral omission.
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?
Three short sentences with no filler: action comes first, followed by the parameter constraint and the mutation exclusion. Every sentence 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?
For a generic dispatch tool with no output schema, the description leaves important context unstated: it does not mention that responses follow the selected operation's schema, how to discover valid operationIds, or the read-only POST exception. The GET/HEAD vs POST body ambiguity further reduces 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?
Schema description coverage is 80%, so most parameters (path, query, headers, body) are already documented in the schema. The main description adds only that operationId selects the operation and that undeclared parameters are rejected, which is useful but not substantial enough to exceed the baseline.
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 identifies the action ('Execute'), the resource ('ESI GET/HEAD operation selected by operationId'), and the read-only scope, which distinguishes it from the sibling search/inspection tools. However, the 'GET/HEAD' qualifier is too narrow because the body parameter schema explicitly mentions 'semantically read-only bulk lookup POST operations,' creating an internal inconsistency.
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?
It gives explicit when-not guidance: mutating ESI operations cannot be selected and only schema-declared parameters are accepted. It does not name the sibling tools as alternatives for discovering or inspecting operations, so it stops short of full 5-level routing guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Return the exact path/query/header parameters, OAuth scopes, cache hints, and rate-limit metadata for one read-only ESI operation before calling it.
| Name | Required | Description | Default |
|---|---|---|---|
| operationId | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, openWorldHint, idempotentHint, and destructiveHint false. The description adds meaningful behavioral context by specifying exactly what metadata will be returned and confirms the read-only nature. It does not cover error behavior for unknown operationIds, but this is not a major gap given the annotations and scope.
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?
A single, dense sentence that front-loads the main action and enumerates the return contents without any wasted words. It is appropriately sized for the tool's simple interface.
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?
For a simple one-parameter introspection tool, the description fully covers what the tool returns and when to use it. There is no output schema, so the explicit enumeration of returned metadata is sufficient. Sibling tool names provide the surrounding workflow context.
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 schema provides no description for operationId and coverage is 0%, so the description must compensate. It conveys the general purpose but does not explicitly explain that operationId should be a valid ESI operation identifier returned by search_esi_operations. The parameter name is fairly self-explanatory, which raises it from 2, but the description could have stated this relationship more directly.
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 names the exact resource ('one read-only ESI operation') and the specific metadata delivered (path/query/header parameters, OAuth scopes, cache hints, rate-limit metadata). This clearly distinguishes it from the sibling search_esi_operations and call_esi tools.
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 phrase 'before calling it' explicitly identifies this as a pre-call inspection tool, giving clear context for when to use it. It does not explicitly name search_esi_operations as the alternative for discovering operations, but the sibling list and the tool's purpose imply this distinction.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Find read-only EVE Online ESI operations by natural-language keywords, exact tag, or authentication requirement. Start here when choosing which game data to retrieve.
| Name | Required | Description | Default |
|---|---|---|---|
| tag | No | Exact ESI tag, such as Character, Skills, Market, Routes, or Universe | |
| limit | No | ||
| query | No | Keywords matched across operation IDs, paths, summaries, descriptions, tags, and scopes | |
| authenticated | No | true for character/corporation data; false for public data |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The annotations already cover the safety profile (readOnlyHint, idempotentHint, non-destructive), so the description only needs to add context beyond that. It adds the search-mode behavior and discovery positioning, but doesn't describe the output shape or clarify that results are operation metadata rather than live game data.
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?
Two short sentences with no filler. The action and search dimensions are front-loaded, and 'Start here...' adds useful routing guidance that 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?
For a simple optional-parameter search tool with rich annotations, the description covers what it finds and how to search. The only notable gap is that it doesn't explicitly state the return format or that the tool returns operation metadata rather than actual game data, but the tool's purpose is still clear enough for correct invocation.
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 schema already describes tag, query, and authenticated; the description reinforces these by mapping them to natural-language keywords, exact tag, and authentication requirement. It doesn't mention `limit`, but the schema provides a default and min/max, making it sufficiently clear.
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 ('Find'), a clear resource ('read-only EVE Online ESI operations'), and three explicit search dimensions (keywords, tag, authentication requirement). This distinguishes it from the get/call siblings and makes the tool's role obvious.
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?
'Start here when choosing which game data to retrieve' gives clear context and positioning as the discovery step. It does not explicitly name get_esi_operation or call_esi as alternatives or state when not to use this tool, so it falls short of a 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections. Dates show when Glama detected each change.
v0.1.2call_esiget_esi_operationsearch_esi_operationsEach tool has a clearly distinct role: search discovers operations, get returns metadata for a specific operation, and call executes the operation. There is no meaningful overlap or ambiguity between them.
The names are all snake_case with a verb-first pattern, which is consistent and predictable. The only minor deviation is call_esi omitting the 'operation' noun that appears in the other two tool names.
Three tools is an appropriate and focused size for a gateway that discovers, inspects, and executes read-only ESI operations. Each tool serves a necessary step in the workflow without redundancy.
For its stated purpose of providing read-only EVE Online ESI access, the set is complete: search, inspect, and call cover the full lifecycle. Mutating operations are intentionally excluded and clearly communicated, so there are no obvious gaps.
Unclaimed servers have limited discoverability.
If you are the server author, to access and configure the admin panel.
Read and update your Everway trips and itineraries from any MCP-compatible AI assistant.
Query your team's drift, vulnerability, and upgrade data from any AI assistant. OAuth 2.1, 51 tools.
Query your Twitch streams, events, supporters, raids & rankings from an AI assistant via OAuth.
Web search and page-reading for AI agents. One-click OAuth connect, or a Caesar API key.
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/HammoTime/eve-online-mcp'
If you have feedback or need assistance with the MCP directory API, please join our Discord server
