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 University Wiki MCP Server search for Rifter frigate fittings"
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 Model Context Protocol (MCP) server that provides access to EVE University Wiki content with automatic Wayback Machine fallback for enhanced reliability.
This server enables AI assistants to search, retrieve, and explore EVE Online knowledge from the comprehensive EVE University Wiki, making it an invaluable resource for EVE Online players, developers, and enthusiasts.
Comprehensive Search: Search across all EVE University Wiki articles with intelligent result ranking
Full Article Access: Retrieve complete article content with proper formatting
Article Summaries: Get concise summaries for quick information overview
Section Navigation: Browse article sections and structure
Link Discovery: Find related articles through internal wiki links
Related Topics: Discover related content based on article categories
Wayback Machine Fallback: Automatic fallback to Internet Archive when primary wiki is unavailable
Robust Error Handling: Graceful degradation with retry mechanisms
Rate Limiting: Built-in request throttling to respect server resources
Related MCP server: WebSearch-MCP
search_eve_wikiSearch for articles on EVE University Wiki
Parameters:
query (string): Search query
limit (number, 1-50, default: 10): Maximum results to return
Returns: Array of search results with titles, snippets, and metadata
get_eve_wiki_articleRetrieve full content of a specific wiki article
Parameters:
title (string): Article title
Returns: Complete article content
get_eve_wiki_summaryGet a concise summary of an article
Parameters:
title (string): Article title
Returns: Article summary/extract
get_eve_wiki_sectionsList all sections within an article
Parameters:
title (string): Article title
Returns: Array of sections with titles, levels, and indices
get_eve_wiki_linksGet all internal links from an article
Parameters:
title (string): Article title
Returns: Array of linked article titles
get_eve_wiki_related_topicsFind related articles based on categories
Parameters:
title (string): Article title
limit (number, 1-20, default: 10): Maximum related topics to return
Returns: Array of related article titles
EVE University Wiki Info: Basic information about the EVE University Wiki
eve-wiki-search-helper: Generates optimized search queries for EVE University Wiki based on user questions
To install eve-university-wiki-mcp-server for Claude Desktop automatically via Smithery:
npx -y @smithery/cli install @kongyo2/eve-university-wiki-mcp-server --client claudeNode.js 18+
npm or yarn
npm installStart the server in development mode with interactive CLI:
npm run devBuild and start the server:
npm run build
npm run startAdd to your Claude Desktop configuration:
{
"mcpServers": {
"eve-university-wiki": {
"command": "npx",
"args": ["tsx", "/path/to/eve-university-mcp/src/server.ts"],
"env": {}
}
}
}The server uses stdio transport and follows the MCP specification, making it compatible with any MCP client.
// Search for EVE Online ships
await callTool("search_eve_wiki", {
query: "Rifter frigate",
limit: 5
});
// Get detailed information about a specific ship
await callTool("get_eve_wiki_article", {
title: "Rifter"
});
// Get a quick summary
await callTool("get_eve_wiki_summary", {
title: "Rifter"
});
// Find related topics
await callTool("get_eve_wiki_related_topics", {
title: "Rifter",
limit: 10
});When the primary EVE University Wiki is unavailable, the server automatically attempts to retrieve content from the Internet Archive's Wayback Machine. This ensures continued access to EVE Online knowledge even during wiki downtime.
Archived content is clearly marked in responses with:
source: "wayback_machine" field
pageid: -1 to indicate archived content
Descriptive notes about the content source
Run the comprehensive test suite:
npm run testThe test suite covers:
All tool functionality
Error handling scenarios
Parameter validation
Response formatting
Wayback Machine fallback
npm run lint # Check code style
npm run format # Fix formatting issuesThis project uses:
TypeScript for type safety
ESLint for code quality
Prettier for consistent formatting
Vitest for testing
The server is built with:
FastMCP: High-performance MCP server framework
Axios: HTTP client with retry logic and timeout handling
Cheerio: HTML parsing for Wayback Machine content
Zod: Runtime type validation for parameters
Fork the repository
Create a feature branch
Make your changes with tests
Run npm run lint and npm run test
Submit a pull request
MIT License - see LICENSE file for details.
FastMCP - The MCP server framework used
Model Context Protocol - The protocol specification
EVE University Wiki - The knowledge source
Get the full content of an EVE University Wiki article (with Wayback Machine fallback)
| Name | Required | Description | Default |
|---|---|---|---|
| title | Yes | Title of the EVE University Wiki article |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations provide readOnlyHint=true and openWorldHint=true, indicating a safe read operation with potentially unknown outputs. The description adds valuable context beyond this by mentioning the 'Wayback Machine fallback', which implies resilience behavior not covered by annotations. It does not contradict annotations, as 'Get' aligns with read-only.
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 core purpose ('Get the full content') and includes essential context ('with Wayback Machine fallback') without unnecessary words. Every part earns its place, 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 low complexity (1 parameter, no output schema) and rich annotations (readOnlyHint, openWorldHint), the description is mostly complete. It covers the purpose and a key behavioral trait (fallback), but lacks details on output format or error handling, which could be useful despite the annotations.
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 'title' clearly documented in the schema. The description does not add any additional meaning or details about the parameter beyond what the schema provides, such as format examples or constraints, so it meets the baseline for 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 action ('Get the full content') and resource ('EVE University Wiki article'), distinguishing it from siblings like get_eve_wiki_summary (which likely provides a summary) and get_eve_wiki_sections (which might list sections). The mention of 'Wayback Machine fallback' adds unique scope, further differentiating it.
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 'full content' and 'Wayback Machine fallback', suggesting this tool is for retrieving complete articles, possibly when the main source is unavailable. However, it does not explicitly state when to use it versus alternatives like get_eve_wiki_summary or search_eve_wiki, leaving some ambiguity.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get the links contained within an EVE University Wiki article
| Name | Required | Description | Default |
|---|---|---|---|
| title | Yes | Title of the EVE University Wiki article |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations indicate readOnlyHint=true and openWorldHint=true, so the agent knows this is a safe, read-only operation with open-world semantics. The description adds context by specifying it retrieves 'links' from an article, which is useful beyond annotations, but doesn't detail behavioral traits like rate limits, error handling, or output format, keeping it at a baseline level.
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 directly states the tool's purpose without any unnecessary words. It is front-loaded and appropriately sized, making it easy for an agent to parse quickly.
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 (1 parameter, no output schema) and good annotations, the description is minimally complete. It covers the basic purpose but lacks details on output (e.g., link format or structure) and usage context relative to siblings, which could be helpful for an agent to operate effectively.
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 single parameter 'title' clearly documented in the schema. The description doesn't add any meaning beyond this, such as format examples or constraints, so it meets the baseline score of 3 where the schema handles parameter documentation adequately.
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 ('Get') and resource ('links contained within an EVE University Wiki article'), making the purpose specific and understandable. However, it doesn't explicitly differentiate from sibling tools like 'get_eve_wiki_article' or 'get_eve_wiki_sections', which might also involve article content, so it's not a perfect 5.
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 provides no guidance on when to use this tool versus alternatives such as 'get_eve_wiki_article' or 'get_eve_wiki_related_topics'. It lacks explicit context, exclusions, or named alternatives, leaving the agent to infer usage from tool names alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get the sections of an EVE University Wiki article
| Name | Required | Description | Default |
|---|---|---|---|
| title | Yes | Title of the EVE University Wiki article |
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 unknown data. The description adds value by specifying it retrieves 'sections' of articles, which clarifies the scope beyond what annotations cover, but it doesn't detail behavioral traits like rate limits, error handling, or output format.
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, clear sentence that directly states the tool's purpose without any unnecessary words. It is front-loaded and efficiently conveys the essential information, 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 has one parameter with full schema coverage and annotations covering safety and data scope, the description is adequate for a basic read operation. However, without an output schema, it doesn't explain return values or structure, and it lacks usage guidelines, leaving some gaps in context for optimal agent use.
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 'title' parameter fully documented in the schema. The description doesn't add any extra meaning or context about the parameter beyond what the schema provides, such as formatting examples or constraints, so it meets the baseline for 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 verb 'Get' and the resource 'sections of an EVE University Wiki article', which is specific and unambiguous. However, it doesn't explicitly differentiate from sibling tools like 'get_eve_wiki_article' or 'get_eve_wiki_summary', which might retrieve different aspects of wiki content, so it doesn't reach the highest score.
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 provides no guidance on when to use this tool versus alternatives such as 'get_eve_wiki_article' or 'get_eve_wiki_summary'. It lacks any context about use cases, exclusions, or prerequisites, leaving the agent to infer usage from the tool name alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get a summary of an EVE University Wiki article (with Wayback Machine fallback)
| Name | Required | Description | Default |
|---|---|---|---|
| title | Yes | Title of the EVE University Wiki article |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations provide readOnlyHint=true and openWorldHint=true, indicating safe read operations and potential unknown inputs. The description adds valuable context by mentioning the 'Wayback Machine fallback', which is not covered by annotations and informs about reliability and data retrieval behavior beyond basic hints.
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 core purpose and includes the fallback detail without unnecessary words. Every part of the sentence contributes directly to understanding the tool's function.
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) and lack of output schema, the description is reasonably complete. It covers the main action and fallback mechanism, though it could benefit from more detail on output format or error handling to be fully comprehensive.
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 input schema has 100% description coverage, with the 'title' parameter clearly documented. The description does not add any additional meaning or details about the parameter beyond what the schema provides, so it meets the baseline for high schema coverage without extra value.
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 action ('Get a summary') and resource ('EVE University Wiki article'), and distinguishes it from siblings by specifying the fallback mechanism ('with Wayback Machine fallback'). This is specific and differentiates it from tools like 'get_eve_wiki_article' or 'search_eve_wiki'.
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 for retrieving summaries rather than full articles or other data, but does not explicitly state when to use this tool versus alternatives like 'get_eve_wiki_article' or 'search_eve_wiki'. No exclusions or clear alternatives are named, leaving some ambiguity.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Search for articles on EVE University Wiki (with Wayback Machine fallback)
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | Maximum number of results to return | |
| query | Yes | Search query for EVE University Wiki |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already provide readOnlyHint=true and openWorldHint=true, indicating a safe read operation with open-world data. The description adds value by disclosing the 'Wayback Machine fallback' behavior, which is not covered by annotations. However, it lacks details on rate limits, error handling, or response format, leaving some behavioral traits unspecified.
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 core purpose ('Search for articles on EVE University Wiki') and adds a critical behavioral detail ('with Wayback Machine fallback') without any wasted words. It is appropriately sized and structured for clarity.
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 moderate complexity (search with fallback), rich annotations (readOnlyHint, openWorldHint), and 100% schema coverage, the description is mostly complete. It covers the purpose and a key behavioral trait. However, without an output schema, it does not explain return values or result structure, which is a minor gap.
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 clear descriptions for both parameters (query and limit). The description does not add any additional meaning beyond what the schema provides, such as search syntax or result ordering. Baseline 3 is appropriate since the schema adequately documents the 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 the specific action ('Search for articles') and target resource ('EVE University Wiki'), and distinguishes it from sibling tools by mentioning the unique 'Wayback Machine fallback' feature. It uses a precise verb ('Search') rather than being vague or tautological.
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 implicitly suggests using this tool for searching articles on the EVE University Wiki, which provides clear context. However, it does not explicitly state when to use this versus the sibling tools (e.g., get_eve_wiki_article for specific articles), nor does it mention exclusions or alternatives beyond the fallback.
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 targeting different aspects of wiki articles: retrieving full content, links, related topics, sections, summaries, or searching. No overlap exists between these functions, making tool selection straightforward for an agent.
All tools follow a consistent 'get_eve_wiki_X' or 'search_eve_wiki' pattern with snake_case, using descriptive nouns (article, links, topics, sections, summary, search) that clearly indicate their function. This uniformity enhances predictability and usability.
With 6 tools, this server is well-scoped for its purpose of interacting with the EVE University Wiki. Each tool serves a specific and necessary function, such as retrieving content, exploring structure, or searching, without being overly sparse or bloated.
The tool set provides comprehensive coverage for wiki interaction, including retrieval of full articles, summaries, sections, links, and related topics, plus search functionality. This covers typical agent workflows for information gathering and exploration without obvious gaps.
Unclaimed servers have limited discoverability.
If you are the server author, to access and configure the admin panel.
Official remote MCP server for Archivist AI TTRPG campaign memory: characters, sessions, and more.
A comprehensive Model Context Protocol (MCP) server that enables AI assistants to interact with yo…
Hosted MCP server for live public-data APIs and Skills for AI agents.
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/kongyo2/EVE-University-Wiki-MCP-Server'
If you have feedback or need assistance with the MCP directory API, please join our Discord server
