Skip to main content
Glama
kongyo2

eve-online-mcp

by kongyo2
OverviewSchemaSourceRelated ServersScoreDiscussionsAdmin
TypeScript
Remote

EVE Online Market MCP Server

Ask DeepWiki

このMCPサーバーは、EVE Onlineのマーケットデータにアクセスするためのインターフェースを提供します。ESI（EVE Swagger Interface）APIを使用して、リアルタイムの市場データを取得できます。

認証とレート制限

このサーバーは現在、パブリックなマーケットデータのみを取得するため、ESI認証は必要ありません。ただし、以下の制限と仕様があります：

  1. レート制限

    • ESIには1分あたりのエラー制限があります

    • サーバーは自動的にレート制限を監視し、制限に達した場合はエラーを返します

    • ヘッダーx-esi-error-limit-remainとx-esi-error-limit-resetで制限状態を確認できます

  2. ユーザーエージェント

    • ESIの推奨事項に従い、適切なユーザーエージェントを設定しています

    • 形式: eve-online-mcp/1.0 (github.com/your-username/eve-online-mcp)

  3. エラーハンドリング

    • APIエラーは適切にキャプチャされ、わかりやすいメッセージとして返されます

    • ESIからのエラー詳細情報も含まれます

Related MCP server: EVE Tycoon MCP Server

機能

サーバーは以下の3つの主要な機能を提供します：

  1. 市場価格の取得 (get-market-prices)

    • EVE Online内のすべてのアイテムの調整価格と平均価格を取得

    • 返り値には type_id、adjusted_price、average_price が含まれます

  2. 市場注文の取得 (get-market-orders)

    • 特定のリージョンの市場注文を取得

    • オプションで特定のアイテムタイプやオーダータイプ（買い/売り）でフィルタリング可能

    • 各注文には価格、数量、場所などの情報が含まれます

  3. 市場履歴の取得 (get-market-history)

    • 特定のリージョンの特定のアイテムの市場履歴を取得

    • 日ごとの最高価格、最低価格、平均価格、取引量などを取得可能

  4. グループ化された市場データの取得 (get-market-groups)

    • 特定のリージョンと特定のアイテムタイプのグループ化された市場データを取得

    • 買い注文と売り注文それぞれの統計情報（平均価格、最高/最低価格、取引量など）を提供

  5. 構造体の市場注文取得 (get-structure-orders)

    • 特定の構造体（ステーション、シタデルなど）の全市場注文を取得

    • ページネーション対応で大量のデータを効率的に取得可能

  6. 地域の取引所統計取得 (get-market-stats)

    • 特定の地域の市場統計情報を取得

    • 取引量、価格トレンド、市場活性度などの指標を提供

  7. 構造体の特定アイテム注文取得 (get-structure-type-orders)

    • 特定の構造体における特定のアイテムタイプの全市場注文を取得

    • より詳細な市場分析が可能

セットアップ

Installing via Smithery

To install eve-online-mcp for Claude Desktop automatically via Smithery:

npx -y @smithery/cli install @kongyo2/eve-online-mcp --client claude

  1. 依存パッケージのインストール：

    npm install

  2. プロジェクトのビルド：

    npm run build

  3. サーバーの起動：

    npm start

VS Code統合

このプロジェクトはVS Code用の設定が含まれています：

  • .vscode/settings.json: MCPサーバーの設定

  • .vscode/tasks.json: ビルドと実行用のタスク

以下のタスクが利用可能です：

  • "Build EVE Online Market MCP Server": プロジェクトをビルド

  • "Run EVE Online Market MCP Server": MCPサーバーを起動

使用例

  1. 市場価格の取得：

// すべてのアイテムの価格を取得
const prices = await callTool("get-market-prices");

  1. 市場注文の取得：

// The Forge（リージョンID: 10000002）のTritanium（タイプID: 34）の注文を取得
const orders = await callTool("get-market-orders", {
  region_id: 10000002,
  type_id: 34,
  order_type: "all"
});

  1. 市場履歴の取得：

// The ForgeのTritaniumの市場履歴を取得
const history = await callTool("get-market-history", {
  region_id: 10000002,
  type_id: 34
});

  1. グループ化された市場データの取得：

// The ForgeのTritaniumのグループ化された市場データを取得
const marketGroups = await callTool("get-market-groups", {
  region_id: 10000002,
  type_id: 34
});

  1. 構造体の市場注文取得：

// 構造体ID: 1234567890 の全市場注文を取得
const structureOrders = await callTool("get-structure-orders", {
  structure_id: 1234567890,
  page: 1
});

  1. 地域の取引所統計取得：

// The Forgeの市場統計情報を取得
const marketStats = await callTool("get-market-stats", {
  region_id: 10000002
});

  1. 構造体の特定アイテム注文取得：

// 構造体ID: 1234567890 におけるTritaniumの全市場注文を取得
const typeOrders = await callTool("get-structure-type-orders", {
  structure_id: 1234567890,
  type_id: 34,
  page: 1
});

認証設定

EVE Online SSO設定

  1. EVE Online Developers Portalでアプリケーションを登録

  2. 以下のスコープを要求:

    • esi-markets.structure_markets.v1

    • esi-markets.read_character_orders.v1

  3. 取得したクライアントIDとシークレットを.envファイルに設定:

    cp .env.example .env
# .envファイルを編集して認証情報を設定

認証フロー

  1. 認証URLの取得:

const authUrlResponse = await callTool("get-auth-url", {
  state: "unique-state-string"
});
// ユーザーをauthUrlResponseのURLにリダイレクト

  1. 認証コードの交換:

const authResponse = await callTool("authenticate", {
  code: "authorization-code-from-callback"
});
// 返されたトークンを保存

  1. トークンの更新:

const refreshResponse = await callTool("refresh-token", {
  refresh_token: "saved-refresh-token"
});
// 新しいトークンで更新

構造体アクセス

認証が必要な構造体のマーケットデータにアクセスする場合：

  1. 適切なスコープを持つトークンを取得

  2. makeESIRequestの呼び出し時にトークンを指定:

const structureOrders = await callTool("get-structure-orders", {
  structure_id: 1234567890,
  page: 1,
  token: "your-access-token"
});

注意事項

  1. 構造体関連のエンドポイント

    • 構造体関連のエンドポイントにアクセスするには、適切な権限を持つESIトークンが必要です

    • アクセス権のない構造体のデータは取得できません

  2. ページネーション

    • 大量のデータを返すエンドポイントはページネーションを使用します

    • pageパラメータで特定のページを指定できます（1から開始）

  3. キャッシュ

    • ESIのレスポンスはサーバー側でキャッシュされます

    • キャッシュ期間はエンドポイントによって異なります

    • キャッシュ情報はレスポンスヘッダーで確認できます

Available Tools

10 tools
authenticateC

Exchange authorization code for access token

ParametersJSON Schema
NameRequiredDescriptionDefault
codeYesAuthorization code from EVE Online SSO

TDQS

C2.9/5.0
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.

get-auth-urlC

Get the authentication URL for EVE Online SSO

ParametersJSON Schema
NameRequiredDescriptionDefault
stateYesState parameter for OAuth2 flow

TDQS

C2.9/5.0
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.

get-market-groupsC

Get grouped market data for a region and type

ParametersJSON Schema
NameRequiredDescriptionDefault
region_idYesRegion ID to get market groups from
type_idYesItem type ID to get groups for

TDQS

C2.9/5.0
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.

get-market-historyC

Get market history for a specific item in a region

ParametersJSON Schema
NameRequiredDescriptionDefault
region_idYesRegion ID to get market history from
type_idYesItem type ID to get history for

TDQS

C2.9/5.0
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.

get-market-ordersC

Get market orders from a specific region

ParametersJSON Schema
NameRequiredDescriptionDefault
order_typeNoType of orders to retrieveall
region_idYesRegion ID to get market orders from
type_idNoItem type ID to filter orders

TDQS

C2.9/5.0
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.

get-market-pricesB

Get market prices for all items in EVE Online

ParametersJSON Schema
NameRequiredDescriptionDefault

No parameters

TDQS

B3.1/5.0
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.

get-market-statsC

Get market statistics for a region

ParametersJSON Schema
NameRequiredDescriptionDefault
region_idYesRegion ID to get statistics from

TDQS

C2.7/5.0
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.

get-structure-ordersC

Get all market orders in a structure

ParametersJSON Schema
NameRequiredDescriptionDefault
pageNoWhich page to query, starts at 1
structure_idYesStructure ID to get market orders from

TDQS

C2.9/5.0
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.

get-structure-type-ordersC

Get all market orders for a specific type in a structure

ParametersJSON Schema
NameRequiredDescriptionDefault
pageNoWhich page to query, starts at 1
structure_idYesStructure ID to get market orders from
type_idYesItem type ID to get orders for

TDQS

C2.9/5.0
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.

refresh-tokenB

Refresh an expired access token

ParametersJSON Schema
NameRequiredDescriptionDefault
refresh_tokenYesRefresh token from previous authentication

TDQS

B3.2/5.0
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.

Tool Schema Changelog

Recent tool additions, removals, and schema changes observed during successful MCP inspections. Dates show when Glama detected each change.

  1. 10 tool updatesv1.0.0
    • First observedauthenticate
    • First observedget-auth-url
    • First observedget-market-groups
    • First observedget-market-history
    • First observedget-market-orders
    • First observedget-market-prices
    • First observedget-market-stats
    • First observedget-structure-orders
    • First observedget-structure-type-orders
    • First observedrefresh-token
Install Server
RayrunBuild, deploy, and operate MCP servers without becoming an infrastructure team.ray.runAd

TDQS

B3.3/5.0

Scored across 10 tools

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.

Maintenance

ActivityInactive
ResponsivenessNo issues

Resources

Unclaimed servers have limited discoverability.

Looking for Admin?

If you are the server author, to access and configure the admin panel.

Related MCP Connectors

Related MCP Servers

  • EVE Tycoon MCP Server

    kongyo2
    A
    license
    A
    quality
    D
    maintenance
    This MCP server allows you to interact with the EVE Tycoon API to retrieve market data, price statistics, order books, and historical pricing information for EVE Online items across different regions.
    6
    4
    MIT

  • EVE ESI Tool

    Berman510
    A
    license
    Not graded
    quality
    D
    maintenance
    An MCP server that integrates EVE Online's ESI API with AI assistants to enable natural language interaction with character data, market information, and assets. It provides 22 tools for managing skills, wallet balances, ship fittings, and more directly through AI-powered clients.
    2
    MIT

Appeared in Searches

Latest Blog Posts

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