How do I use hearthstone-decks-mcp?

1. Click on "Install Server". 2. Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state. 3. In the chat, type @ followed by the MCP server name and your instructions, e.g., "@hearthstone-decks-mcp decode this deck code: AAECAZ8FBugE7QXUBfcF4gXtBQwBAfcC5wP5A/4D5wWJBpkH4wfXCOsE7QX3BQAA" That's it! The server will respond to your query, and you can continue using it as needed. Here is a step-by-step guide with screenshots.

hearthstone-decks-mcp

by YinshawnRao

Overview Schema Related Servers Score Discussions

Remote

hearthstone-decks-mcp

npm version License: MIT Node.js Version

一个基于Model Context Protocol (MCP)的炉石传说卡组解析服务器，可以解析卡组代码并返回详细的卡牌信息和封面图。

功能特性

🎯 卡组代码解析: 解析炉石传说卡组代码，返回详细的卡组信息
🔍 卡牌搜索: 根据卡牌名称搜索炉石传说卡牌
📋 卡牌详情: 根据卡牌ID获取详细的卡牌信息
🖼️ 封面图支持: 自动获取卡牌封面图URL
📊 统计信息: 提供卡组统计（法力值分布、稀有度统计等）
🔌 多传输方式: 支持标准输入输出、HTTP SSE、流式传输

Related MCP server: hearthstone-oracle

安装

全局安装（推荐）

npm install -g hearthstone-decks-mcp

本地安装

npm install hearthstone-decks-mcp

快速开始

作为MCP服务器使用

在Cursor或其他支持MCP的客户端中配置：

{
  "mcpServers": {
    "hearthstone-decks": {
      "command": "npx",
      "args": ["hearthstone-decks-mcp"]
    }
  }
}

独立运行

标准输入输出模式（stdio）

npx hearthstone-decks-mcp
# 或者
hearthstone-decks-mcp

HTTP SSE模式

npx hearthstone-decks-mcp --transport=http
# 或者
hearthstone-decks-mcp --transport=http

命令行选项

--transport=stdio - 使用标准输入输出模式（默认）
--transport=http - 使用HTTP SSE模式

环境变量

# HTTP服务器配置
HTTP_PORT=3000          # HTTP服务器端口（默认3000）
HTTP_HOST=localhost     # HTTP服务器主机（默认localhost）

# 卡牌数据缓存配置
CARD_DATA_TTL=24        # 卡牌数据缓存时间（小时，默认24）

API接口

工具列表

parse_deck_code - 解析卡组代码
- 参数：
  - deckCode (string, 必需): 炉石传说卡组代码
  - includeStats (boolean, 可选): 是否包含统计信息，默认为true
search_cards - 搜索卡牌
- 参数：
  - cardName (string, 必需): 要搜索的卡牌名称
  - limit (integer, 可选): 返回结果数量限制，默认为10
get_card_info - 获取卡牌详情
- 参数：
  - cardId (string, 必需): 炉石传说卡牌ID

HTTP API端点

当使用HTTP模式时，服务器提供以下端点：

GET / - 测试页面
GET /sse - Server-Sent Events端点
GET /tools - 获取可用工具列表
POST /tools/{toolName} - 调用指定工具
GET /health - 健康检查

使用示例

1. 解析卡组代码

curl -X POST http://localhost:3000/tools/parse_deck_code \
  -H "Content-Type: application/json" \
  -d '{
    "deckCode": "AAECAZ8FBugE7QXUBfcF4gXtBQwBAfcC5wP5A/4D5wWJBpkH4wfXCOsE7QX3BQAA",
    "includeStats": true
  }'

2. 搜索卡牌

curl -X POST http://localhost:3000/tools/search_cards \
  -H "Content-Type: application/json" \
  -d '{
    "cardName": "火球术",
    "limit": 5
  }'

3. 获取卡牌详情

curl -X POST http://localhost:3000/tools/get_card_info \
  -H "Content-Type: application/json" \
  -d '{
    "cardId": "CS2_029"
  }'

返回数据格式

卡组解析结果

{
  "success": true,
  "data": {
    "meta": {
      "version": 1,
      "format": "Standard",
      "totalCards": 30,
      "deckCode": "AAECAZ8F..."
    },
    "heroes": [
      {
        "id": "HERO_04",
        "name": "乌瑟尔",
        "cardClass": "PALADIN",
        "imageUrl": "https://art.hearthstonejson.com/v1/render/latest/zhCN/512x/HERO_04.png"
      }
    ],
    "cards": [
      {
        "id": "CS2_088",
        "name": "守护者祝福",
        "cost": 1,
        "type": "SPELL",
        "cardClass": "PALADIN",
        "rarity": "COMMON",
        "count": 2,
        "imageUrl": "https://art.hearthstonejson.com/v1/render/latest/zhCN/512x/CS2_088.png"
      }
    ],
    "statistics": {
      "totalCards": 30,
      "totalUnique": 15,
      "manaCurve": [2, 4, 6, 8, 4, 3, 2, 1, 0, 0, 0],
      "rarities": {
        "COMMON": 14,
        "RARE": 8,
        "EPIC": 4,
        "LEGENDARY": 4
      },
      "cardTypes": {
        "MINION": 20,
        "SPELL": 8,
        "WEAPON": 2
      },
      "classes": {
        "PALADIN": 15,
        "NEUTRAL": 15
      }
    }
  }
}

数据源

卡牌数据: HearthstoneJSON API
卡牌封面图: HearthstoneJSON Render API

卡牌ID说明

炉石传说的卡牌有两种ID格式：

字符串ID (如 CS2_029): 这是卡牌的唯一字符串标识符
DBF ID (如 315): 这是卡牌的数字标识符，用于卡组代码中

卡组代码解析时会获得DBF ID，然后通过映射关系找到对应的字符串ID和卡牌详细信息。

开发

从源码运行

git clone https://github.com/yinshawnrao/hearthstone-decks-mcp.git
cd hearthstone-decks-mcp
npm install
npm start

开发模式

npm run dev  # 使用nodemon自动重启

测试

npm test

技术栈

Node.js - 运行时环境
@modelcontextprotocol/sdk - MCP协议支持
Express.js - HTTP服务器
node-fetch - HTTP客户端
Server-Sent Events - 实时通信

许可证

MIT License

贡献

欢迎提交Issue和Pull Request！

提交Issue

报告Bug
请求新功能
改进建议

提交Pull Request

Fork 项目
创建功能分支 (git checkout -b feature/amazing-feature)
提交更改 (git commit -m 'Add some amazing feature')
推送到分支 (git push origin feature/amazing-feature)
打开Pull Request

更新日志

v1.0.0

初始版本发布
支持卡组代码解析
支持卡牌搜索
支持卡牌详情查询
支持HTTP和stdio传输模式
提供美观的测试界面

注意事项

首次运行时会从HearthstoneJSON API下载卡牌数据，可能需要一些时间
卡牌数据会缓存24小时（可配置）
部分卡组代码可能需要最新的解析算法支持
建议在生产环境中配置适当的缓存和错误处理

常见问题

Q: 卡组代码解析失败怎么办？

A: 请确保卡组代码是有效的炉石传说卡组代码，格式类似于 AAECAZ8F...

Q: 搜索不到某些卡牌？

A: 请检查卡牌名称是否正确，支持中文和英文名称搜索

Q: 图片无法显示？

A: 图片URL来自HearthstoneJSON，请检查网络连接和API可用性

Available Tools

3 tools

get_card_infoC

根据卡牌ID获取详细的炉石传说卡牌信息

ParametersJSON Schema

Name	Required	Description	Default
`cardId`	Yes	炉石传说卡牌ID

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. While it indicates this is a read operation ('获取' - get), it doesn't describe any behavioral traits such as error handling (e.g., what happens if cardId is invalid), performance characteristics, rate limits, authentication requirements, or what 'detailed information' specifically includes. The description is minimal and lacks context 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.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is a single, efficient sentence that states the purpose clearly without unnecessary words. It's appropriately sized for a simple lookup tool and front-loaded with the core action. However, it could be slightly more structured by including basic usage context, but it earns high marks for zero waste.

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 tool's simplicity (1 parameter, no annotations, no output schema), the description is incomplete. It doesn't explain what 'detailed information' includes (e.g., card stats, effects, rarity), how errors are handled, or any dependencies. For a tool with no structured output schema, the description should provide more context about return values to be fully helpful to an agent.

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 cardId documented as '炉石传说卡牌ID' (Hearthstone card ID). The description adds no additional parameter semantics beyond what the schema provides—it doesn't explain format, examples, or constraints for cardId. With high schema coverage, the baseline is 3, as the schema does the heavy lifting without extra value from 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 verb ('获取' - get/retrieve) and resource ('炉石传说卡牌信息' - Hearthstone card information) with specificity about what information is retrieved ('详细的' - detailed). It distinguishes from parse_deck_code (which likely parses deck codes) and search_cards (which likely searches multiple cards) by focusing on single-card lookup by ID. However, it doesn't explicitly contrast with siblings beyond the inherent difference in operation type.

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 when to use get_card_info versus search_cards (e.g., when you have a specific card ID vs. when you need to search by name/attributes) or parse_deck_code. There's no context about prerequisites, limitations, or typical use cases beyond the basic operation.

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

parse_deck_codeB

解析炉石传说卡组代码，返回详细的卡组信息，包括卡牌详情和封面图

ParametersJSON Schema

Name	Required	Description	Default
`deckCode`	Yes	炉石传说卡组代码（如：AAECAZ8FBugE7QXUBfcF4gXtBQwBAfcC5wP5A/4D5wWJBpkH4wfXCOsE7QX3BQAA）
`includeStats`	No	是否包含卡组统计信息（法力值分布、稀有度统计等），默认为true

TDQS

B3.1/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 parses deck codes and returns detailed information, but doesn't describe behavioral traits such as error handling (e.g., for invalid codes), performance characteristics, rate limits, authentication needs, or output format specifics. For a tool with no annotation coverage, this leaves significant gaps in understanding how it behaves beyond basic functionality.

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 and output. It's front-loaded with the core action (parsing deck codes) and includes key details (card details and cover images) without unnecessary elaboration. Every word contributes to understanding the tool's function, making it highly concise and well-structured.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness3/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the tool's moderate complexity (parsing deck codes with optional stats) and lack of annotations and output schema, the description is minimally adequate. It covers what the tool does but lacks details on behavioral aspects, error handling, and output structure. Without an output schema, the description should ideally hint at return values, but it only mentions 'detailed deck information' vaguely, leaving gaps in completeness for effective agent 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 clear documentation for both parameters (deckCode and includeStats). The description doesn't add any parameter-specific semantics beyond what the schema provides—it mentions returning card details and cover images but doesn't explain how parameters influence this. With high schema coverage, the baseline score of 3 is appropriate, as the description doesn't compensate but also doesn't detract.

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: '解析炉石传说卡组代码，返回详细的卡组信息，包括卡牌详情和封面图' (Parse Hearthstone deck codes, return detailed deck information including card details and cover images). It specifies the verb (parse), resource (deck codes), and output (detailed deck info with card details and cover images). However, it doesn't explicitly distinguish from sibling tools like get_card_info or search_cards, which appear to be about individual cards rather than deck parsing.

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 sibling tools (get_card_info, search_cards) or specify contexts where this tool is appropriate (e.g., for analyzing deck compositions vs. looking up individual cards). There's no indication of prerequisites or exclusions, leaving usage entirely implicit.

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

search_cardsC

根据卡牌名称搜索炉石传说卡牌信息

ParametersJSON Schema

Name	Required	Description	Default
`cardName`	Yes	要搜索的卡牌名称（支持模糊搜索）
`limit`	No	返回结果数量限制，默认为10

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 mentions '支持模糊搜索' (supports fuzzy search) in the schema, but the description itself doesn't elaborate on this or other behaviors like response format, error handling, or rate limits. For a search tool with zero annotation coverage, this leaves significant gaps in understanding how it operates beyond basic functionality.

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: '根据卡牌名称搜索炉石传说卡牌信息' (Search for Hearthstone card information by card name). It's front-loaded with the core purpose, has zero wasted words, and is appropriately sized for a simple search tool. Every part of the sentence contributes directly to understanding the tool's function.

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 tool's moderate complexity (search functionality with fuzzy matching) and lack of annotations and output schema, the description is incomplete. It doesn't explain what the search returns (e.g., card details, IDs, or partial matches), how results are ordered, or any limitations. Without an output schema, the description should provide more context about the response to help the agent 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 input schema has 100% description coverage, clearly documenting both parameters: 'cardName' (with fuzzy search support) and 'limit' (with default and range). The description doesn't add any additional meaning beyond what the schema provides, such as examples of fuzzy search behavior or context for the limit parameter. With high schema coverage, the baseline score of 3 is appropriate as the schema handles parameter documentation adequately.

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: '根据卡牌名称搜索炉石传说卡牌信息' (Search for Hearthstone card information by card name). It specifies the verb ('搜索' - search), resource ('炉石传说卡牌信息' - Hearthstone card information), and key input ('卡牌名称' - card name). However, it doesn't explicitly differentiate from sibling tools like 'get_card_info' or 'parse_deck_code', which likely have different purposes.

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 sibling tools like 'get_card_info' (which might retrieve specific card details) or 'parse_deck_code' (which likely handles deck codes). There's no context about when this search tool is preferred over other methods or any prerequisites for its use.

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

B3.2/5.0

Disambiguation5/5

Each tool has a clearly distinct purpose: get_card_info retrieves details for a specific card ID, parse_deck_code processes deck codes to return deck information, and search_cards searches by card name. There is no overlap in functionality, making it easy for an agent to select the correct tool without confusion.

Naming Consistency5/5

All tool names follow a consistent verb_noun pattern (get_card_info, parse_deck_code, search_cards), using snake_case throughout. This predictability enhances readability and usability for agents, with no deviations in naming style.

Tool Count3/5

With only 3 tools, the server feels thin for a domain like Hearthstone decks, which might involve more operations such as creating, updating, or managing decks. While the tools cover basic retrieval and parsing, the count is borderline for the apparent scope, potentially limiting agent capabilities.

Completeness2/5

The tool set is significantly incomplete for a Hearthstone deck management domain. It lacks essential CRUD operations like creating, updating, or deleting decks, and does not cover lifecycle aspects such as deck validation or sharing. Agents will face dead ends when trying to perform common deck-related tasks beyond basic lookup and parsing.

Maintenance

ActivityInactive

ResponsivenessSyncing

Resources

Need Help?

Reddit Discussion

Related Servers

Unclaimed servers have limited discoverability.

Looking for Admin?

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

Related MCP Connectors

Hex.pm MCP B
io.github.joshrotenberg
MCP server for hex.pm and hexdocs.pm: search, inspect, compare, and audit Elixir packages
Developer Tools Documentation Access
2422
Apideck MCP A
dev.apideck.mcp
Model Context Protocol server for the Apideck Unified API. Connect any MCP-compatible agent framework to 100+ accounting systems, HRIS platforms, file storage providers, and more through one integration. More information https://www.apideck.com/mcp-server
Developer Tools
42
podcasts A
com.petabloom
An MCP server that provides tools to discover and retrieve podcast episodes transcripts.
Entertainment & Media Search
52
kkjdaniel-bgg-mcp AOAuth
ai.smithery
BGG MCP provides access to the BoardGameGeek API through the Model Context Protocol, enabling retr…
Search Games & Gamification Entertainment & Media
252

Related MCP Servers

Scryfall MCP Server
Games & Gamification Databases Search
bmurdock
A
license
A
quality
B
maintenance
A comprehensive Model Context Protocol server that integrates with the Scryfall API to provide Magic: The Gathering card data to AI assistants like Claude.
Updated a month ago (2026-07-30 16:04 UTC)
14
1
MIT
hearthstone-oracle
Games & Gamification Search Knowledge & Memory
gregario
A
license
A
quality
C
maintenance
Hearthstone MCP server with card search, deck analysis, and strategy coaching. Gives LLMs access to every Hearthstone card plus built-in strategy knowledge for deck building and gameplay advice.
Updated 4 months ago (2026-05-02 19:55 UTC)
9
58
1
MIT
MTG-MCP
Games & Gamification Entertainment & Media
wtfregia
A
license
Not graded
quality
C
maintenance
A comprehensive Model Context Protocol server that provides AI assistants with rich Magic: The Gathering information, including card data, comprehensive rules, EDHREC recommendations, combo interactions, and intelligent Commander deck generation.
Updated 10 months ago (2025-11-14 03:33 UTC)
1
MIT
lorcana-mcp
Games & Gamification Search
danielenricocahall
A
license
A
quality
A
maintenance
An MCP server for searching and aggregating Disney Lorcana cards, enabling card lookup, deck building, and statistical analysis.
Updated 11 days ago (2026-08-23 21:09 UTC)
10
1
MIT

Latest Blog Posts

Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)
By Om-Shree-0709 on July 25, 2026.
mcp
Agent Identity
OAuth 2.1
Your AI Chatbot Just Exposed Your CEO's Salary to an Intern
By Om-Shree-0709 on July 2, 2026.
Agent Identity
MCP Security
OAuth Delegation
Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)
By Om-Shree-0709 on June 30, 2026.
Agentic Ai
Prompt Injection
WebAssembly

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/YinshawnRao/hearthstone-decks-mcp'

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