Skip to main content
Glama
enesjakozh
NaveenBandarage

Poke-MCP

by NaveenBandarage
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Remote

insignia de herrería

Descripción general

Poke-MCP es un servidor de Protocolo de Contexto de Modelo (MCP) que proporciona información de Pokémon mediante una interfaz estandarizada. Se conecta a PokeAPI para obtener datos de Pokémon y los expone mediante herramientas MCP compatibles con cualquier cliente compatible con MCP, como Claude Desktop App, Continue, Cline y otros.

Related MCP server: PokeMCP

Características

  • Obtén información sobre Pokémon específicos por nombre

  • Descubre Pokémon al azar

  • Encuentra Pokémon aleatorios de regiones específicas (Kanto, Johto, Hoenn, etc.)

  • Consigue Pokémon aleatorios de tipos específicos (Fuego, Agua, Eléctrico, etc.)

  • Interfaz de consulta en lenguaje natural para información de Pokémon

Cómo funciona

Poke-MCP se basa en el Protocolo de Contexto de Modelo , que permite a las aplicaciones de IA acceder a herramientas y fuentes de datos externas de forma estandarizada. El servidor:

  1. Se conecta a PokeAPI para obtener datos de Pokémon.

  2. Expone varias herramientas a través de la interfaz MCP

  3. Procesa solicitudes de clientes de MCP

  4. Devuelve información formateada de Pokémon

Herramientas MCP

El servidor proporciona las siguientes herramientas:

  • get-pokemon: obtén información detallada sobre un Pokémon específico por su nombre

  • random-pokemon: Obtén información sobre un Pokémon aleatorio

  • random-pokemon-from-region: obtén un Pokémon aleatorio de una región específica

  • random-pokemon-by-type: Consigue un Pokémon aleatorio de un tipo específico

  • pokemon-query: Responde consultas en lenguaje natural sobre Pokémon

Arquitectura

El servidor está construido utilizando:

  • Mecanografiado

  • SDK de TypeScript de MCP (@modelcontextprotocol/sdk)

  • Zod para validación de entrada

  • Transporte de E/S estándar para la comunicación MCP

Instalación

Instalación mediante herrería

Para instalar Pokémcp para Claude Desktop automáticamente a través de Smithery :

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

Instalación manual

# 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

Uso

Con la aplicación de escritorio Claude

  1. Descargue e instale la aplicación Claude Desktop

  2. Abrir la configuración de Claude Desktop

  3. Vaya a la configuración del desarrollador y edite el archivo de configuración.

  4. Agregue la siguiente configuración:

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

  1. Reiniciar Claude Desktop

  2. Ahora deberías ver las herramientas Pokémon disponibles en Claude

Consultas de ejemplo

Una vez conectado a un cliente MCP, puede hacer preguntas como:

  • "Cuéntame sobre Pikachu"

  • "Dame un Pokémon al azar"

  • "Muéstrame un Pokémon al azar de Kanto"

  • "¿Qué es un Pokémon de agua aleatorio?"

Estructura del proyecto

  • src/index.ts: Implementación del servidor principal

  • src/types.ts: Definiciones de tipos de TypeScript para datos de Pokémon

  • package.json: Dependencias y scripts del proyecto

  • tsconfig.json: configuración de TypeScript

Añadiendo nuevas funciones

Para agregar nuevas herramientas o mejorar las existentes:

  1. Definir nuevas funciones auxiliares para obtener y formatear datos

  2. Registrar nuevas herramientas utilizando el método server.tool()

  3. Implementar la lógica de la herramienta para manejar solicitudes y devolver respuestas

Licencia

ISC

Expresiones de gratitud

Este proyecto demuestra cómo construir servidores MCP personalizados que puedan ampliar los asistentes de IA con conocimientos y capacidades específicos del dominio.

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