Skip to main content
Glama
enesjakozh
NaveenBandarage

Poke-MCP

by NaveenBandarage
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Remote

铁匠徽章

概述

Poke-MCP 是一个模型上下文协议 (MCP) 服务器，通过标准化接口提供 Pokémon 信息。它连接到PokeAPI以获取 Pokémon 数据，并通过 MCP 工具将其公开，这些工具可供任何兼容 MCP 的客户端使用，例如 Claude Desktop App、Continue、Cline 等。

Related MCP server: PokeMCP

特征

  • 通过名称获取特定神奇宝贝的信息

  • 发现随机宝可梦

  • 寻找来自特定地区（关都、城都、丰缘等）的随机神奇宝贝

  • 获取特定类型的随机神奇宝贝（火、水、电等）

  • 神奇宝贝信息的自然语言查询界面

工作原理

Poke-MCP 使用模型上下文协议构建，该协议使 AI 应用程序能够以标准化的方式访问外部工具和数据源。服务器：

  1. 连接到 PokeAPI 以获取 Pokémon 数据

  2. 通过 MCP 界面公开多种工具

  3. 处理来自 MCP 客户端的请求

  4. 返回格式化的神奇宝贝信息

MCP 工具

该服务器提供以下工具：

  • get-pokemon：通过名称获取特定神奇宝贝的详细信息

  • random-pokemon：获取有关随机神奇宝贝的信息

  • random-pokemon-from-region：从特定区域随机获取一只神奇宝贝

  • random-pokemon-by-type：获取特定类型的随机神奇宝贝

  • pokemon-query：回答有关 Pokémon 的自然语言查询

建筑学

该服务器使用以下方式构建：

  • TypeScript

  • 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. 你现在应该可以看到 Claude 中可用的 Pokémon 工具

示例查询

连接到 MCP 客户端后，您可以提出以下问题：

  • “跟我讲讲皮卡丘吧”

  • “给我一只随机的宝可梦”

  • “随机给我看看一只来自关东地区的宝可梦”

  • “随机水系宝可梦是什么？”

项目结构

  • src/index.ts：主服务器实现

  • src/types.ts：Pokémon 数据的 TypeScript 类型定义

  • package.json：项目依赖项和脚本

  • tsconfig.json：TypeScript 配置

添加新功能

要添加新工具或增强现有工具：

  1. 定义新的辅助函数来获取和格式化数据

  2. 使用 server.tool() 方法注册新工具

  3. 实现工具逻辑来处理请求并返回响应

执照

国际学习中心

致谢

该项目演示了如何构建自定义 MCP 服务器，以使用特定领域的知识和功能扩展 AI 助手。

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.
    -