Skip to main content
Glama
enesjakozh
NaveenBandarage

Poke-MCP

by NaveenBandarage
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Remote

鍛冶屋のバッジ

概要

Poke-MCPは、標準化されたインターフェースを通じてポケモンの情報を提供するモデルコンテキストプロトコル（MCP）サーバーです。PokeAPIに接続してポケモンデータを取得し、Claude Desktop App、Continue、ClineなどのMCP対応クライアントで使用できるMCPツールを通じて公開します。

Related MCP server: PokeMCP

特徴

  • 名前で特定のポケモンの情報を取得する

  • ランダムなポケモンを発見

  • 特定の地域（カントー、ジョウト、ホウエンなど）からランダムにポケモンを探します

  • 特定のタイプ（火、水、電気など）のポケモンをランダムに入手します。

  • ポケモン情報の自然言語クエリインターフェース

仕組み

Poke-MCPは、AIアプリケーションが標準化された方法で外部ツールやデータソースにアクセスできるようにするモデルコンテキストプロトコル（Model Context Protocol）を使用して構築されています。サーバーは次のことを行います。

  1. PokeAPIに接続してポケモンデータを取得します

  2. MCPインターフェースを通じていくつかのツールを公開します

  3. MCPクライアントからのリクエストを処理する

  4. フォーマットされたポケモン情報を返します

MCPツール

サーバーは次のツールを提供します。

  • get-pokemon: 特定のポケモンの名前の詳細情報を取得します

  • random-pokemon: ランダムなポケモンの情報を取得する

  • random-pokemon-from-region: 特定の地域からランダムにポケモンをゲット

  • random-pokemon-by-type: 特定のタイプのポケモンをランダムに入手する

  • pokemon-query: ポケモンに関する自然言語クエリに答える

建築

サーバーは以下を使用して構築されます:

  • タイプスクリプト

  • MCP TypeScript SDK（@modelcontextprotocol/sdk）

  • 入力検証のためのZod

  • MCP通信用の標準I/Oトランスポート

インストール

Smithery経由でインストール

Smithery経由で Claude Desktop 用の Pokémcp を自動的にインストールするには:

npx -y @smithery/cli install @NaveenBandarage/poke-mcp --client claude

手動インストール

# Clone the repository
git clone https://github.com/yourusername/poke-mcp.git
cd poke-mcp

# Install dependencies
npm install

# Build the project
npm run build

使用法

Claudeデスクトップアプリ

  1. Claudeデスクトップアプリをダウンロードしてインストールする

  2. Claudeデスクトップの設定を開く

  3. 開発者設定に移動して設定ファイルを編集します

  4. 次の構成を追加します。

{
  "mcpServers": {
    "pokedex": {
      "command": "path/to/poke-mcp/build/index.js"
    }
  }
}

  1. Claudeデスクトップを再起動します

  2. クロードで利用可能なポケモンツールが表示されるはずです

クエリの例

MCP クライアントに接続すると、次のような質問をすることができます。

  • 「ピカチュウについて教えてください」

  • 「ランダムにポケモンをください」

  • 「カントー地方のポケモンをランダムに表示」

  • 「ランダムウォーターポケモンって何？」

プロジェクト構造

  • src/index.ts: メインサーバーの実装

  • src/types.ts: ポケモンデータのTypeScript型定義

  • package.json: プロジェクトの依存関係とスクリプト

  • tsconfig.json: TypeScript の設定

新機能の追加

新しいツールを追加したり、既存のツールを強化したりするには:

  1. データの取得とフォーマットを行うための新しいヘルパー関数を定義する

  2. server.tool() メソッドを使用して新しいツールを登録する

  3. リクエストを処理してレスポンスを返すツールロジックを実装する

ライセンス

ISC

謝辞

このプロジェクトでは、ドメイン固有の知識と機能を使用して AI アシスタントを拡張できるカスタム MCP サーバーを構築する方法を示します。

Available Tools

4 tools
pokemon-queryC

Answer natural language Pokémon queries

ParametersJSON Schema
NameRequiredDescriptionDefault
queryYesA natural language query about Pokémon

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 for behavioral disclosure. While 'Answer natural language Pokémon queries' implies a read-only operation, it doesn't specify what types of answers are provided (facts, stats, descriptions), whether there are limitations on query complexity, or how results are formatted. The description lacks behavioral details beyond the 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 extremely concise with just 5 words: 'Answer natural language Pokémon queries'. Every word earns its place by specifying the action, input format, and subject matter. It's front-loaded with no unnecessary elaboration or redundancy.

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 a single parameter with good schema coverage, the description is incomplete. It doesn't explain what types of answers are returned, how comprehensive the knowledge base is, or any limitations. For a query tool with no structured output documentation, the description should provide more context about response format and capabilities.

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 'query' well-documented as 'A natural language query about Pokémon'. The description adds no additional parameter semantics beyond what the schema already provides. With high schema coverage, the baseline score of 3 is appropriate as the description doesn't enhance parameter understanding.

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: 'Answer natural language Pokémon queries' specifies the action (answer) and resource (Pokémon queries). It distinguishes from sibling tools like 'random-pokemon' which provide random selections rather than query-based answers. However, it doesn't explicitly mention what types of Pokémon information it can answer about.

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 its siblings. It doesn't mention alternatives like using 'random-pokemon' for random selections or specify scenarios where this query tool is preferred. The only implied usage is for natural language questions about Pokémon, but no explicit context or exclusions are provided.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

random-pokemonB

Get a random Pokémon

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 full burden but only states the basic action. It doesn't disclose behavioral traits like whether this is a read-only operation, if it requires authentication, rate limits, what data is returned, or if there are any constraints on randomness. The description is minimal and lacks necessary 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 extremely concise with just three words, front-loading the core purpose without any wasted text. Every word earns its place, making it efficient for quick understanding.

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 'Get' entails (e.g., returns Pokémon data), the format of the result, or how randomness is implemented. For a 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.

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 mention parameters, which aligns with the schema. Baseline is 4 for 0 parameters as it correctly avoids unnecessary information.

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 'Get a random Pokémon' clearly states the action (Get) and resource (a random Pokémon), making the purpose immediately understandable. However, it doesn't differentiate from sibling tools like 'random-pokemon-by-type' or 'random-pokemon-from-region' which suggests more specific random selection methods.

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 its siblings. There's no mention of alternatives like 'pokemon-query' for specific searches or the other random tools for filtered random selection, leaving the agent without usage context.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

random-pokemon-by-typeC

Get a random Pokémon of a specific type

ParametersJSON Schema
NameRequiredDescriptionDefault
typeYesThe Pokémon type (e.g., fire, water, grass, etc.)

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 states the tool 'Get[s] a random Pokémon,' which suggests a read-only operation, but doesn't clarify aspects like whether the randomness is seeded, if there are rate limits, what format the output takes, or if authentication is required. This leaves significant gaps for a tool with no annotation coverage.

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 functionality ('Get a random Pokémon of a specific type') with no wasted words. 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 lack of annotations and output schema, the description is incomplete. It doesn't explain what the tool returns (e.g., Pokémon details, just a name), how randomness is determined, or any behavioral constraints. For a tool with no structured data beyond the input schema, this leaves too many open questions 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 input schema has 100% description coverage, with the parameter 'type' documented as 'The Pokémon type (e.g., fire, water, grass, etc.).' The description adds minimal value by mentioning 'specific type,' which aligns with but doesn't expand beyond 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 action ('Get a random Pokémon') and target resource ('of a specific type'), making the purpose immediately understandable. However, it doesn't differentiate from sibling tools like 'random-pokemon' or 'random-pokemon-from-region' beyond mentioning the type parameter.

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 'random-pokemon' (which might get any random Pokémon) or 'random-pokemon-from-region' (which filters by region). The description implies usage when a type filter is needed, but doesn't explicitly state this or mention exclusions.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

random-pokemon-from-regionC

Get a random Pokémon from a specific region

ParametersJSON Schema
NameRequiredDescriptionDefault
regionYesThe Pokémon region (e.g., kanto, johto, hoenn, etc.)

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 what the tool does but doesn't describe key traits: whether it's read-only or mutative, if there are rate limits, authentication needs, or what the output looks like (e.g., Pokémon details). This leaves significant gaps for a tool with no structured safety hints.

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 one parameter, 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 behavioral aspects like safety or output format, and while the schema covers parameters well, the overall context for a tool with no structured metadata is insufficient, requiring more guidance for reliable 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 'region' well-documented in the schema (including examples like 'kanto'). The description adds no additional parameter details beyond what's in the schema, so it meets the baseline score of 3 where 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 action ('Get a random Pokémon') and the resource ('from a specific region'), making the purpose immediately understandable. However, it doesn't explicitly differentiate from sibling tools like 'random-pokemon' (which likely gets any random Pokémon) or 'random-pokemon-by-type' (which filters by type rather than region), missing 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. There's no mention of when it's appropriate compared to 'pokemon-query', 'random-pokemon', or 'random-pokemon-by-type', nor any context about prerequisites or exclusions, leaving the agent to infer usage from the name alone.

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.

  1. 4 tool updatesv1.0.0
    • First observedpokemon-query
    • First observedrandom-pokemon
    • First observedrandom-pokemon-by-type
    • First observedrandom-pokemon-from-region
Deploy Server
One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

TDQS

A3.5/5.0

Scored across 4 tools

Disambiguation5/5

Each tool has a clearly distinct purpose: pokemon-query handles natural language questions, random-pokemon provides a completely random selection, random-pokemon-by-type filters by type, and random-pokemon-from-region filters by region. There is no overlap in functionality, making tool selection straightforward.

Naming Consistency5/5

All tool names follow a consistent kebab-case pattern with a clear descriptive structure: random-pokemon, random-pokemon-by-type, random-pokemon-from-region, and pokemon-query. The naming is predictable and easy to understand across the set.

Tool Count5/5

With 4 tools, this server is well-scoped for its purpose of providing Pokémon information and random selections. Each tool serves a specific and useful function without redundancy, making the count appropriate for the domain.

Completeness4/5

The toolset covers core random selection and querying needs effectively, but there are minor gaps such as the inability to get specific Pokémon by name or ID, or to list Pokémon by type/region without randomness. However, agents can likely work around these limitations for most use cases.

Maintenance

ActivityInactive
ResponsivenessNo issues

Resources

Related MCP Connectors

Related MCP Servers

  • PokeAPI MCP Server

    AkhrHysd
    F
    license
    Not graded
    quality
    D
    maintenance
    A Model Context Protocol server that interfaces with PokeAPI to provide Pokémon information to LLM applications through JSON-RPC over stdio.
    -

  • PokeMCP

    ChiragAgg5k
    F
    license
    B
    quality
    D
    maintenance
    An MCP server that provides detailed Pokémon information by integrating with the PokeAPI, allowing users to fetch comprehensive data about Pokémon and simulate battles.
    2
    2
    -

  • PokéAPI MCP Server

    kumaranvpl
    F
    license
    Not graded
    quality
    D
    maintenance
    An MCP (Multi-Agent Conversation Protocol) Server that provides an interface to access Pokémon data through the PokéAPI, enabling agents to retrieve information about Pokémon species, abilities, moves, and more via natural language.
    -

  • Poke-MCP

    Jalajil
    F
    license
    Not graded
    quality
    D
    maintenance
    A Model Context Protocol server that provides comprehensive Pokemon data and battle simulation capabilities to AI assistants. It enables users to access detailed stats, types, and moves while simulating battles with realistic mechanics like type effectiveness and status effects.
    -