Click on "Deploy Server".
Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state.
In the chat, type @ followed by the MCP server name and your instructions, e.g., "@MTGDecks Metagame MCP Server What's the current Modern metagame?"
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.
A Python/MCP PoC that reads public pages of MTGDecks.net and normalizes metagame and deck information into a consistent JSON format.
Since no documented public API was found, it uses the site's public HTML and URL-based filters. No browser login or cookies are required.
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,
)Each feature is provided both as a Python function and as an MCP tool.
Related MCP server: Mystic Forge
Python 3.10 or higher
uv recommended
git clone <repository-url>
cd Metagame-MCP
uv syncTo install including development and test dependencies, use the following command.
uv sync --extra devThe server runs with stdio transport by default.
uv run mtgdecks-mcpAn example MCP host configuration is as follows. cwd must be changed to the actual absolute path of this repository.
{
"mcpServers": {
"mtgdecks": {
"command": "uv",
"args": ["run", "mtgdecks-mcp"],
"cwd": "C:\\path\\to\\Metagame-MCP"
}
}
}The following four MCP tools are registered.
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,
)When querying multiple times, it is more efficient to use the client directly so that HTTP connections can be reused.
from mtgdecks_mcp import MTGDecksClient
with MTGDecksClient() as client:
modern = client.get_metagame("Modern")
pioneer = client.get_metagame("Pioneer")formatThe format name used on MTGDecks.net. Examples: Standard, Pioneer, Modern, Legacy, Pauper, Commander, Duel-Commander.
sourceValue | Meaning |
| Full metagame |
| MTGO event metagame |
| Recent major event metagame |
mtgo-events, major-events, and recent-major-events can also be used as aliases.
platformmtgo
arena
tabletop
Case is not distinguished.
game_typeBO1
BO3
Case is not distinguished.
max_pages: 1~10
limit: 1~100
min_players: positive integer
{
"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
}
]
}Deck query functions commonly return pages and decks. pages contains the original page URLs that were actually queried.
{
"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
}
]
}Fields that MTGDecks pages do not provide values for may be null. Prices are USD values based on the page's Paper/TCGPlayer.
get_top_performing_decks does not calculate its own performance score but uses MTGDecks' rank ascending sort. Therefore, decks with better event results such as champion, runner-up, and Top 8 are returned first.
uv run pytestTests use stored HTML examples and httpx.MockTransport without connecting to external sites.
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.pyThis project depends on the public HTML structure, so if MTGDecks.net's markup or paths change, parser updates may be needed.
Mass crawling, parallel collection, and cache/database persistence are not included in the PoC scope.
The accuracy and availability of the original data depend on MTGDecks.net.
All normalized results include traceable original URLs.
MTGDecks' terms of use restrict content to personal, non-commercial use. Before expanding to commercial services or continuous mass collection, confirm permission or an API partnership with MTGDecks.
Related documentation: MTGDecks Terms of Use
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.
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…
Live TCG card and decklist prices for AI assistants. 22+ games, no account, ready-to-buy links.