MTGDecks.net の公開ページを読み取り、メタゲームとデッキ情報を一貫したJSON形式に正規化するPython/MCP PoCです。
文書化された公開APIが確認できないため、サイトの公開HTMLとURLベースのフィルタを使用します。ブラウザのログインやクッキーは不要です。
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ツールは次の4つです。
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基準のUSD値です。
get_top_performing_decks は独自のパフォーマンススコアを計算せず、MTGDecksの rank 昇順ソートを使用します。したがって、優勝、準優勝、Top 8などのイベント成績が良いデッキから返されます。
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のマークアップやパスが変更されるとパーサーの修正が必要になる場合があります。
大量クローリング、並列収集、キャッシュ/データベースの永続化はPoCの範囲に含まれていません。
元データの正確性と可用性は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…