EVE Tycoon MCP Server

Server Quality Checklist

Profile completionA complete profile improves this server's visibility in search results.

Latest release: v1.0.0
Disambiguation5/5
Every tool has a clearly distinct purpose with no ambiguity: get_market_groups lists groups, get_market_group_types lists types within a group, get_market_history provides price history, get_market_orders shows current orders, get_market_stats gives price/volume stats, and get_regions lists regions. The descriptions make it easy to tell them apart, as each targets a specific market data aspect.
Naming Consistency5/5
All tool names follow a consistent verb_noun pattern with 'get_' prefix and snake_case, such as get_market_groups, get_market_history, and get_regions. This predictable naming scheme enhances readability and makes the tool set easy to navigate without any deviations or mixed conventions.
Tool Count5/5
With 6 tools, the server is well-scoped for its market data domain in EVE Tycoon. Each tool earns its place by covering essential functions like listing groups, types, history, orders, stats, and regions, providing a focused and manageable set without being too thin or overloaded.
Completeness4/5
The tool surface is nearly complete for market data retrieval, covering key operations such as listing groups, types, regions, and detailed market info. A minor gap exists in lacking update or manipulation tools (e.g., place_orders), but agents can work around this for read-only analysis, as the core workflows are well-covered.
Average 3.4/5 across 6 of 6 tools scored.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 0 commits in the last 12 weeks
- No stable releases found
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI is passing
This repository is licensed under MIT License.
This repository includes a README.md file.
No tool usage detected in the last 30 days. Usage tracking helps demonstrate server value.
Tip: use the "Try in Browser" feature on the server page to seed initial usage.
Add a glama.json file to provide metadata about your server.
If you are the author, simply .
If the server belongs to an organization, first add glama.json to the root of your repository:
```
{
  "$schema": "https://glama.ai/mcp/schemas/server.json",
  "maintainers": [
    "your-github-username"
  ]
}
```
Then . Browse examples.
Add related servers to improve discoverability.

How to sync the server with GitHub?

Servers are automatically synced at least once per day, but you can also sync manually at any time to instantly update the server profile.

To manually sync the server, click the "Sync Server" button in the MCP server admin interface.

How is the quality score calculated?

The overall quality score combines two components: Tool Definition Quality (70%) and Server Coherence (30%).

Tool Definition Quality measures how well each tool describes itself to AI agents. Every tool is scored 1–5 across six dimensions: Purpose Clarity (25%), Usage Guidelines (20%), Behavioral Transparency (20%), Parameter Semantics (15%), Conciseness & Structure (10%), and Contextual Completeness (10%). The server-level definition quality score is calculated as 60% mean TDQS + 40% minimum TDQS, so a single poorly described tool pulls the score down.

Server Coherence evaluates how well the tools work together as a set, scoring four dimensions equally: Disambiguation (can agents tell tools apart?), Naming Consistency, Tool Count Appropriateness, and Completeness (are there gaps in the tool surface?).

Tiers are derived from the overall score: A (≥3.5), B (≥3.0), C (≥2.0), D (≥1.0), F (<1.0). B and above is considered passing.

Tool Scores

Behavior3/5
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 large data sets. The description adds value by specifying it returns 'current order book' and 'metadata about the type and locations,' which clarifies the scope beyond annotations. However, it lacks details on rate limits, pagination, or data freshness, which would enhance behavioral understanding. No contradiction with annotations is present.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence that front-loads the core purpose. It avoids redundancy and waste, making it easy to parse. However, it could be slightly more structured by explicitly separating the main function from filtering details, but overall it is concise and well-formed.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's moderate complexity (4 parameters, no output schema), the description is adequate but incomplete. It covers what the tool does and filtering options, but lacks details on output format, error handling, or usage examples. With annotations providing safety hints, it meets minimum viability, but could be more comprehensive to fully guide an agent in invocation and interpretation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, with clear descriptions for all four parameters (typeId, regionId, systemId, locationId). The description adds minimal semantics by implying these are used for filtering ('to filter on'), but does not provide additional context like format examples or interdependencies. Since the schema already documents parameters well, the baseline score of 3 is appropriate as the description adds little extra value.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'Returns the current order book for an item type, with metadata about the type and locations.' It specifies the verb ('Returns') and resource ('current order book for an item type'), making the function understandable. However, it does not explicitly differentiate from sibling tools like 'get_market_history' or 'get_market_stats', which likely provide different market data, so it misses full sibling distinction.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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. It mentions filtering by region, system, or location but does not specify when to choose this over siblings like 'get_market_history' (for historical data) or 'get_market_stats' (for statistical summaries). Without such context, users may struggle to select the appropriate tool for their needs.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
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 potential for incomplete data. The description adds minimal behavioral context beyond this, as it doesn't specify return format, pagination, or error handling. No contradiction with annotations exists, but the description doesn't enrich the behavioral profile significantly.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, direct sentence with zero waste, efficiently conveying the core purpose without unnecessary details. It's appropriately sized and front-loaded for clarity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
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 annotations covering safety, the description is minimally adequate. However, it lacks details on return values or error cases, which could be helpful for an agent despite the annotations. It meets basic needs but leaves gaps in full context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, with the single parameter 'groupId' documented as 'Market group ID'. The description doesn't add meaning beyond this, such as explaining what a market group is or valid ID ranges. Baseline 3 is appropriate since the schema handles parameter documentation adequately.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Returns') and target resource ('list of types in a market group'), making the purpose understandable. However, it doesn't explicitly differentiate from sibling tools like 'get_market_groups' or 'get_market_stats', which might also return related market data, so it misses full sibling distinction.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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. With siblings like 'get_market_groups' and 'get_market_stats', there's no indication of context, exclusions, or comparative use cases, leaving the agent to infer usage.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and openWorldHint=true, indicating this is a safe read operation with potentially open-ended data. The description adds the specific behavioral context of returning 'price history', which implies time-series data, but doesn't disclose details like date ranges, pagination, or rate limits. With annotations covering core traits, this adds some value but not rich behavioral context.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence that front-loads the core purpose without any wasted words. It's appropriately sized for a simple tool with good annotations and schema coverage.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's moderate complexity (2 required parameters, no output schema), the description is minimally adequate. It covers the basic purpose but lacks usage guidelines and detailed behavioral context. With annotations providing safety and openness hints, it's complete enough for basic use but could be improved with more context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, with both parameters (regionId and typeId) documented in the schema. The description implies these parameters are used to specify the item and region for price history, but doesn't add syntax or format details beyond what the schema provides. Baseline 3 is appropriate when the schema does the heavy lifting.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'returns' and the resource 'price history of an item in a particular region', making the purpose specific and understandable. However, it doesn't explicitly differentiate from sibling tools like get_market_stats or get_market_orders, which might also provide market-related data.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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. It doesn't mention when to choose this over siblings like get_market_stats (which might provide aggregated statistics) or get_market_orders (which might show current orders), leaving the agent without contextual usage cues.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations indicate readOnlyHint=true and openWorldHint=true, which the description doesn't contradict. The description adds value by specifying the type of data returned ('price and volume stats'), but it doesn't disclose additional behavioral traits like rate limits, authentication needs, or data freshness, which could be useful context beyond the annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence that front-loads the key action and resource without any wasted words. It's appropriately sized for a simple data retrieval tool, 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.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's moderate complexity (4 parameters, no output schema) and rich annotations, the description is adequate but incomplete. It covers the basic purpose but lacks details on output format, error handling, or usage scenarios, which could help the agent invoke it more effectively in context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema fully documents all parameters. The description adds minimal semantic context by implying that 'regionId' and 'typeId' are required for the core query, but it doesn't provide extra details beyond what the schema already specifies, such as how 'systemId' or 'locationId' refine the results.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb ('Returns') and resource ('price and volume stats for an item type in a specific region'), making the purpose immediately understandable. However, it doesn't explicitly differentiate from sibling tools like 'get_market_history' or 'get_market_orders', which might also return market-related data, 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.
Usage Guidelines2/5
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. It doesn't mention sibling tools or contexts where other tools might be more appropriate, such as using 'get_market_history' for historical data or 'get_market_orders' for order details, leaving the agent with minimal usage direction.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
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 incomplete data. The description adds no behavioral context beyond this, such as rate limits, authentication needs, or data freshness. It doesn't contradict annotations, but adds minimal value beyond them.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence with zero waste. It's front-loaded with the core action and resource, making it immediately clear. Every word earns its place, and there's no redundancy or unnecessary elaboration.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple read-only tool with no parameters and good annotations, the description is adequate but minimal. It lacks output details (no schema provided), doesn't explain data format or scope limitations, and misses sibling differentiation. It's complete enough for basic use but leaves gaps in contextual understanding.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has 0 parameters with 100% schema description coverage, so the schema fully documents the absence of inputs. The description doesn't need to explain parameters, and it correctly implies no filtering or options are available. This meets expectations for a parameterless tool.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb ('Returns') and resource ('list of all market groups'), making the purpose immediately understandable. However, it doesn't differentiate from sibling tools like 'get_market_group_types' or 'get_market_stats', which likely return different market-related data. The description is specific but lacks sibling distinction.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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. With siblings like 'get_market_group_types' and 'get_market_stats', there's no indication of what distinguishes this tool's scope or when it's appropriate. The description only states what it does, not when to choose it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and openWorldHint=true, indicating safe read operations with potentially incomplete data. The description adds value by specifying 'all regions' scope, which provides useful context beyond annotations. No contradiction with annotations exists.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence with zero waste. It's appropriately sized for a simple tool with no parameters and gets straight to the point without unnecessary elaboration.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple read-only tool with no parameters and good annotations, the description is adequate but minimal. It doesn't explain return format, data structure, or potential limitations despite no output schema. The completeness is acceptable but not comprehensive.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0 parameters and 100% schema coverage, the baseline is 4. The description appropriately doesn't discuss parameters since none exist, and it correctly indicates this is a simple retrieval operation without input requirements.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose with a specific verb ('Returns') and resource ('list of all regions'). It distinguishes from siblings by focusing on regions rather than market-related data. However, it doesn't explicitly differentiate from potential non-sibling region tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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. It doesn't mention sibling tools, prerequisites, or specific contexts where retrieving regions is appropriate versus other market data tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

GitHub Badge

Glama performs regular codebase and documentation scans to:

Confirm that the MCP server is working as expected.
Confirm that there are no obvious security issues.
Evaluate tool definition quality.

Our badge communicates server capabilities, safety, and installation instructions.

Card Badge

Copy to your README.md:

[![evetycoon-mcp-server MCP server](https://glama.ai/mcp/servers/kongyo2/evetycoon-mcp-server/badges/card.svg)](https://glama.ai/mcp/servers/kongyo2/evetycoon-mcp-server)

Score Badge

Copy to your README.md:

[![evetycoon-mcp-server MCP server](https://glama.ai/mcp/servers/kongyo2/evetycoon-mcp-server/badges/score.svg)](https://glama.ai/mcp/servers/kongyo2/evetycoon-mcp-server)

Latest Blog Posts

Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)
By Om-Shree-0709 on July 25, 2026.
mcp
Agent Identity
OAuth 2.1
Your AI Chatbot Just Exposed Your CEO's Salary to an Intern
By Om-Shree-0709 on July 2, 2026.
Agent Identity
MCP Security
OAuth Delegation
Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)
By Om-Shree-0709 on June 30, 2026.
Agentic Ai
Prompt Injection
WebAssembly

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/kongyo2/evetycoon-mcp-server'

If you have feedback or need assistance with the MCP directory API, please join our Discord server