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 도구는 다음 네 개입니다.
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…