eve-online-mcp

Server Quality Checklist

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

Latest release: v1.0.0
Disambiguation4/5
Most tools have distinct purposes, with clear separation between authentication (authenticate, get-auth-url, refresh-token) and market data retrieval functions. However, get-market-orders and get-structure-orders could potentially be confused as they both retrieve market orders, differing only by location (region vs. structure), which might cause misselection if the agent doesn't carefully parse the descriptions.
Naming Consistency5/5
All tools follow a consistent verb_noun pattern with clear, descriptive names. The naming convention is uniform throughout, using lowercase with hyphens, and verbs like 'get', 'authenticate', and 'refresh' are applied predictably across related functions.
Tool Count5/5
With 10 tools, the count is well-scoped for the server's purpose of handling EVE Online authentication and market data. Each tool serves a specific function, such as authentication flow management and various market queries, making the set comprehensive without being overwhelming.
Completeness4/5
The tool surface is nearly complete for the domain of EVE Online market data and authentication, covering authentication lifecycle (get URL, authenticate, refresh) and diverse market queries (groups, history, orders, prices, stats). A minor gap exists in the lack of tools for placing or managing market orders, which could limit full market interaction, but core retrieval and authentication are well-covered.
Average 2.9/5 across 10 of 10 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

Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It states the action ('Get') but doesn't describe whether this is a read-only operation, requires authentication, has rate limits, returns paginated data, or what the output format might be. This leaves significant gaps for a tool that likely queries market data.
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 and front-loaded with the core purpose, making it easy to parse quickly.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity of market data tools, no annotations, and no output schema, the description is incomplete. It doesn't explain what 'market statistics' includes, how results are structured, or behavioral traits like authentication needs. This leaves the agent under-informed for effective use.
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?
The schema description coverage is 100%, with the parameter 'region_id' documented as 'Region ID to get statistics from'. The description adds no additional meaning beyond this, such as examples of valid region IDs or how they relate to market data. Baseline 3 is appropriate since the schema does the heavy lifting.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Get market statistics for a region' clearly states the verb ('Get') and resource ('market statistics'), but it's vague about what 'market statistics' entails compared to siblings like get-market-prices or get-market-history. It doesn't specify what type of statistics (e.g., aggregates, trends, summaries) are returned, leaving ambiguity.
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?
No guidance is provided on when to use this tool versus alternatives like get-market-prices or get-market-history. The description doesn't mention prerequisites (e.g., authentication), exclusions, or contextual cues, leaving the agent to infer usage based on tool names alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It mentions the exchange action but fails to describe critical behaviors such as authentication requirements, rate limits, error handling, or the format of the returned access token. For a security-sensitive tool, this lack of detail is a significant gap.
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 that efficiently conveys the core functionality without any extraneous words. It is front-loaded with the essential action and resources, making it highly concise and well-structured for quick comprehension.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity of an authentication tool with no annotations and no output schema, the description is insufficient. It lacks details on security implications, token lifecycle, error responses, and integration with sibling tools like 'refresh-token', leaving critical context gaps for safe and effective use.
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?
The schema description coverage is 100%, with the single parameter 'code' clearly documented as 'Authorization code from EVE Online SSO'. The description adds no additional semantic information beyond what the schema provides, such as format details or validation rules, so it meets the baseline for adequate but not enhanced coverage.
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 ('Exchange') and the specific resources involved ('authorization code for access token'), making the purpose immediately understandable. However, it doesn't explicitly differentiate this tool from its sibling 'refresh-token', which also deals with token management, leaving some ambiguity about when to use each.
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 like 'refresh-token' or 'get-auth-url', nor does it mention any prerequisites or context for invocation. It merely states what the tool does without indicating the appropriate scenarios for its use.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It states the tool retrieves an authentication URL but doesn't describe what the URL is used for (e.g., redirecting users), whether it's safe to call repeatedly, or any side effects. This leaves gaps in understanding the tool's behavior beyond its basic purpose.
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, clear sentence with no wasted words. It's appropriately sized for a simple tool and front-loads the essential information. Every part of the sentence contributes directly to understanding the tool's purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity of authentication tools and the lack of annotations and output schema, the description is insufficient. It doesn't explain what the returned URL is used for, how it fits into the OAuth2 flow, or what happens after obtaining it. For a tool with no structured behavioral data, more context is needed to guide effective use.
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?
The input schema has 100% description coverage, with the 'state' parameter documented as 'State parameter for OAuth2 flow.' The description adds no additional parameter information beyond what the schema provides. According to scoring rules, when schema coverage is high (>80%), the baseline is 3 even with no param info in the description.
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: 'Get the authentication URL for EVE Online SSO.' It specifies the verb ('Get') and resource ('authentication URL'), and identifies the target system ('EVE Online SSO'). However, it doesn't explicitly differentiate from sibling tools like 'authenticate' or 'refresh-token', which might handle different aspects of authentication flow.
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 prerequisites, context (e.g., initiating OAuth2 flow), or exclusions. Sibling tools like 'authenticate' and 'refresh-token' suggest related authentication functions, but the description offers no comparison or usage scenarios.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It states the tool retrieves data ('Get'), implying a read-only operation, but doesn't cover aspects like rate limits, authentication needs, error handling, or return format. This leaves significant gaps for a tool with no annotation support.
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 no wasted words, clearly front-loading the core purpose. It's appropriately sized for a simple 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.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the lack of annotations and output schema, the description is incomplete. It doesn't explain what 'grouped market data' entails, how results are structured, or any behavioral traits like pagination or errors. For a data retrieval tool with no structured support, more context is needed to guide the agent effectively.
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?
The description mentions 'region and type', aligning with the parameters 'region_id' and 'type_id' from the schema. Since schema description coverage is 100%, the schema already documents these parameters well, so the description adds minimal value beyond restating them, meeting the baseline for high coverage.
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 ('Get') and resource ('grouped market data') with specific scoping parameters ('for a region and type'), making the purpose understandable. However, it doesn't differentiate from sibling tools like 'get-market-history' or 'get-market-prices', which prevents a perfect 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?
No guidance is provided on when to use this tool versus alternatives like 'get-market-history' or 'get-market-prices'. The description implies usage for grouped data but doesn't specify scenarios, prerequisites, or exclusions, leaving the agent to infer context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It states it 'gets' data (implying read-only), but doesn't disclose behavioral traits like rate limits, authentication requirements (though sibling 'authenticate' suggests auth needed), data freshness, or pagination. The description is minimal and lacks context about what 'market history' entails (e.g., time range, format).
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 purpose and appropriately sized for a simple tool. Every word earns its place by specifying 'market history', 'specific item', and 'region'.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no annotations, no output schema, and 2 parameters with full schema coverage, the description is incomplete. It doesn't explain what 'market history' returns (e.g., price history, volume trends), time ranges, or how it relates to authentication (implied by sibling tools). For a data retrieval tool in a market context, more behavioral context is needed.
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 clearly documented in the schema. The description adds no additional meaning beyond implying 'region_id' and 'type_id' are required for specificity. It doesn't explain parameter relationships or provide examples, so it meets the baseline of 3 where 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 'Get' and the resource 'market history', specifying it's for 'a specific item in a region'. It distinguishes from siblings like 'get-market-prices' or 'get-market-orders' by focusing on historical data rather than current prices or orders. However, it doesn't explicitly differentiate from 'get-market-stats' which might also involve historical analysis.
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 like 'get-market-prices' or 'get-market-stats'. It mentions 'market history' but doesn't clarify if this is for trend analysis, price tracking, or other purposes. There are no explicit when/when-not instructions or prerequisites mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It states the tool retrieves data ('Get'), implying a read-only operation, but doesn't cover critical aspects like authentication requirements, rate limits, pagination, error handling, or response format. This is a significant gap for a tool with potential complexity in a market data 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 unnecessary words. Every part ('Get market orders from a specific region') contributes directly to understanding the tool's function, making it appropriately concise and well-structured.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the lack of annotations and output schema, the description is incomplete for a tool with 3 parameters in a market data context. It doesn't address behavioral traits (e.g., auth needs, data freshness), usage guidelines, or output details, leaving significant gaps that could hinder an agent's ability to use the tool effectively.
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?
The description mentions 'from a specific region', which aligns with the required 'region_id' parameter, but adds no meaning beyond what the schema provides. With 100% schema description coverage, the baseline is 3, as the schema already documents all parameters well (e.g., 'order_type' with enum values, 'type_id' for filtering). The description doesn't compensate with additional context like parameter interactions or examples.
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 ('Get') and resource ('market orders') with a specific scope ('from a specific region'), which provides a clear purpose. However, it doesn't differentiate from siblings like 'get-market-history' or 'get-market-prices' beyond mentioning 'orders', leaving some ambiguity about how this tool uniquely fits among market-related 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 like 'get-market-history' or 'get-structure-orders'. It mentions a region scope but doesn't explain prerequisites (e.g., authentication) or exclusions, leaving the agent to infer usage from context alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It states the action but fails to describe key traits such as whether this is a read-only operation, potential rate limits, authentication requirements, or the format of returned data (e.g., pagination details). This leaves significant gaps for a tool that likely interacts with market data.
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 directly states the tool's purpose without unnecessary words. It is appropriately sized and front-loaded, 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.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the lack of annotations and output schema, the description is incomplete. It does not address behavioral aspects like safety, authentication, or data format, which are crucial for a tool fetching market orders. The high schema coverage helps with parameters, but overall context is insufficient for effective tool selection and invocation.
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?
The input schema has 100% description coverage, clearly documenting both parameters ('structure_id' and 'page'). The description adds no additional meaning beyond implying the scope ('in a structure'), which is already covered by the schema. This meets the baseline of 3 for high schema coverage.
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 ('Get') and resource ('all market orders in a structure'), making the purpose specific and understandable. However, it does not explicitly differentiate from sibling tools like 'get-market-orders' or 'get-structure-type-orders', which might have overlapping functionality, preventing a score of 5.
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 such as 'get-market-orders' or 'get-structure-type-orders'. It lacks context about prerequisites (e.g., authentication) or exclusions, leaving the agent to infer usage based on tool names alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden for behavioral disclosure. It mentions 'Get all market orders' but doesn't clarify whether this is a read-only operation, if it requires authentication, what pagination behavior exists (implied by 'page' parameter but not explained), or rate limits. The description is minimal and lacks essential operational 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 directly states the tool's purpose without any fluff. It's appropriately sized for a simple retrieval tool and front-loads the core functionality.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with 3 parameters, no annotations, and no output schema, the description is insufficient. It doesn't explain what 'market orders' means in this context, what format the results take, how pagination works, or authentication requirements. The description alone leaves significant gaps for an agent to understand how to properly use this tool.
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 all parameters are documented in the schema. The description adds no additional meaning about parameters beyond implying that 'structure_id' and 'type_id' are required (which is already in the schema's required array). It doesn't explain relationships between parameters or provide usage examples.
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 ('Get all market orders') and the target ('for a specific type in a structure'), which is a specific verb+resource combination. It distinguishes itself from sibling tools like 'get-structure-orders' by specifying 'type' filtering, but doesn't explicitly contrast with 'get-market-orders' which might be broader in scope.
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 like 'get-structure-orders' (which presumably gets all orders in a structure) or 'get-market-orders' (which might be global). It states what it does but offers no context about prerequisites, exclusions, or comparative use cases.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It states the tool's function but lacks critical details: it doesn't mention whether this is a read-only operation, potential rate limits, authentication requirements (though sibling tools suggest an auth system), or what the output format looks like. This leaves significant gaps for an agent to use it effectively.
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 directly states the tool's function without any fluff. It's front-loaded with the core action and resource, making it easy to parse quickly. Every word earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the lack of annotations and output schema, the description is insufficiently complete. It doesn't address behavioral aspects like authentication needs (implied by sibling tools), rate limits, or output format. For a tool that likely interacts with an external API (EVE Online), more context is needed for reliable agent use.
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 input schema has 0 parameters with 100% coverage, so no parameter documentation is needed. The description appropriately doesn't discuss parameters, focusing instead on the tool's purpose. This aligns with the baseline expectation 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 action ('Get market prices') and resource ('all items in EVE Online'), making the purpose immediately understandable. It doesn't explicitly differentiate from siblings like 'get-market-history' or 'get-market-orders', but the scope ('all items') provides some implicit 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?
No guidance is provided on when to use this tool versus alternatives like 'get-market-history' or 'get-market-orders'. The description implies it retrieves current prices for all items, but it doesn't specify use cases, prerequisites, or exclusions, 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.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden for behavioral disclosure. While it indicates this refreshes tokens, it doesn't describe what happens after refresh (e.g., returns new access token, updates session), whether it has rate limits, or what errors might occur. This is a significant gap for a security-related tool.
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 wasted words. It's appropriately sized and front-loaded with the essential information about what the tool does.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity of token refresh operations and the absence of both annotations and output schema, the description is incomplete. It doesn't explain what the tool returns (new access token, expiration time), error conditions, or security implications, leaving critical gaps for agent understanding.
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 'refresh_token' well-documented in the schema. The description doesn't add any meaningful parameter semantics beyond what the schema already provides, 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.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('refresh') and the resource ('an expired access token'), providing a specific verb+resource combination. However, it doesn't distinguish this tool from its sibling 'authenticate' tool, which likely handles initial authentication rather than token renewal.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage context through 'expired access token,' suggesting this should be used when tokens expire. However, it doesn't provide explicit guidance on when to use this versus the 'authenticate' sibling tool or mention any prerequisites or alternatives.
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:

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

Score Badge

Copy to your README.md:

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

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/eve-online-mcp'

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