这是一个 Python/MCP 概念验证项目，用于读取 MTGDecks.net 的公开页面，并将元游戏和套牌信息规范化为统一的 JSON 格式。
由于未确认存在公开的 API 文档，本项目使用网站的公开 HTML 页面和基于 URL 的筛选参数。无需浏览器登录或 Cookie。
get_metagame(
format: str,
source: str = "all",
)
get_recent_decks(
format: str,
platform: str | None = None,
game_type: str | None = None,
max_pages: int = 3,
)
get_archetype_decks(
format: str,
archetype: str,
limit: int = 20,
)
get_top_performing_decks(
format: str,
platform: str | None = None,
min_players: int | None = None,
limit: int = 20,
)每个功能均以 Python 函数和 MCP 工具两种形式提供。
Related MCP server: Mystic Forge
Python 3.10 或更高版本
推荐使用 uv
git clone <repository-url>
cd Metagame-MCP
uv sync如需安装开发及测试依赖，请使用以下命令。
uv sync --extra dev服务器默认通过 stdio 传输方式运行。
uv run mtgdecks-mcpMCP 主机配置示例如下。请将 cwd 修改为该仓库的实际绝对路径。
{
"mcpServers": {
"mtgdecks": {
"command": "uv",
"args": ["run", "mtgdecks-mcp"],
"cwd": "C:\\path\\to\\Metagame-MCP"
}
}
}注册的 MCP 工具共有以下四个。
get_metagame
get_recent_decks
get_archetype_decks
get_top_performing_decks
from mtgdecks_mcp import (
get_archetype_decks,
get_metagame,
get_recent_decks,
get_top_performing_decks,
)
metagame = get_metagame("Modern", source="mtgo")
recent = get_recent_decks(
"Modern",
platform="mtgo",
game_type="BO3",
max_pages=1,
)
archetype = get_archetype_decks(
"Modern",
"Boros Energy",
limit=5,
)
top = get_top_performing_decks(
"Modern",
platform="mtgo",
min_players=64,
limit=10,
)当需要多次查询时，建议直接使用客户端以便复用 HTTP 连接，这样效率更高。
from mtgdecks_mcp import MTGDecksClient
with MTGDecksClient() as client:
modern = client.get_metagame("Modern")
pioneer = client.get_metagame("Pioneer")formatMTGDecks.net 使用的赛制名称。例如：Standard、Pioneer、Modern、Legacy、Pauper、Commander、Duel-Commander。
source值 | 含义 |
| 全部元游戏 |
| MTGO 赛事元游戏 |
| 近期大型赛事元游戏 |
mtgo-events、major-events、recent-major-events 也可作为别名使用。
platformmtgo
arena
tabletop
不区分大小写。
game_typeBO1
BO3
不区分大小写。
max_pages：1~10
limit：1~100
min_players：正整数
{
"format": "Modern",
"source": "all",
"url": "https://mtgdecks.net/Modern",
"selected_deck_count": 10994,
"updated_at": "2026-08-21 06:47:39",
"archetypes": [
{
"name": "Boros Energy",
"url": "https://mtgdecks.net/Modern/boros-energy",
"meta_share_percent": 7.98,
"trend_percent": -2.85,
"tier": "A",
"win_rate_percent": 49.0,
"top_25_conversion": 0.95,
"deck_count": 877,
"price_usd": 1109.0
}
]
}套牌查询功能统一返回 pages 和 decks 两个字段。pages 中包含实际查询过的原始页面 URL。
{
"format": "Modern",
"pages": ["https://mtgdecks.net/Modern/decklists/page:1"],
"decks": [
{
"name": "deck",
"url": "https://mtgdecks.net/Modern/example-decklist-123",
"author": "Player",
"archetype": "Boros Energy",
"game_type": "BO3",
"platform": "mtgo",
"event": "MTGO Modern Challenge",
"event_level": 3,
"players": 94,
"spiciness_percent": 30.0,
"date": "2026-08-20",
"price_usd": 1112.0,
"placement": "1st",
"wins": 5,
"losses": 0,
"draws": 0,
"win_rate_percent": 100.0
}
]
}如果 MTGDecks 页面未提供某字段的值，则该字段可能为 null。价格以页面上的 Paper/TCGPlayer 基准美元金额为准。
get_top_performing_decks 不自行计算表现分数，而是按照 MTGDecks 的 rank 升序排列，因此会优先返回冠军、亚军、八强等赛事成绩较好的套牌。
uv run pytest测试不访问外部网站，而是使用保存的 HTML 示例和 httpx.MockTransport 进行。
src/mtgdecks_mcp/
├── __init__.py # 공개 Python API
├── parsers.py # MTGDecks HTML 정규화
├── server.py # MCP 도구 등록과 stdio 서버
└── service.py # URL 구성, HTTP 클라이언트, 네 가지 기능
tests/
├── test_parsers.py
└── test_service.py本项目依赖公开的 HTML 结构，因此如果 MTGDecks.net 的标记或路径发生变化，则可能需要修改解析器。
本概念验证不包含大规模爬取、并行采集、缓存或数据库持久化功能。
原始数据的准确性和可用性取决于 MTGDecks.net。
所有规范化结果均包含可追溯的原始页面 URL。
MTGDecks 的使用条款将内容限制为个人和非商业用途。如需扩展到商业服务或持续大规模采集，请事先获得 MTGDecks 的许可或建立 API 合作伙伴关系。
相关文档：MTGDecks 使用条款
Return recent decks belonging to one archetype.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | ||
| format | Yes | ||
| archetype | Yes |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It clearly signals a read-only retrieval operation, but 'recent' is vague and no ordering, time-window, or pagination behavior is disclosed. The simple return nature keeps this at a middle score.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
A single sentence with no filler words. It front-loads the action and result, and every word contributes to the meaning.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
An output schema exists, so return-value details are covered elsewhere. However, the ambiguity of 'recent', the lack of format explanation, and the absence of any usage context leave minor but real gaps for an agent deciding when and how to call this tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description should compensate for the undocumented parameters. It only adds meaning for 'archetype' and partially for the notion of recency, but it does not explain what 'format' means or clarify the 'limit' parameter beyond what the schema already provides.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb ('Return') and a specific resource ('recent decks belonging to one archetype'). This clearly distinguishes the tool from siblings like get_recent_decks or get_top_performing_decks, which target different subsets of decks.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit guidance is given about when to choose this tool over get_recent_decks or get_top_performing_decks. The archetype qualifier implies a use case, but the description never states alternatives or exclusion conditions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Return normalized archetype shares for a format (source: all, mtgo, or major).
| Name | Required | Description | Default |
|---|---|---|---|
| format | Yes | ||
| source | No | all |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the burden of behavioral disclosure. It indicates a read-only lookup behavior ('Return') and notes the 'normalized' aggregation, but it does not state whether results are paginated, sorted, or restricted by other implicit filters. For a simple getter, this is acceptable but not fully transparent.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
A single sentence that front-loads the core action and resource, then clarifies the source parameter. No filler or redundancy. Every phrase earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is simple, has an output schema, and the schema supplies the default for 'source'. However, the description omits any list or hint of accepted format values, and there is no mention of output shape or sample usage. It is adequate for a basic request but leaves an agent unsure about valid format inputs.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. It adds meaning to 'source' by listing allowed values (all, mtgo, major), but it does not elaborate on the 'format' parameter beyond 'a format', leaving a clear gap about what format strings are valid. Partial compensation only.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb ('Return') and resource ('normalized archetype shares for a format'), which clearly identifies the tool's purpose. It also identifies the 'source' filter options, and this distinguishes it from sibling tools that retrieve decks (get_recent_decks, get_archetype_decks, get_top_performing_decks).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives no guidance on when to use this tool versus the sibling deck-retrieval tools. It does not mention any conditions, alternatives, or exclusions. An agent would have to infer use cases from the tool name and description alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Return recent deck rows, optionally filtered by platform and BO1/BO3 game type.
| Name | Required | Description | Default |
|---|---|---|---|
| format | Yes | ||
| platform | No | ||
| game_type | No | ||
| max_pages | No |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are present, so the description carries the full burden of behavioral disclosure. It does not state whether this is a read-only operation, how pagination works, how results are sorted, or what limits apply; it only restates the query shape and optional filters.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, clear, front-loaded sentence with no filler. It earns points for brevity, though the terse wording sacrifices important details.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a four-parameter tool with no annotations and 0% schema coverage, the description is too sparse. It omits format guidance, pagination semantics, and sibling differentiation, so an agent cannot reliably know how to construct required arguments or choose this tool over similar ones.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. It adds meaning for 'platform' and 'game_type' but does not explain the required 'format' field, valid values, or what 'max_pages' controls, leaving the agent with insufficient input guidance.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a clear verb ('Return') and identifies the resource ('recent deck rows') along with optional filters for platform and game type. It is reasonably distinguishable from siblings like get_metagame or get_top_performing_decks through the 'recent' qualifier, though it does not explicitly name those alternatives.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives no explicit guidance on when to use this tool versus get_metagame, get_archetype_decks, or get_top_performing_decks. It implies a recency-based use case but provides no exclusions, prerequisites, or alternative routing.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Return decks ordered by best finish, optionally filtered by platform and attendance.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | ||
| format | Yes | ||
| platform | No | ||
| min_players | No |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the behavioral disclosure burden. It does reveal ordering behavior and optional filtering, but it does not explain how 'best finish' is calculated, whether a limit applies, or how filters interact. The word 'attendance' does not match any schema parameter, which introduces ambiguity.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence with a front-loaded verb and resource, no filler, and no repetition. Every part of the sentence contributes to understanding the tool's core behavior.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with four parameters, one required parameter, and no annotations, the description is thin. It does not mention that 'format' is required, leaves 'limit' unexplained, and provides no guidance for choosing this tool over its siblings. The output schema covers return values, but the invocation context remains incomplete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate, but it only hints at two of four parameters: 'platform' and 'attendance' (presumably min_players). It omits the required 'format' parameter entirely and does not explain 'limit'. The term 'attendance' is not a schema property and could mislead an agent.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description states an explicit verb ('Return') and resource ('decks'), and adds the key ordering criterion ('by best finish') and optional filters. It is distinguishable from siblings like get_recent_decks due to the performance focus, though it does not explicitly name alternative tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives clear context that this tool is for top-performing decks and mentions optional filtering, but it does not explicitly say when to use this tool versus get_metagame, get_recent_decks, or get_archetype_decks. Usage is implied rather than stated with exclusions or comparisons.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
v0.1.0get_archetype_decksget_metagameget_recent_decksget_top_performing_decksScored across 4 tools
The tools are mostly distinct: get_metagame provides aggregate archetype shares, get_recent_decks provides unfiltered recent deck lists, get_archetype_decks filters recent decks by a specific archetype, and get_top_performing_decks sorts by finish. However, get_recent_decks and get_archetype_decks both return recent decks and could be confused when a user wants all decks versus a single archetype.
All four tool names follow a consistent get_ prefix with snake_case, and three use the get_<adjective>_decks pattern. get_metagame is the only outlier, but it still shares the verb-first style and is clear and predictable.
Four tools is a well-scoped count for a metagame analysis server. Each tool addresses a distinct query need without unnecessary bloat or minimalism, fitting comfortably within the ideal 3-15 range.
The tool surface covers the core metagame queries: aggregate shares, all recent decks, archetype-filtered decks, and top performers. Minor gaps like deck detail lookup or archetype listing exist, but agents can answer most metagame questions using these four tools.
Organize and track your Magic: The Gathering collection, decks, prices and imports.
MTG market data: search 114K+ cards, price signals, AI analysis. Free tier available.
Scryfall MCP — Magic: The Gathering card database.
Provide detailed Pokémon data and information through a standardized MCP interface. Enable LLMs an…