Skip to main content
Glama
enesjakozh
NaveenBandarage

Poke-MCP

by NaveenBandarage
OverviewSchemaRelated ServersScoreDiscussions
TypeScript
Remote

Overview

Poke-MCP is a Model Context Protocol (MCP) server that provides Pokémon information through a standardized interface. It connects to the PokeAPI to fetch Pokémon data and exposes it through MCP tools that can be used by any MCP-compatible client, such as Claude Desktop App, Continue, Cline, and others.

This server now supports HTTP transport using Server-Sent Events (SSE) for real-time communication, making it accessible over HTTP instead of just stdio.

Related MCP server: PokeMCP

Features

  • Get information about specific Pokémon by name

  • Discover random Pokémon

  • Find random Pokémon from specific regions (Kanto, Johto, Hoenn, etc.)

  • Get random Pokémon of specific types (Fire, Water, Electric, etc.)

  • Natural language query interface for Pokémon information

How It Works

Poke-MCP is built using the Model Context Protocol, which enables AI applications to access external tools and data sources in a standardized way. The server:

  1. Connects to the PokeAPI to fetch Pokémon data

  2. Exposes several tools through the MCP interface

  3. Processes requests from MCP clients

  4. Returns formatted Pokémon information

MCP Tools

The server provides the following tools:

  • get-pokemon: Get detailed information about a specific Pokémon by name

  • random-pokemon: Get information about a random Pokémon

  • random-pokemon-from-region: Get a random Pokémon from a specific region

  • random-pokemon-by-type: Get a random Pokémon of a specific type

  • pokemon-query: Answer natural language queries about Pokémon

Architecture

The server is built using:

  • TypeScript

  • MCP TypeScript SDK (@modelcontextprotocol/sdk)

  • Zod for input validation

  • HTTP transport with Server-Sent Events (SSE) for MCP communication

  • Node.js built-in HTTP server

Installation

Installing via Smithery

To install Pokémcp for Claude Desktop automatically via Smithery:

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

Manual Installation

# 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

Usage

Running the HTTP Server

To start the server in HTTP mode:

# Start the server (defaults to port 3000)
npm start

# Or specify a custom port
PORT=8080 npm start

The server will be available at:

  • Info endpoint: http://127.0.0.1:3000/ - Server information and status

  • SSE endpoint: http://127.0.0.1:3000/sse - Server-Sent Events connection for MCP clients

  • Message endpoint: http://127.0.0.1:3000/message - POST endpoint for sending MCP messages

With Claude Desktop App (HTTP Transport)

  1. Download and install Claude Desktop App

  2. Open Claude Desktop settings

  3. Go to Developer settings and edit the config file

  4. Add the following configuration for HTTP transport:

{
  "mcpServers": {
    "pokedex": {
      "transport": {
        "type": "sse",
        "url": "http://127.0.0.1:3000/sse"
      }
    }
  }
}

  1. Start the Poke-MCP server: npm start

  2. Restart Claude Desktop

  3. You should now see the Pokémon tools available in Claude

Legacy Usage (stdio)

For backward compatibility, you can still run the server with stdio transport by reverting to the stdio implementation.

Example Queries

Once connected to an MCP client, you can ask questions like:

  • "Tell me about Pikachu"

  • "Give me a random Pokémon"

  • "Show me a random Pokémon from Kanto"

  • "What's a random Water Pokémon?"

Project Structure

  • src/index.ts: Main server implementation

  • src/types.ts: TypeScript type definitions for Pokémon data

  • package.json: Project dependencies and scripts

  • tsconfig.json: TypeScript configuration

Adding New Features

To add new tools or enhance existing ones:

  1. Define new helper functions to fetch and format data

  2. Register new tools using the server.tool() method

  3. Implement the tool logic to handle requests and return responses

License

ISC

Acknowledgments

This project demonstrates how to build custom MCP servers that can extend AI assistants with domain-specific knowledge and capabilities.

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.

Install Server
RayrunBuild, deploy, and operate MCP servers without becoming an infrastructure team.ray.runAd

TDQS

A3.5/5.0
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

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

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

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/NaveenBandarage/poke-mcp'

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