The EVE Online OSINT MCP Server provides comprehensive open-source intelligence (OSINT) capabilities for EVE Online entities, allowing AI assistants to gather detailed data by name.
• Character Intelligence: Retrieve ESI public data (birthday, gender, description, security status, title), complete corporation history, current affiliations, EveWho data (last login), and zKillboard statistics (recent killmails, PvP stats) • Corporation Analysis: Access ESI corporation information (name, ticker, member count, tax rate, founding date, CEO details), EveWho statistics (activity metrics, 7-day delta), alliance affiliations, full member lists, and corporate details • Alliance Intelligence: Obtain ESI alliance data (name, ticker, founding date, creator/executor details), member corporations with individual stats, growth trends, and leadership information • Multi-API Integration: Combines data from ESI, EveWho, and zKillboard for comprehensive intelligence • Name Resolution: Automatically converts entity names to IDs and vice versa • Rate Limiting Compliance: Respects all API rate limits with proper error handling
Runtime environment for executing the MCP server application
Package manager used for dependency management and running development scripts
Alternative package manager option for dependency management
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 OSINT MCP Server character-osint characterName="John Doe""
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 provides OSINT (Open Source Intelligence) capabilities for EVE Online using multiple APIs including ESI, EveWho, and zKillboard. This server allows AI assistants to gather comprehensive intelligence on EVE Online characters, corporations, and alliances by name.
Character Intelligence: Get detailed information about EVE Online characters including:
ESI public character data (birthday, gender, description, security status)
Complete corporation history with dates
Current affiliations and titles
zKillboard statistics and recent killmails
Corporation Analysis: Retrieve comprehensive corporation data including:
ESI corporation information (member count, tax rate, founding date)
EveWho member lists with activity metrics
Alliance affiliations and leadership details
Alliance Intelligence: Analyze alliance composition including:
ESI alliance information (founding date, ticker, executor corp)
Member corporations with detailed statistics
Growth trends and activity metrics
Name Resolution: Automatically converts entity names to IDs and vice versa using ESI API
Multi-API Integration: Combines data from ESI, EveWho, and zKillboard for comprehensive intelligence
Rate Limiting Compliance: Respects all API rate limits and includes proper error handling
Related MCP server: EVE ESI Tool
character-osint)Investigates individual EVE Online characters by name.
Parameters:
characterName (string): The exact name of the character to investigate
Returns:
ESI Character Information: Birthday, gender, description, security status, title
Corporation History: Complete history from ESI with corporation names and dates
Current Affiliations: Corporation and alliance information
EveWho Data: Additional context including last login information
zKillboard Data: Recent killmails and PvP statistics
corporation-osint)Analyzes EVE Online corporations by name.
Parameters:
corporationName (string): The exact name of the corporation to investigate
Returns:
ESI Corporation Information: Name, ticker, member count, tax rate, founding date, CEO details
EveWho Statistics: Total member count, 7-day delta, activity metrics
Alliance Affiliation: Current alliance information (if applicable)
Member List: Complete member roster with join dates and security status
Corporate Details: Description, URL, war eligibility status
alliance-osint)Examines EVE Online alliances by name.
Parameters:
allianceName (string): The exact name of the alliance to investigate
Returns:
ESI Alliance Information: Name, ticker, founding date, creator and executor corporation details
EveWho Statistics: Total member count, corporation count, 7-day delta
Member Corporations: Complete list with individual member counts and activity metrics
Growth Trends: Historical data and activity patterns
Leadership Information: Creator and executor corporation details
EveWho API Information: Documentation about the EveWho API, rate limits, and data sources
EVE OSINT Report: Generate comprehensive intelligence reports with customizable focus areas (membership, activity, history, connections)
Node.js 18+
npm or pnpm
To install eve-online-osint-mcp for Claude Desktop automatically via Smithery:
npx -y @smithery/cli install @kongyo2/eve-online-osint-mcp --client claudegit clone https://github.com/your-username/eve-online-osint-mcp.git
cd eve-online-osint-mcp
npm installStart the server in development mode with interactive CLI:
npm run devStart the server for production use:
npm run startRun the test suite:
npm run test# Check code style
npm run lint
# Fix code style issues
npm run formatMIT License - see LICENSE file for details.
Get OSINT information about an EVE Online alliance by name. Returns member corporations, total member count, and alliance details.
| Name | Required | Description | Default |
|---|---|---|---|
| allianceName | Yes | The exact name of the EVE Online alliance to investigate |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations provide readOnlyHint=true and openWorldHint=true, indicating it's a safe read operation with open-world data. The description adds value by specifying the return content (member corporations, total member count, alliance details), which isn't covered by annotations. It doesn't contradict annotations, as 'Get' aligns with read-only behavior.
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, efficient sentence that front-loads the purpose and key details without any wasted words. It's appropriately sized for a simple tool with one parameter and clear annotations.
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 tool's low complexity (one parameter, read-only, open-world), annotations cover safety and data scope, and the description specifies return content. However, there's no output schema, so the description could benefit from more detail on output structure or error handling, but it's largely complete for this 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?
Schema description coverage is 100%, with the parameter 'allianceName' well-documented in the schema. The description adds minimal semantic context by mentioning 'by name', but doesn't provide additional details beyond what the schema already specifies. Baseline 3 is appropriate given high schema coverage.
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 specific verb ('Get OSINT information') and resource ('about an EVE Online alliance by name'), and distinguishes it from sibling tools by specifying it's for alliances rather than characters or corporations. It provides a concrete outcome: 'Returns member corporations, total member count, and alliance details.'
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 usage context by specifying 'by name' and listing what it returns, which helps differentiate it from siblings like character-osint and corporation-osint. However, it lacks explicit guidance on when to use this tool versus alternatives or any prerequisites or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get OSINT information about an EVE Online character by name. Returns character details, corporation history, and current status.
| Name | Required | Description | Default |
|---|---|---|---|
| characterName | Yes | The exact name of the EVE Online character to investigate |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already provide readOnlyHint=true and openWorldHint=true, indicating this is a safe read operation with potentially incomplete data. The description adds context about what information is returned (character details, corporation history, current status), which goes beyond annotations. However, it doesn't disclose behavioral traits like rate limits, authentication needs, or data freshness.
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, well-structured sentence that efficiently communicates purpose, input method, and return values. Every element earns its place with zero wasted words, making it easy to parse and understand.
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 read operation with one parameter and good annotations, the description provides adequate context about what information is returned. However, without an output schema, the description could benefit from more detail about the structure or format of the returned data (character details, corporation history, current status).
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 100%, with the parameter 'characterName' clearly documented as 'The exact name of the EVE Online character to investigate'. The description adds marginal value by reinforcing that investigation is 'by name', but doesn't provide additional semantic context beyond what the schema already states.
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 specific action ('Get OSINT information') and resource ('about an EVE Online character by name'), and distinguishes from sibling tools (character vs alliance/corporation). It specifies the exact scope of information returned: character details, corporation history, and current status.
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 when to use this tool (for character investigation by name) and distinguishes it from sibling tools (alliance-osint, corporation-osint) by specifying the target resource. However, it doesn't explicitly state when NOT to use it or provide alternative scenarios beyond the sibling differentiation.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get OSINT information about an EVE Online corporation by name. Returns member list, activity metrics, and corporation details.
| Name | Required | Description | Default |
|---|---|---|---|
| corporationName | Yes | The exact name of the EVE Online corporation to investigate |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations provide readOnlyHint=true and openWorldHint=true, indicating this is a safe read operation with open-world data. The description adds value by specifying the return content: 'Returns member list, activity metrics, and corporation details,' which gives context on what information is retrieved. It doesn't disclose behavioral traits like rate limits or auth needs, but with annotations covering safety, this is acceptable.
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, front-loaded with the core purpose and followed by return details. Every sentence adds value: the first states what the tool does, and the second specifies the output. There is no wasted text, making it highly concise and well-structured.
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 tool's complexity (simple lookup with one parameter), annotations cover safety (readOnlyHint, openWorldHint), and the description specifies return content. There is no output schema, so the description's mention of return values is helpful. However, it could be more complete by addressing potential errors or usage nuances, but it's largely adequate for the 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?
Schema description coverage is 100%, with the parameter 'corporationName' documented as 'The exact name of the EVE Online corporation to investigate.' The description adds minimal semantics by reinforcing 'by name' but doesn't provide additional details beyond what the schema already covers. Baseline score of 3 is appropriate as the schema handles parameter documentation effectively.
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's purpose: 'Get OSINT information about an EVE Online corporation by name.' It specifies the verb ('Get'), resource ('OSINT information about an EVE Online corporation'), and scope ('by name'). However, it doesn't explicitly differentiate from sibling tools (alliance-osint, character-osint) beyond mentioning 'corporation' specifically.
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 usage context by stating 'by name,' suggesting this tool is for looking up specific corporations. However, it doesn't provide explicit guidance on when to use this tool versus the sibling tools (alliance-osint, character-osint), nor does it mention any prerequisites or exclusions. The usage is implied but not clearly articulated.
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.
v1.0.0alliance-osintcharacter-osintcorporation-osintEach tool has a clearly distinct purpose targeting a specific EVE Online entity type: alliance, character, and corporation. The descriptions specify unique data returns (e.g., member corporations vs. character details vs. member list), eliminating any overlap or confusion in tool selection.
All tool names follow a consistent pattern of 'entity-osint' using snake_case, with 'osint' as a suffix indicating the operation type. This uniformity makes the tools predictable and easy to understand at a glance.
With only 3 tools, the set feels thin for an OSINT server, as it lacks broader investigative capabilities like searching across entities or accessing related data such as killmails or market information. However, it covers the core entities adequately for basic lookups.
The tools provide complete coverage for retrieving OSINT data on the main EVE Online entities (alliance, character, corporation), with no dead ends for basic queries. A minor gap exists in the inability to search or cross-reference data beyond direct name lookups, but agents can work around this with sequential tool calls.
Unclaimed servers have limited discoverability.
If you are the server author, to access and configure the admin panel.
Hosted MCP server for live public-data APIs and Skills for AI agents.
MCP server unifying ERPs, CRMs, APIs and knowledge base for Claude, ChatGPT and Gemini.
Hosted MCP server connecting AI assistants to 9,000+ apps and 40,000+ actions via Zapier.
MCP server connecting AI agents to 100+ apps (Gmail, Slack, Notion, GitHub) via one-click OAuth.
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/kongyo2/EVE-Online-OSINT-MCP'
If you have feedback or need assistance with the MCP directory API, please join our Discord server
