mtg-forja
The mtg-forja server provides comprehensive analysis tools for Magic: The Gathering decks, using verified Scryfall oracle text to detect synergies, combos, and conflicts, and to generate interactive HTML documents.
Resolve deck lists (
resolver_mazo): Parse and validate any deck list (MTG Arena, Moxfield, Archidekt, ManaBox, plain text, etc.) to obtain accurate card data from Scryfall.Deck radiography (
radiografia_del_mazo): Get objective facts—effect scope (symmetric/asymmetric), mentioned types, zones touched, speed, mana curve, type distribution, and color source coverage.Detect synergies and conflicts (
detectar_sinergias): Rule-based pattern matching identifies candidate interactions and anti-synergies, each backed by the exact oracle phrase that triggered the rule.Look up known combos (
combos_conocidos): Retrieve curated combos from Commander Spellbook that are fully or partially present, with step-by-step details (requires verification against oracle text).List engine rules (
listar_reglas): Browse the hand-written interaction patterns the engine understands, useful for coverage insight or extension.Generate documents (
render_guia,render_chuleta,render_mapa): Create three HTML outputs—an illustrated synergy guide, a printable two-sided cheat sheet with card thumbnails, and an interactive force-directed map where edge thickness reflects synergy strength and dashed red lines mark conflicts.One-shot analysis (
analizar): Run the full pipeline (resolve, detect, render all documents) in a single call for a fast initial pass.
Click on "Install 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., "@mtg-forjaAnalyze this deck list for synergies."
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.
MTG Forja
Analiza un mazo de Magic: The Gathering y genera tres cosas: una guía extensa de sinergias, una chuleta imprimible de dos caras y un mapa interactivo navegable.
Funciona de tres maneras: como servidor MCP dentro de Claude, como herramienta de línea de comandos y como web que corre entera en el navegador.
La premisa: las interacciones se comprueban contra el texto de oráculo real que devuelve Scryfall, nunca contra lo que un modelo de lenguaje cree recordar. Los cuatro errores que originaron este proyecto —una carta que se creía que barajaba y mandaba al fondo, una tierra indestructible tomada por condicional— son exactamente los que el motor detecta bien.
Qué genera
Pegas una lista de mazo y salen tres documentos HTML autónomos. Estas capturas son salida real del mazo de ejemplo: 45 cartas y 39 sinergias detectadas.
El mapa del mazo
Un grafo de fuerzas navegable: cada círculo es una carta, su tamaño depende de cuántas copias llevas y el grosor de la línea marca la fuerza de la sinergia. Las líneas rojas discontinuas son cartas que se estorban entre sí. Puedes pulsar cualquier carta para aislar sus conexiones, arrastrarlas y hacer zoom.
Salen todas las cartas del mazo, también las que no tienen ninguna relación detectada: una tierra suelta dice algo del mazo, y esconderla no.
Los filtros por función son acumulables — enciende varios y verás lo que encaje en cualquiera de ellos. Y el botón Ajustes controla la densidad de la red:
Mando | Para qué |
Conexiones por carta | Recorta la maraña dejando lo más fuerte de cada carta |
Fuerza mínima | Esconde las sinergias flojas |
Solo conflictos | Deja el mapa únicamente con los avisos |
El motor sigue calculando todas las sinergias; esto solo decide cuáles se dibujan. Los conflictos no se ocultan con ningún ajuste, porque avisar es el trabajo principal del mapa.

La guía de sinergias
Página larga con cada jugada desarrollada: las piezas ilustradas, la secuencia numerada de ejecución, los avisos y el mazo completo agrupado por función. Pensada para leerla una vez y entender el mazo.

La chuleta
Dos caras A4 densas, sin literatura, para imprimir y tener al lado mientras juegas. Cada línea es una interacción con sus cartas en miniatura y cuándo aplica.

Related MCP server: mtg-mcp-server
De qué se compone
Pieza | Qué es | Su papel aquí |
| 36 patrones de interacción escritos a mano | Lo que alguien enseñó. Profundo pero estrecho: solo encuentra lo que está escrito. |
Commander Spellbook | Base externa de combos curados | Lo que otros catalogaron. Combos con nombre propio y pasos redactados. Consultada bajo petición, cacheada, y siempre a contrastar contra el oráculo. |
| 37 conceptos de recurso | Lo que se deduce. No describe parejas de cartas sino recursos: quién los produce, quién los premia y quién los rompe. Cubre cualquier mazo, aunque más en superficie. |
El motor |
| Cruza el mazo con los patrones y devuelve las candidatas, cada una con la frase de oráculo que la disparó. |
| Cliente de Scryfall, con caché en disco | La fuente de verdad. Oráculo real y rulings oficiales de Wizards — el contenido de Gatherer. Todo lo que se afirma sale de aquí. |
Los renderizadores |
| Convierten el análisis en HTML autónomo. Una sola implementación, compartida por la web y la terminal. |
El servidor MCP |
| El enchufe con Claude. Expone las herramientas para que el modelo pueda llamarlas. |
Las herramientas | Trece funciones — tabla completa abajo | Lo que Claude puede hacer: resolver, detectar, listar reglas, renderizar cada documento. |
La skill |
| Lo que Claude debe saber: qué verificar antes de afirmar nada, qué documento pide cada situación, cómo redactar. |
El CLI |
| Los mismos tres documentos sin pasar por Claude. |
La web |
| Todo lo anterior en el navegador, sin instalar nada. |
Qué es MCP. El Model Context Protocol es un estándar abierto para que un modelo pueda
llamar a programas externos. Aquí el reparto es deliberado: el servidor aporta los
hechos, el modelo aporta el criterio. Por eso detectar_sinergias no devuelve prosa
cerrada, sino candidatas con su evidencia: los datos los pone el motor, la redacción y el
juicio los pone Claude.
Qué es la skill. Un archivo de instrucciones que Claude lee cuando la tarea lo pide. Si las herramientas le dan capacidad, la skill le da criterio: le prohíbe afirmar nada de memoria, le dice cuándo generar cada documento y cómo escribir los pasos. Funciona sin ella; con ella los análisis salen bastante mejor.
Qué necesitas según cómo lo uses
Si lo usas… | Te hace falta |
Desde la web | Nada — solo el navegador |
Desde la terminal | Python y el paquete |
Desde Claude | Python, el paquete y el conector MCP · la skill es opcional y recomendada |
Instalación
Elige el camino según cómo quieras usarlo. La web no requiere instalar nada; el resto depende de si quieres usarlo desde Claude o desde la terminal.
Quiero… | Ve a |
Probarlo ahora mismo, sin instalar | |
Pedírselo a Claude en lenguaje natural | |
Usarlo desde otro programa con soporte MCP | |
Generar los HTML desde la terminal |
Requisito previo (salvo para la web)
Todo lo demás necesita Python 3.10 o superior. La forma más cómoda de ejecutarlo es
con uv, que descarga y aísla el proyecto por ti sin que
tengas que crear entornos a mano:
curl -LsSf https://astral.sh/uv/install.sh | shEn macOS también vale brew install uv. Si prefieres no instalar uv, más abajo tienes
la alternativa con pip.
La web (nada que instalar)
https://grutino.github.io/mtg-forja/
Pegas la lista, pulsas Analizar mazo y sale el mapa. Desde ahí, los botones Guía y Chuleta generan los otros dos documentos. Todo ocurre en tu navegador; no se envía nada a ningún servidor salvo la consulta de cartas a Scryfall. Es la forma más rápida de ver si el proyecto te sirve.
Los archivos que descarga la web son exactamente los mismos que genera la línea de comandos: el mismo renderizador, incrustado en un HTML autónomo.
Claude Desktop
Abre el archivo de configuración de conectores:
macOS:
~/Library/Application Support/Claude/claude_desktop_config.jsonWindows:
%APPDATA%\Claude\claude_desktop_config.jsonLinux:
~/.config/Claude/claude_desktop_config.json
Si no existe, créalo con ese contenido. Si ya tienes otros conectores, añade solo la entrada
"mtg-forja"dentro delmcpServersque ya tengas.Pega esto:
{
"mcpServers": {
"mtg-forja": {
"command": "uvx",
"args": ["--from", "git+https://github.com/grutino/mtg-forja", "mtg-forja-mcp"],
"env": { "MTG_FORJA_SALIDA": "/ruta/donde/quieres/los/html" }
}
}
} Cambia /ruta/donde/quieres/los/html por una carpeta tuya real (por ejemplo
/Users/tunombre/Documents/mazos). Ahí es donde aparecerán los documentos generados.
Cierra Claude Desktop del todo y vuelve a abrirlo. No basta con cerrar la ventana.
Comprueba que ha cargado: en el icono de conectores debe aparecer
mtg-forjacon sus nueve herramientas. Si no sale, mira Si algo falla.Instala además la skill de
skill/SKILL.mdpara que Claude sepa cómo usar las herramientas: qué verificar, cómo redactar los pasos y cuándo generar cada documento. Sin ella funciona, pero con ella los textos salen bastante mejor.
Claude Code
Desde la terminal, en cualquier carpeta:
claude mcp add mtg-forja --scope user --env MTG_FORJA_SALIDA=/ruta/donde/quieres/los/html -- uvx --from git+https://github.com/grutino/mtg-forja mtg-forja-mcp--scope user lo deja disponible en todos tus proyectos. Si prefieres tenerlo solo en un
proyecto concreto, usa --scope project: se guardará en un .mcp.json en la raíz del
repositorio, que puedes commitear para que lo tenga todo tu equipo.
Ese .mcp.json es exactamente el mismo formato que el de Claude Desktop, así que también
puedes escribirlo a mano:
{
"mcpServers": {
"mtg-forja": {
"command": "uvx",
"args": ["--from", "git+https://github.com/grutino/mtg-forja", "mtg-forja-mcp"],
"env": { "MTG_FORJA_SALIDA": "/ruta/donde/quieres/los/html" }
}
}
}Otros clientes MCP
El servidor habla MCP sobre stdio, que es el transporte estándar. Sirve tal cual en cualquier programa que soporte MCP —Cursor, Windsurf, Zed, VS Code con una extensión compatible, LM Studio y demás—. Casi todos usan el mismo formato que Claude Desktop; si el tuyo pide los campos por separado, esta es la equivalencia:
Campo | Valor |
Transporte |
|
Comando |
|
Argumentos |
|
Variable de entorno |
|
Consulta la documentación de tu cliente para saber dónde vive su archivo de configuración;
el bloque mcpServers de arriba suele copiarse sin cambios.
Alternativa sin uv
Si no quieres instalar uv, instala el paquete en un entorno propio y apunta al ejecutable
por su ruta absoluta:
python3 -m venv ~/.venvs/mtg-forja
~/.venvs/mtg-forja/bin/pip install git+https://github.com/grutino/mtg-forjaY en la configuración, en lugar de uvx:
{
"mcpServers": {
"mtg-forja": {
"command": "/Users/tunombre/.venvs/mtg-forja/bin/mtg-forja-mcp",
"args": [],
"env": { "MTG_FORJA_SALIDA": "/ruta/donde/quieres/los/html" }
}
}
}Usa siempre la ruta absoluta: los clientes MCP no heredan tu PATH, y ese es el motivo
más común de que un servidor no arranque.
Línea de comandos
Sin instalar nada de forma permanente:
uvx --from git+https://github.com/grutino/mtg-forja mtg-forja mazo.txt -n "Mi mazo" -o salidaO instalándolo de una vez:
pip install git+https://github.com/grutino/mtg-forja
mtg-forja mazo.txt -n "Mi mazo" -o salidaGenera salida/guia.html, salida/chuleta.html y salida/mapa.html.
Cómo se usa
Desde Claude
Una vez instalado el conector, pídeselo en lenguaje natural y pégale la lista:
«Analiza este mazo y hazme el mapa y la chuleta: 4 Cleansing Wildfire 4 Cascading Cataracts …»
Claude resolverá las cartas contra Scryfall, buscará los patrones de interacción y
generará los HTML en la carpeta que pusiste en MTG_FORJA_SALIDA. Vale el formato de
exportación de MTG Arena, Moxfield, Archidekt, MTGO, el CSV de ManaBox, o una carta por línea.
Cosas que puedes pedirle, ya que las herramientas están separadas a propósito:
«¿Qué sinergias detecta este mazo?» — solo el análisis, sin generar documentos.
«Enséñame las reglas que conoce el motor» — el catálogo de patrones.
«Genérame solo la chuleta» — un único documento.
«¿Por qué dice que estas dos cartas se estorban?» — cada sinergia viene con la frase de oráculo exacta que la disparó, así que puedes auditar el razonamiento.
Desde la línea de comandos
mtg-forja mazo.txt -n "Mi mazo" -o salidaOpción | Qué hace |
| Archivo con la lista. Usa |
| Nombre del mazo, el que sale en los títulos. |
| Carpeta de destino. |
| Vuelca además el documento en JSON, por si quieres procesarlo tú. |
Abre los tres HTML en el navegador. Son autónomos: puedes moverlos, enviarlos por correo o imprimir la chuleta directamente desde el navegador.
Desde la web
Entra en https://grutino.github.io/mtg-forja/
Pega la lista, o pulsa Cargar ejemplo para ver cómo funciona con un mazo de prueba.
Pulsa Analizar mazo.
Pulsa cualquier carta del grafo para aislar sus conexiones; arrastra para recolocar, rueda del ratón para acercar y los botones de arriba para filtrar por función.
Los botones Guía y Chuleta, arriba a la derecha, abren esos documentos en una pestaña nueva. Guárdalos con Ctrl/Cmd + S, o imprime la chuleta directamente: está maquetada en A4 y sale bien del navegador sin tocar nada.
Si algo falla
Síntoma | Causa habitual |
El conector no aparece en Claude | No reiniciaste del todo la aplicación; ciérrala por completo y vuelve a abrirla. |
«command not found: uvx» en los logs |
|
El JSON no se acepta | Suele ser una coma de más o de menos. Pégalo en un validador de JSON. |
Los HTML no aparecen |
|
Una carta sale «sin resolver» | Revisa la grafía del nombre. Los acentos no importan, pero un nombre mal escrito sí. |
Las imágenes de carta tardan | Se piden a Scryfall según hacen falta. Con conexión lenta se ven en gris un momento. |
Herramientas MCP
Herramienta | Qué hace |
| Resuelve la lista contra Scryfall y devuelve el oráculo real. |
| Los hechos objetivos: a quién alcanza cada efecto, qué tipos menciona, qué zonas toca, y si el mazo tiene fuentes de color para lo que él mismo exige. |
| Busca patrones de interacción y devuelve candidatas con la frase de oráculo que disparó cada una. |
| Combos ya catalogados por Commander Spellbook, con sus pasos. Única fuente que no es oráculo verificado: hay que contrastarla. |
| Enseña los patrones que conoce el motor. |
| Generan cada HTML a partir del documento. |
| Atajo: hace todo de una pasada con los textos automáticos. |
El reparto es deliberado: el servidor aporta los hechos, el modelo aporta el criterio.
Por eso detectar_sinergias devuelve borradores con evidencia en lugar de prosa cerrada.
Cómo funciona el motor
src/mtg_forja/reglas.json es una lista de patrones genéricos de interacción. No sabe
nada de cartas concretas: describe formas. Por ejemplo, «una carta que destruye una tierra
y roba» más «una tierra indestructible» es una sinergia de rampa, se llamen como se llamen.
{
"id": "tierra-indestructible-cantrip",
"nombre": "Rampa y robo con tierra indestructible",
"fuerza": 3,
"piezas": [
{"rol": "a", "oracle": "destroy target land",
"oracle2": "search their library for a basic land", "oracle3": "draw a card"},
{"rol": "b", "tipo": "Land", "oracle": "indestructible"}
],
"resumen": "{a} apuntado a tu propia {b} no la destruye, pero…"
}Campos disponibles en cada pieza: oracle, oracle2, oracle3, no_oracle, tipo,
no_tipo, coste, mv_min, mv_max, copias_min, copias_max. A nivel de regla,
conteo permite condiciones sobre el mazo entero (basicas, tierras, total).
Añadir una regla es añadir un objeto a esa lista. Nada más. Se usa igual desde Python y desde el navegador, porque las dos mitades leen el mismo archivo.
La segunda capa: el léxico de recursos
Escribir una regla por cada pareja de cartas que interactúa no escala a treinta mil
naipes. Por eso hay un segundo motor que trabaja al revés: src/mtg_forja/lexico.json
no describe parejas, describe recursos. De cada carta deduce qué produce, qué premia
y qué rompe.
{
"id": "cementerio",
"nombre": "el cementerio",
"fuerza": 3,
"produce": {"oracle": ["\\bmills?\\b", "discard(s)? (a|your|two)"],
"no_oracle": "exile(s)? .{0,40}graveyard",
"texto": "llena tu cementerio"},
"premia": {"oracle": ["\\bDelve\\b", "cards? in your graveyard"],
"texto": "se alimenta del cementerio"},
"rompe": {"oracle": ["exile(s)? .{0,40}graveyard"],
"texto": "vacía los cementerios"}
}Las sinergias no se escriben, se deducen: si A produce un recurso y B lo premia, hay sinergia; si A lo rompe y B depende de él, hay conflicto. Un concepto cubre de golpe todas las parejas que lo compartan, así que el esfuerzo crece con las mecánicas del juego y no con el número de mazos. Hoy son 24 conceptos frente a 37 reglas escritas.
Cada bloque acepta los mismos campos que una pieza de regla (oracle, no_oracle, tipo,
no_tipo, mv_min, mv_max), y texto es lo que se lee en el resumen.
Dos cosas que se aprendieron a base de falsos positivos, y que el motor ya hace por ti: ignora el texto recordatorio entre paréntesis (el de retrospectiva de Snapcaster Mage dice «exile it» y la carta pasaba por odio al cementerio) y quita el nombre propio de la carta antes de analizar (Lightning Storm casaba con la mecánica Tormenta).
Hasta dónde llega cada camino
Conviene decirlo claro, porque determina qué esperar:
Camino | Alcance | Profundidad |
Reglas escritas ( | solo los arquetipos que alguien escribió | alta — ve asimetrías y casos raros |
Léxico de recursos ( | cualquier mazo | baja — solo flujos de recursos |
Modelo vía MCP | cualquier mazo | alta — es como se hizo el análisis original |
Las reglas escritas no salieron de un motor: salieron de un modelo leyendo el oráculo de cada carta y razonando, y luego alguien congeló esas conclusiones. Por eso ningún motor de patrones las reproduce. Comprobado: sobre el mazo que originó el proyecto, el léxico redescubre 1 de las 18 parejas escritas a mano.
Lo que ningún motor puede ver, y sí ve un modelo con el oráculo delante:
«apaga los artefactos del rival, pero no los tuyos» — requiere entender la asimetría
«el barrido no alcanza a tus planeswalkers» — requiere inferir qué queda fuera
«esa tierra solo es criatura cuando la activas, así que sobrevive» — estados temporales
«barajar descoloca la carta que pusiste arriba» — posición en la biblioteca
Por eso la herramienta radiografia_del_mazo existe: le da al modelo esos hechos —alcance,
tipos que menciona, zonas que toca— para que pueda razonar en vez de adivinar.
Si quieres el análisis bueno de un mazo que nadie ha visto, usa el camino MCP. El CLI y la web no tienen un modelo detrás; ahí el léxico sirve de suelo, para que un mazo desconocido nunca devuelva una página casi vacía.
¿Y las colecciones nuevas?
El léxico no describe cartas ni colecciones: describe recursos. Una carta nueva que llene el cementerio, haga fichas o premie a los dragones encaja en conceptos que ya existen, salga en la colección que salga.
Medido sobre 525 cartas reales de 2023 en adelante: el motor lee el 98 %. Lo que no entiende son equipos y auras que solo dan +X/+X, que apenas tienen señal de sinergia.
Lo que sí se escapa es una mecánica genuinamente nueva — Ferocious pide «controlas una criatura de fuerza 4 o más», y sin un concepto para eso un mazo entero se queda mudo. Suelen ser dos o tres por colección.
Para no depender de que alguien se dé cuenta:
python scripts/auditar_cobertura.py --minimo 25Pregunta a Scryfall qué mecánicas existen hoy, cuántas cartas usa cada una, y avisa de las que ningún concepto menciona. De las 371 del juego, 295 tienen menos de veinte cartas: son residuales de colecciones antiguas. Las que merecen un concepto son unas quince, y el guion las ordena por uso real.
Hay además una acción que lo ejecuta cada lunes y abre un aviso en el repositorio si aparece algo nuevo que se use de verdad.
Cómo saber si TU mazo está bien analizado
Un porcentaje de cobertura puede mentir. El caso real que lo enseñó: un mazo de dragones daba «100 %, el motor cubre las mecánicas de este mazo» mientras la carta que lo sostenía —una que abarata las criaturas con volar— aparecía en el mapa completamente suelta, sin una sola línea.
Las dos razones, y las dos están corregidas:
Volar estaba en la lista de «palabras de combate que no definen sinergias». Es cierto hasta que una carta se fija en ellas; entonces es el eje del mazo.
La mecánica Flurry («lanzas tu segundo hechizo del turno») no la etiqueta Scryfall como palabra clave, así que ningún recuento la veía. Y tiene menos de 25 cartas en todo Magic: la auditoría global tampoco la habría sacado nunca, aunque en ese mazo concreto fuera la mitad de la lista.
La lección es que contar mecánicas no mide comprensión. La señal que sí la mide es la que se ve de un vistazo en el mapa, y ahora sale también en el informe:
cartas_sin_relacion: ["Momo, Friendly Flier", ...]Si una carta importante del mazo sale ahí, falta un concepto. Es la comprobación que conviene hacer con cualquier mazo de una colección recién salida.
Cuando el mapa sale casi vacío
Un mazo blanco agresivo de los de siempre —Mother of Runes, Worship, Soltari, Rishadan Port— salía con cuatro líneas y casi todo suelto. Las tres cosas que faltaban dicen bastante de dónde falla un motor de patrones:
Carta | Por qué debía conectar |
| Busca «an artifact or enchantment card»: encuentra cinco cartas del mazo |
| «If you control a creature…» y el mazo lleva diecinueve |
| «Target creature you control gains protection» |
Ninguna era un caso raro: eran dependencias entre una carta y un tipo, y el motor solo sabía emparejar cartas con cartas. Ahora un tutor casa con lo que dice buscar —y solo con eso, nunca con una criatura— y un efecto que exige controlar una criatura casa con las criaturas que llevas.
El mazo pasa de 4 sinergias a 26, y las dos cartas que siguen sueltas son
Swords to Plowshares y Disenchant: removal puro, que en ese mazo de verdad no
se apoya en nada. Eso es lo que debe quedar suelto.
Tres fuentes que no somos nosotros
El motor deduce leyendo el oráculo con patrones propios. Eso es una sola opinión, y conviene contrastarla con quien no seamos nosotros:
Fuente | Qué aporta | Dónde falla |
Rulings oficiales | La regla escrita por Wizards. La mejor prueba que existe | Solo unas pocas cartas tienen rulings |
Etiquetas de Scryfall | Qué hace una carta, según quien la etiquetó: | Comunitario: puede faltar o sobrar |
Commander Spellbook | Combos catalogados con sus pasos | Solo Commander: ante un mazo de Legacy devuelve cero |
Las tres degradan sin romper nada: sin red, el análisis sigue.
Las etiquetas funcionales se consultan con el operador otag: de la API pública
de Scryfall, y valen sobre todo para ver lo que se nos escapa. Sobre el mazo de
Stiflenought:
drawback Phyrexian Dreadnought
phasing Vision Charm
pitch-spell Foil, Misdirection
counterspell Counterspell, Daze, Foil, Stifle, Thwartdrawback en Phyrexian Dreadnought es exactamente el concepto que habíamos escrito
a mano — dos fuentes independientes de acuerdo. Y pitch-spell señala un grupo que
el motor todavía no relaciona.
No hay catálogo público de etiquetas, así que se descubren probando:
python scripts/etiquetas_descubrir.pyUna advertencia que costó un bug: cuando una consulta falla, eso no es una
ausencia. Tragarse un 429 y dar la etiqueta por vacía convierte un fallo de red
en un dato, y el informe pasa a mentir con toda la confianza del mundo. Por eso
salen aparte, en etiquetas_sin_comprobar.
Lo que el contraste destapó al usarlo
La primera vez que se pasó el contraste por los cuatro mazos, marcó cinco parejas como «había con qué comprobarlo y no salió nada». Las cinco eran falsos positivos, y de dos clases:
Un peaje no es un recurso. Sage of the Skies tiene vínculo vital y
Sacred Foundry dice «paga 2 vidas o entra girada». Emparejarlos haría que
cualquier mazo con tierras de choque saliera unido a cualquier criatura con
lifelink. La vida como recurso es Necropotence, no un peaje de dos vidas en el
turno uno.
Sacrificarse a sí misma no llena el cementerio. El patrón cazaba cualquier
Sacrifice this, así que Maelstrom of the Spirit Dragon —que se sacrifica para
buscar un Dragón— salía emparejada con el flashback de Daydream. Esa tierra en el
cementerio no hace nada por Daydream, que llega ahí por lanzarse.
Ese segundo arreglo se llevó por delante, de una vez, las dos parejas del Stiflenought que ya sospechábamos a mano días antes. Después: 12 de 12 reforzadas y ninguna sospechosa.
La lección es sobre el contraste, no sobre las cartas: sirve porque cada aviso señala un sitio concreto donde mirar. Si se hubiera calibrado para que todo saliera verde, no habría encontrado nada.
Cuando la comunidad ve algo que el motor no
Demonic Consultation + Thassa's Oracle gana la partida en el sitio y es de los
combos más conocidos que existen. El motor no lo deduce: hace falta saber que
vaciarte la biblioteca convierte el disparo del Oráculo en victoria, y eso no está
escrito en ninguna de las dos cartas.
El catálogo sí lo sabe. Así que entra en los documentos, marcado como venido de la comunidad y con fuerza 5, por encima de lo que deduce el motor:
mtg-forja mazo.txt # consulta el catálogo
mtg-forja mazo.txt --sin-combos # no lo consultaSolo entran los combos completos —todas sus piezas dentro del mazo—. Los
casi_completos nombran cartas que no llevas: son sugerencias de construcción, y
dibujarían líneas hacia cartas que no existen en la lista.
Dos límites que conviene tener claros:
La web no puede. La API del catálogo no envía cabeceras CORS, así que el navegador bloquea la petición. Por eso los combos entran solo por la línea de comandos y por MCP. El motor sigue siendo idéntico en los dos sitios —la prueba de paridad lo vigila sobre cuatro mazos—, pero la terminal consulta una fuente extra que el navegador no alcanza.
El mapa no los distingue del todo. La guía y la chuleta llevan el aviso de que esa jugada no sale del oráculo; en el mapa, la evidencia que se muestra por carta es la de la primera sinergia que la menciona, así que a veces enseña el texto de oráculo en vez de la procedencia. Está pendiente darle a esas líneas un estilo propio.
La comunidad manda
Hay un orden de precedencia, y el motor está el último:
Un ruling oficial. Es la regla escrita por Wizards. Si contradice una sinergia detectada, se descarta la sinergia.
Un combo catalogado por la comunidad. Son jugadas que alguien ha visto funcionar en una mesa. Si el catálogo une dos cartas del mazo y el motor no, el hueco es nuestro: sale en
la_comunidad_ve_lo_que_nosotros_noy cuenta como sinergia aunque no aparezca en el mapa.Lo que deduce el motor. Lo último, y solo cuando nadie más ha hablado.
Por eso cada pareja detectada sale con veredicto: reforzada por ruling oficial,
reforzada por etiquetas, o sin apoyo. Y el campo que más conviene mirar es
sin_apoyo_pero_comprobables: parejas donde sí había con qué contrastar y no
salió nada. Sobre el mazo de Stiflenought señala dos, y son exactamente las dos
que ya sospechábamos a mano.
Distinguir «nadie lo ha comprobado» de «nadie lo respalda» es la mitad del valor:
un concepto sin etiqueta equivalente no es sospechoso, es que no hay por dónde
mirarlo. Forzar el mapeo para que todo salga verde destruiría el aviso — un premio
tribal no es un lord, así que ese concepto no se mapea y punto.
Pagar un hechizo con algo que no es maná
Además de las tierras, hay 80 cartas cuyo coste alternativo se cobra en otra
moneda: sacrificar criaturas (Delraich, Demon of Death's Gate), taparlas
(el ciclo de Masques), exiliar cartas de la mano, pagar vida.
El motor empareja cada una con lo que su texto dice que se lleva por delante, no con cualquier permanente: un coste que pide criaturas no se paga con un artefacto.
Una regla escrita mirando una carta
Daze devuelve una Isla para lanzarse gratis, y había una regla para eso. Decía
literalmente return an Island, así que en un mazo con cuatro hechizos de esa
familia solo enseñaba uno: Gush devuelve dos Islas, Thwart tres, y
Foil la descarta en vez de devolverla.
Preguntando a Scryfall salen 32 cartas con costes que se pagan con tierras, y
es un ciclo por los cinco colores con tres verbos: devolver, descartar y
sacrificar —Fireblast sacrifica dos Montañas, Abolish descarta un Llano—.
Generalizarla como regla escrita no valía: allí el tipo de la segunda pieza va
fijo, así que habría emparejado Foil con una Montaña. Pasa a ser concepto del
léxico, que sí casa por subtipo: cada hechizo con la tierra que de verdad nombra.
La moraleja se repite tanto que conviene decirla: una regla escrita mirando una carta describe esa carta, no el efecto. El singular, el verbo concreto y el tipo fijo son las tres formas de que se note.
Compartir etiqueta no es tener sinergia
Es la trampa más fácil de esta fuente, y estuve a punto de caer en ella.
Foil y Misdirection comparten otag:pitch-spell, así que parece que van
juntas. No van: esa etiqueta las clasifica, igual que agrupa a Counterspell
con Daze. De hecho compiten — las dos se pagan con cartas de la mano, el mismo
recurso, y por eso el mazo lleva una Misdirection y no cuatro.
Ninguna otra fuente las une tampoco: Misdirection tiene cuatro rulings y ninguno menciona nada parecido, y Commander Spellbook no devuelve nada.
Lo que sí es una sinergia estaba al lado, y es de otra clase:
Gush → "return two Islands you control to their owner's hand"
Foil → "discard an Island card ... rather than pay this spell's mana cost"Gush te pone Islas en la mano; Foil necesita descartar una Isla de la mano para lanzarse gratis. Gush paga literalmente el coste de Foil, y eso también vale para Daze y Thwart, que devuelven Islas igual.
La diferencia importa y da la regla general: una categoría agrupa cartas que se parecen; una sinergia es un recurso que pasa de una carta a otra. Convertir categorías en líneas es exactamente cómo Misdirection acabó con nueve conexiones que no significaban nada.
Por eso las etiquetas se usan para buscar dónde mirar, nunca como sinergia directa. Señalaron el sitio correcto por el motivo equivocado, y eso ya es útil.
Contrastar contra la fuente oficial
Un combo conocido desde hace veinte años no debería costar deducirlo. Y no hace falta: suele estar explicado en el ruling oficial de la propia carta, que es la mejor prueba que existe — no es la opinión de nadie, es la regla.
Los rulings de Phyrexian Dreadnought documentan las dos mitades del combo:
«Reverted to its original wording, this now has an "enters" triggered ability.» — por eso Stifle lo contrarresta
«Phasing in does not trigger "enters" abilities, so you don't have to sacrifice again if it phases in.» — por eso Vision Charm funciona
Por eso hay una herramienta que coge las sinergias detectadas y busca qué dice Wizards sobre ellas. Sobre ese mazo respalda las dos piezas del combo.
Dos avisos, porque importan:
Empareja por vocabulario, así que señala rulings relacionados. No demuestra la jugada: la lee un humano —o el modelo, por MCP— y decide.
Que una pareja no traiga apoyo no la vuelve falsa. La mayoría de las cartas apenas tienen rulings, y la ausencia no dice nada.
Si un ruling contradice una sinergia detectada, gana el ruling.
Por qué no vale Commander Spellbook aquí. Ya está integrada y es buena, pero es una base de datos de Commander: preguntada por este mazo de Legacy devuelve cero. Los rulings, en cambio, no saben de formatos.
No todo disparo al entrar es bueno
Phyrexian Dreadnought es un 12/12 por {1} con una letra pequeña: al entrar,
lo sacrificas salvo que sacrifiques doce puntos de fuerza. El mazo entero existe
para cancelar ese disparo — Stifle lo contrarresta, Vision Charm hace
desvanecerse el artefacto — y el motor no encontraba ninguna de las dos.
La razón de fondo: daba por hecho que un disparo al entrar es valor. Aquí es un lastre. Ahora hay un concepto para el disparo que te cobra un precio y para quien lo neutraliza, y el emparejado por tipo sabe quién apunta a quién: en un tutor apunta el que busca, en una respuesta apunta el que contesta. Por eso Vision Charm solo vale contra un artefacto, que es lo único que puede hacer desvanecerse.
Una carta cualquiera no es una sinergia
En ese mismo mazo, Misdirection salía como el nudo principal con nueve
conexiones. Se lanza exiliando «a blue card», y en un mazo monoazul eso lo cumplen
las quince cartas: nueve líneas para decir que el mazo es azul.
El consejo que sí vale —cada uso te cuesta dos cartas— habla de Misdirection sola. No es una pareja, así que ahora es una nota de una carta y no dibuja ninguna línea. Un mapa donde una carta conecta con todo no dice nada de ninguna.
Una jugada imposible no es una jugada floja
En el mazo de dragones salía Daydream emparejado con Seam Rip. El razonamiento
del motor era correcto por separado y absurdo junto: «Daydream vuelve a meter
permanentes en juego» más «Seam Rip tiene un disparo al entrar».
Lo que nunca comprobó es si Daydream puede apuntarla. Dice «exile target creature you control», y Seam Rip es un encantamiento.
Ahora un efecto solo alcanza a los tipos que su propio texto dice alcanzar:
El texto dice | Llega a |
| criaturas |
| todo menos tierras |
| todo |
no nombra ningún tipo | todo — no se puede afirmar, y callar una sinergia real es peor |
La misma comprobación sirve para los tutores, que solo encuentran lo que dicen buscar. Daydream conserva sus tres criaturas con disparo al entrar y pierde el encantamiento.
Un aviso falso es peor que ningún aviso
La regla «doble símbolo de color con tierras incoloras» decía solo produce
incoloro pero nunca comprobaba lo de solo. Maelstrom of the Spirit Dragon
dice «Add {C}», y también «{T}: Add one mana of any color» sin coste extra, para
pagar dragones. El motor avisaba contra los tres dragones a los que esa tierra
existe justo para lanzar.
Salió a la luz al emitir todas las parejas: pasó de una línea roja a tres, y tres
ya cantaban. Ahora la regla exige que la tierra no produzca color gratis. El aviso
legítimo sigue: Cascading Cataracts cobra {5} por el color, así que en los
primeros turnos es incolora de verdad.
Una regla, todas las cartas que encajen
Las reglas escritas a mano ya eran genéricas —«cualquier tierra indestructible», no una carta concreta— pero el motor emitía una sola pareja por regla: elegía la carta más representativa del papel y descartaba el resto.
En el mazo de ejemplo hay dos tierras indestructibles. Cascading Cataracts se llevaba la única línea y Rustvale Bridge, de la que van cuatro copias, colgaba suelto en el mapa pese a hacer exactamente la misma jugada:
Apuntas
Cleansing Wildfirea tu propia tierra indestructible. No se destruye, pero el objetivo sigue siendo legal: buscas la básica y robas igualmente.
Ahora una regla emite todas las combinaciones que encajen, con un tope de doce por regla para que una laxa no llene el mapa. Es el mismo arreglo que ya se hizo en el léxico cuando una carta eje aparecía con dos de sus seis compañeros.
La trampa de las palabras clave
El texto entre paréntesis de una carta —el recordatorio— se descarta antes de analizarla, porque repite reglas genéricas y disparaba falsos positivos. El precio es sutil: en una mecánica con nombre, el significado vive justo ahí.
Voice of Victory dice «Mobilize 2», y todo lo demás —que crea dos fichas de
criatura al atacar— está en el recordatorio. El motor veía una palabra sin
contenido, y una carta de la que llevas cuatro copias colgaba de un solo hilo.
Por eso los conceptos reconocen también el nombre de la mecánica, no solo su
efecto redactado: Mobilize, Amass, Fabricate, Populate, Ferocious,
Flurry. Es la forma de que una palabra clave nueva entre con una línea de más.
No todas merecen concepto, y decir que no también es una decisión:
Mecánica | ¿Concepto? | Por qué |
| Sí | Crea fichas de criatura: recurso claro |
| No | Solo se relanza a sí misma. Meterla inventaría relaciones de «parpadeo tus permanentes» que no existen |
| No | Pagar más por más de lo mismo, no un recurso que otra carta aproveche |
Dos límites que conviene conocer
El motor solo encuentra lo que se le ha enseñado. Si analizas un mazo y salen dos
sinergias, casi nunca es un fallo de resolución: es que el paquete no cubre ese
arquetipo todavía. Para comprobarlo, mira cartas_sin_resolver en la salida — si viene
vacío, las cartas se leyeron bien y lo que falta son patrones. Escribir la regla que
falta es el trabajo, y es el trabajo que hace crecer esto.
El banquillo no entra en la detección. Las cartas de reserva se resuelven contra Scryfall y aparecen en el documento, pero las reglas solo cruzan el mazo principal. Una sinergia que dependa de una carta del banquillo no se detecta.
Después de tocar reglas.json, lexico.json, grafo.css o cualquiera de los
renderizadores .js, sincroniza la web:
python scripts/sync_docs.pyMontarlo entero en tu máquina
Si quieres tenerlo todo funcionando en local —la web, la línea de comandos y el servidor MCP— sin depender de GitHub Pages, estos son los pasos completos.
Requisitos previos
Necesitas | Para qué | Cómo comprobar que lo tienes |
Python 3.10 o superior | El motor, el CLI y el servidor MCP |
|
git | Clonar el repositorio |
|
Un navegador | Ver la web y los documentos | Cualquiera moderno |
Conexión a internet | Consultar cartas e imágenes en Scryfall | — |
No hace falta Node, ni npm, ni ningún servidor: la web es HTML y JavaScript estáticos, y
el único servidor que se levanta es el que trae Python de serie. Tampoco hace falta uv
para esto; uv solo simplifica el arranque del conector MCP.
Sobre la conexión: aunque todo corra en tu máquina, los nombres de carta y las imágenes se piden a Scryfall. Sin internet, el motor no puede resolver el mazo. Para trabajar sin red existe
MTG_FORJA_FIXTURE, pensado para las pruebas.
Paso 1 — Clonar e instalar
git clone https://github.com/grutino/mtg-forja
cd mtg-forja
python3 -m venv .venv
source .venv/bin/activate
pip install -e .En Windows, la tercera y cuarta línea son py -m venv .venv y .venv\Scripts\activate.
El
-einstala en modo editable: si tocas el código, no hay que reinstalar. Si usas conda, crea igualmente elvenv: mezclar ambos da problemas.
Paso 2 — Comprobar que funciona
pip install pytest
pytest -qDeben pasar las pruebas, y no tocan la red: usan el fixture de ejemplos/. Si fallan
aquí, no sigas: algo está mal en la instalación, no en tu mazo.
Ahora una prueba de verdad, contra Scryfall:
mtg-forja ejemplos/prueba.txt -n "Prueba" -o /tmp/forja-pruebaDebe imprimir un resumen del tipo 30 cartas · 15 sinergias y dejar tres HTML en
/tmp/forja-prueba. Ábrelos en el navegador.
Hay un segundo mazo de ejemplo, uno real de 60 cartas —Boros de dragones— que es el que destapó dos fallos de bulto y ahora vive aquí como regresión:
mtg-forja ejemplos/dragones-boros.txt -n "Dragones Boros" -o /tmp/forja-dragonesSalen 60 cartas · 28 sinergias. Trae su propio fixture, así que también corre sin red:
MTG_FORJA_FIXTURE=ejemplos/fixture-dragones.json mtg-forja ejemplos/dragones-boros.txt -o /tmp/salidaPaso 3 — Levantar la web en local
python scripts/sync_docs.py
python -m http.server -d docs 8000Y abre http://localhost:8000.
Eso es todo: ya tienes la web completa —mapa, guía y chuleta— corriendo en tu máquina, sin
pasar por GitHub. sync_docs.py copia a docs/ el paquete de reglas y los renderizadores
que comparten las dos mitades del proyecto; ejecútalo siempre que toques reglas.json o
cualquiera de los .js de src/mtg_forja/render/, o la web se quedará con la versión
vieja.
Para parar el servidor, Ctrl + C.
Paso 4 (opcional) — Conectar tu Claude a esta copia local
Si quieres que Claude use tu copia en lugar de descargarla de GitHub, apunta el conector al ejecutable de tu entorno virtual, con ruta absoluta:
{
"mcpServers": {
"mtg-forja": {
"command": "/ruta/completa/a/mtg-forja/.venv/bin/mtg-forja-mcp",
"args": [],
"env": { "MTG_FORJA_SALIDA": "/ruta/donde/quieres/los/html" }
}
}
}Averigua la ruta exacta con which mtg-forja-mcp (con el entorno activado). En Windows es
.venv\Scripts\mtg-forja-mcp.exe. Así los cambios que hagas en el código los ve Claude en
cuanto reinicies la aplicación.
Resumen
git clone https://github.com/grutino/mtg-forja && cd mtg-forja
python3 -m venv .venv && source .venv/bin/activate
pip install -e . pytest
pytest -q # 16 pruebas, sin red
python scripts/sync_docs.py # sincroniza reglas y renderizadores
python -m http.server -d docs 8000 # web completa en localhost:8000Desarrollo
# prueba sin red, con el fixture de ejemplo
MTG_FORJA_FIXTURE=ejemplos/fixture-pruebas.json mtg-forja ejemplos/prueba.txt -o /tmp/salidaVariables de entorno:
| Dónde cachear las cartas (por defecto |
| Carpeta por defecto de los HTML del servidor MCP. |
| Archivo JSON de cartas para trabajar sin red, en pruebas. |
Publicar la web
En los ajustes del repositorio, Pages → Source: Deploy from a branch → main / docs.
Estructura
src/mtg_forja/
modelo.py cartas, mazo, parseo de listas (Arena, Moxfield, Archidekt, ManaBox…)
scryfall.py resolución con caché en disco y modo sin red
reglas.json patrones escritos a mano — parejas concretas de cartas
reglas.py motor de detección de esos patrones
lexico.json conceptos de recurso — aquí es donde se crece de verdad
lexico.py motor deductivo: cruza productores con premiadores
hechos.py radiografía objetiva del mazo (alcance, zonas, base de maná)
combos.py cliente de Commander Spellbook, con caché y degradación limpia
render/
comun.js paleta y utilidades compartidas
guia.js \
chuleta.js > el diseño de los tres documentos, en una sola implementación
grafo.js /
grafo.css estilos del mapa, compartidos con la web
guia.py \
chuleta.py > cáscaras: incrustan el JS y el documento en un HTML autónomo
mapa.py /
server.py servidor MCP — las nueve herramientas
cli.py línea de comandos
docs/ web de GitHub Pages (lee los mismos datos y renderizadores)
docs/motor.js gemelo en JavaScript de modelo + scryfall + reglas + lexico
docs/capturas/ las imágenes de este README
skill/SKILL.md cómo debe usar Claude todo lo anterior
tests/ 16 pruebas, todas sin redLos renderizadores no están duplicados. El diseño de cada documento existe una sola
vez, en su .js. Python no lo reimplementa: incrusta ese archivo junto al documento en
JSON y deja que el navegador lo pinte. Por eso la web y la línea de comandos producen el
mismo archivo, byte a byte, y no pueden separarse con el tiempo. sync_docs.py es lo que
mantiene docs/ al día.
Por qué no hay más fuentes
Se probaron, una por una, y estos son los resultados reales:
Fuente | Qué se encontró |
Commander Spellbook | ✅ Integrada. Su endpoint |
Gatherer | Sin API propia, pero su contenido ya llega por Scryfall: los rulings oficiales. Es la fuente que más aporta y ya está integrada |
EDHREC | Su JSON funciona, pero mide popularidad, no interacción. Y su página |
Moxfield | Devuelve |
MTGGoldfish | Sin API y con |
Draftsim | Su |
TCGplayer | La API pide clave de socio, y da precios |
Cardmarket |
|
MTGSimilar | Protección anti-bot |
Untapped.gg | Su API devuelve |
edh-combos.com | La más abierta de todas — |
Archidekt · ManaBox | Almacenan mazos. Valen como formato de importación, y ya se soportan |
La conclusión, tras revisarlas una a una: solo dos aportan algo, y las dos están dentro. Scryfall pone el oráculo real y los rulings oficiales de Wizards; Commander Spellbook pone los combos ya catalogados. El resto son precios, popularidad, listas de mazos o —como edh-combos.com— reempaquetados de las anteriores.
Ninguna se descartó por estar cerrada sin más: se descartaron porque no responden a esta pregunta. Entender por qué dos cartas interactúan exige leer lo que dicen, y eso solo lo dan el texto de la carta y las aclaraciones de quien escribe las reglas.
Créditos y licencia
Código bajo licencia MIT, en LICENSE.
Los datos y las imágenes de carta vienen de la API pública de Scryfall y se enlazan, no se copian; las capturas de este README son la excepción, por necesidad. Magic: The Gathering es propiedad de Wizards of the Coast. Este es un proyecto de aficionado sin ánimo de lucro, amparado por la Fan Content Policy de Wizards, y no está patrocinado ni respaldado por Wizards ni por Scryfall.
Los combos catalogados de combos_conocidos vienen de
Commander Spellbook, curados por su comunidad.
No están afiliados a este proyecto. Si construyes sobre esto, cítalos.
Si usas la API de Scryfall en tu propio despliegue, respeta su
ritmo de peticiones (una cada 50-100 ms). Con
Commander Spellbook, combos.py hace una sola petición por mazo y la cachea en
disco; su robots.txt desaconseja rastrear el backend, así que no lo conviertas en un
bucle. Ninguna de las dos requiere clave.
Available Tools
9 toolsanalizarA
Atajo: resuelve, detecta y genera los tres HTML con los textos automáticos.
Útil para una primera pasada rápida. Para un resultado bueno de verdad,
encadena detectar_sinergias → reescribes el documento → los tres render_*.
| Name | Required | Description | Default |
|---|---|---|---|
| ruta | No | ||
| lista | Yes | ||
| nombre | No | Mazo |
Output Schema
| Name | Required | Description |
|---|---|---|
| result | Yes |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Al no haber anotaciones, la descripción asume la responsabilidad y comunica que es un atajo que genera textos automáticos con calidad limitada, y recomienda el flujo manual para mejores resultados. No detalla efectos secundarios ni permisos, pero la advertencia de uso aporta contexto conductual relevante.
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?
El texto es breve y eficaz: una frase para el propósito, otra para el uso recomendado y una tercera para la alternativa. No hay relleno ni repeticiones.
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?
Aporta contexto de flujo y limitación, pero omite la semántica de los parámetros y los detalles concretos de lo que hace 'resolver/detectar'. Dado que hay un parámetro requerido sin documentar, el agente no tiene lo necesario para invocar la herramienta con seguridad.
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?
La cobertura del esquema es 0% y la descripción no menciona los parámetros 'lista', 'ruta' ni 'nombre'. Un agente no puede inferir qué significan ni cómo usarlos, por lo que la descripción no compensa en absoluto la falta de información.
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?
La descripción usa verbos concretos ('resuelve, detecta y genera los tres HTML') y se distingue de los hermanos al presentarse como un atajo que combina detectar_sinergias y los render_*. Aunque 'resuelve' es algo vago, el recurso y la acción principal están claros.
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?
Indica explícitamente cuándo usarlo ('primera pasada rápida') y ofrece una alternativa concreta: encadenar detectar_sinergias, reescribir y los tres render_*. Esto cumple completamente la dimensión.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
combos_conocidosA
Combos ya catalogados que hay en el mazo, según Commander Spellbook.
Devuelve los combos completos (todas las piezas están en el mazo) y los casi completos (falta una carta, que se indica), cada uno con las cartas implicadas, qué produce y los pasos redactados.
⚠️ Esto no es texto de oráculo verificado. Es una base curada por una comunidad, y es la única herramienta de este servidor cuyos datos no salen de Scryfall. Antes de meter cualquiera de estos combos en un documento:
Comprueba con
resolver_mazooradiografia_del_mazoque las cartas hacen de verdad lo que el combo dice.Si el oráculo real no sostiene los pasos, descarta el combo.
Cuando lo uses, cita Commander Spellbook como fuente.
Complementa al motor de patrones: aquí salen combos con nombre propio que
nadie ha escrito en reglas.json, y que el léxico de recursos no puede
deducir porque requieren razonar sobre reglas del juego.
| Name | Required | Description | Default |
|---|---|---|---|
| lista | Yes | ||
| nombre | No | Mazo |
Output Schema
| Name | Required | Description |
|---|---|---|
| result | Yes |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Sin anotaciones, la descripción explica que los datos no son texto de oráculo verificado, provienen de una curación comunitaria y son la única fuente no Scryfall del servidor. También detalla el contenido de la respuesta (combos completos y casi completos), lo que aporta transparencia sobre la fiabilidad y estructura de los datos.
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?
La descripción es clara y estructurada: comienza con el propósito, luego las advertencias y finalmente el contexto complementario. Cada oración aporta información relevante; el uso de listas numeradas facilita la lectura.
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?
Dado que existe un esquema de salida, la descripción no necesita detallar la estructura de retorno, pero sí ofrece contexto sobre la fuente, la advertencia de verificación y el rol frente a otras herramientas. Cubre adecuadamente aspectos clave aunque no profundiza en el formato de entrada.
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?
El esquema tiene 0% de cobertura de descripciones. La descripción no explica los parámetros `lista` ni `nombre`. Solo se infiere que `lista` se refiere al mazo por la frase 'en el mazo', pero no se detalla el formato ni el propósito de `nombre`, dejando una brecha importante.
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?
La descripción indica claramente que devuelve combos catalogados según Commander Spellbook, diferenciando completos y casi completos, con cartas implicadas, qué produce y pasos redactados. Se distingue de herramientas hermanas como resolver_mazo o radiografia_del_mazo al señalar que complementa al motor de patrones.
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?
Ofrece pautas explícitas: sugiere verificar con resolver_mazo o radiografia_del_mazo antes de usar los resultados, y menciona que es complementaria al motor de patrones, indicando cuándo usar esta herramienta frente a alternativas.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
detectar_sinergiasA
Resuelve el mazo y busca patrones de interacción entre sus cartas.
Devuelve un documento con las cartas, la curva y las sinergias candidatas.
Cada candidata incluye evidencia: la frase del oráculo que ha disparado la
regla. Trátalas como borrador — reescribe títulos, resúmenes y pasos con tu
propio criterio, descarta las que no apliquen y añade las que el motor no vea.
| Name | Required | Description | Default |
|---|---|---|---|
| lista | Yes | ||
| nombre | No | Mazo |
Output Schema
| Name | Required | Description |
|---|---|---|
| result | Yes |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden of behavioral disclosure. It is transparent about the output being a draft ('Trátalas como borrador'), includes an `evidencia` field, and admits the engine may miss synergies ('añade las que el motor no vea'). This adds significant context beyond a bare summary, though it does not mention potential side effects or permissions.
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 efficient and structured: it states the function, the return document, and the draft nature of results in three sentences. Each sentence adds value, though the phrase 'Resuelve el mazo' could be more precise.
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 coverage is partial: it explains output structure and behavior but lacks parameter guidance and explicit usage differentiation from sibling tools. The presence of an output schema reduces the need to describe return values, but the required `lista` parameter is left undefined, making the tool somewhat less complete for an agent.
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 coverage is 0%, and the description does not explain either parameter (`lista` and `nombre`). The tool's purpose implies `lista` is a deck list, but the description fails to state what to pass for `lista` or how `nombre` is used, leaving the agent without essential 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 clearly states the tool's function: 'Resuelve el mazo y busca patrones de interacción entre sus cartas' (solves the deck and looks for interaction patterns). It also specifies the output (a document with cards, curve, and candidate synergies), which distinguishes it from siblings like 'combos_conocidos' by emphasizing candidate discovery over known combos.
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 implies usage context: it is a draft generator for synergy candidates, telling the user to rewrite, discard, or add synergies. However, it does not explicitly name alternatives or exclude scenarios, leaving the choice between this and sibling tools like 'combos_conocidos' or 'analizar' unaddressed.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
listar_reglasA
Lista los patrones de interacción que conoce el motor, con su id y qué buscan.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Output Schema
| Name | Required | Description |
|---|---|---|
| result | Yes |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It implicitly indicates a read-only listing operation and discloses the return fields (id and what patterns look for), but it does not explicitly state side effects, pagination, or any prerequisites. For a simple list tool, this is adequate but not rich.
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, well-structured sentence that is front-loaded with the action verb and resource. No unnecessary words or repetition.
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 simple zero-parameter listing tool with an output schema, the description covers the essential behavior and return content. It lacks deeper context such as when to use it or what 'patrones de interacción' implies, but given the low complexity, it is sufficiently complete.
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?
The tool has zero parameters, so there is nothing to explain. The schema coverage is 100% and the description adds no parameter-related information, which is acceptable. Baseline for 0-param tools is 4.
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 specific verb ('Lista') and identifies the resource ('patrones de interacción que conoce el motor'), and specifies the output contents ('con su id y qué buscan'). It is clear and distinct from the sibling tools, though it does not explicitly contrast with them.
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?
There is no guidance on when to use this tool versus the sibling tools. The description only states what the tool does, not in which context it should be preferred over alternatives like combos_conocidos or detectar_sinergias.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
radiografia_del_mazoA
Los hechos objetivos del mazo, para razonar sobre datos y no de memoria.
Úsala ANTES de escribir el análisis, junto con detectar_sinergias. Devuelve,
para cada carta, el oráculo real y unas señales comprobables:
alcance— si el efecto es simétrico, asimétrico, solo tuyo o solo del rival. Es lo que distingue «barre la mesa» de «apaga lo suyo pero no lo tuyo».tipos_que_menciona— para ver qué NO alcanza un efecto: un barrido de criaturas deja vivos los planeswalkers.zonas_que_tocayvelocidad— para razonar sobre secuencias y respuestas.
Y a nivel de mazo: curva, reparto por tipo, copias únicas, y si hay fuentes de color suficientes para lo que el propio mazo exige.
Estas son las piezas con las que se hace un análisis bueno de un mazo que nadie ha visto antes. El motor de patrones solo encuentra lo que ya estaba escrito; aquí tienes los hechos para ver el resto tú.
| Name | Required | Description | Default |
|---|---|---|---|
| lista | Yes | ||
| nombre | No | Mazo |
Output Schema
| Name | Required | Description |
|---|---|---|
| result | Yes |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It discloses the nature of output (objective facts, not interpretations), the specific per-card fields, and deck-level aggregations. It also notes that the pattern engine only finds existing written patterns, implying this tool provides novel data. However, it does not mention input format validation, error behavior, or performance characteristics.
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?
Front-loaded with the core purpose, uses clear bullet points for output details, and each sentence adds value. It is well-structured for the complexity and not overly verbose.
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?
Given there is an output schema (not shown), the description thoroughly covers the conceptual output: per-card signals and deck-level stats. It also positions the tool within the sibling set. However, it omits input format prerequisites and potential edge cases (e.g., malformed deck lists), leaving a minor gap.
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 has 2 parameters with 0% description coverage. The description does not explain the expected format for 'lista' or the purpose of 'nombre'. It implies 'lista' is a deck list via 'para cada carta', but lacks explicit parameter semantics, syntax, or examples.
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 clearly states the tool provides objective deck facts: per-card oracle text and verifiable signals (alcance, tipos_que_menciona, zonas_que_toca, velocidad), plus deck-level stats. It distinguishes itself from pattern-based tools by positioning this as raw data for reasoning, not pre-computed patterns.
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?
Explicitly instructs to use 'ANTES de escribir el análisis' and 'junto con detectar_sinergias', giving a clear when-to-use. It also contrasts with the 'motor de patrones' (likely combos_conocidos) to clarify that this tool provides facts while the pattern engine finds already-known patterns.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
render_chuletaC
Genera la chuleta imprimible de dos caras A4. Devuelve la ruta del archivo.
| Name | Required | Description | Default |
|---|---|---|---|
| ruta | No | ||
| documento | Yes |
Output Schema
| Name | Required | Description |
|---|---|---|
| result | Yes |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description explicitly states the return value ('Devuelve la ruta del archivo'), which provides some behavioral transparency. However, there are no annotations, so the description must fully disclose side effects and prerequisites. It does not mention whether a file is written to disk, whether existing files are overwritten, or any access or formatting requirements, leaving significant gaps.
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 that is concise and front-loaded. It immediately states the action and the return value with no redundant phrasing or unnecessary details, achieving maximum efficiency for its length.
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?
While the tool is relatively simple, the description fails to explain the two parameters or any usage context. The output schema is indicated as existing, but the description still must clarify parameters and prerequisites, which it does not. This leaves the tool under-specified for reliable invocation.
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?
The input schema has two parameters ('ruta' and 'documento') with 0% schema description coverage. The description does not explain the purpose or acceptable values for either parameter, leaving the agent to guess that 'documento' is the source document and 'ruta' is the output path. This is a critical omission for parameter understanding.
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 clearly states the tool generates a double-sided A4 printable cheat sheet and returns the file path. The verb 'Genera' and specific resource 'chuleta imprimible de dos caras A4' make the core function clear. However, it does not distinguish this from sibling tools like render_guia or render_mapa, which likely have overlapping functionality.
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 guidance is provided on when to use this tool versus alternatives such as render_guia or render_mapa. There are no described prerequisites, input requirements, or scenarios where this tool is preferred. The description only explains what it does, not when to use it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
render_guiaA
Genera la guía extensa en HTML a partir de un documento de análisis.
documento es el JSON de detectar_sinergias, idealmente ya reescrito por ti.
Devuelve la ruta del archivo creado.
| Name | Required | Description | Default |
|---|---|---|---|
| ruta | No | ||
| documento | Yes |
Output Schema
| Name | Required | Description |
|---|---|---|
| result | Yes |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the behavioral burden. It does state the return value ('Devuelve la ruta del archivo creado') and the input format, which is valuable. It does not detail side effects or error behaviors, but the key behavioral trait (output file path) is disclosed.
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 only two sentences, front-loaded with the main action, and includes essential details about input and output without wasted words.
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 an output schema (per context signals), the description sufficiently covers the purpose, input, and return value. The missing explanation of `ruta` is a minor gap, but overall the description is adequate given the tool's simplicity and the presence of an output schema.
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?
The description explains the main parameter `documento` as 'el JSON de `detectar_sinergias`', which is crucial. However, the `ruta` parameter is completely unexplained, and schema description coverage is 0%, so the description does not fully compensate for the lack of parameter documentation.
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 clearly states the tool's purpose: 'Genera la guía extensa en HTML a partir de un documento de análisis.' It uses a specific verb (genera) and resource (guía extensa en HTML), and distinguishes from sibling render tools by noting the input from detectar_sinergias.
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 provides context on when to use the tool by referring to the JSON from detectar_sinergias and suggesting the document should be 'idealmente ya reescrito por ti'. However, it does not explicitly compare to alternatives like render_chuleta or render_mapa, so usage guidance is clear but lacks exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
render_mapaC
Genera el mapa interactivo de sinergias. Devuelve la ruta del archivo.
| Name | Required | Description | Default |
|---|---|---|---|
| ruta | No | ||
| documento | Yes |
Output Schema
| Name | Required | Description |
|---|---|---|
| result | Yes |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are present, so the description is the only source of behavioral information. While it notes the tool returns a file path, it does not disclose side effects such as file creation/overwriting, required permissions, idempotency, or error behavior. This is insufficient for a tool that likely writes files.
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?
Two short sentences, front-loaded with the main action. No unnecessary words; it efficiently conveys the primary function and the return value.
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?
While the output schema exists and the description mentions the return type, the tool has required parameters with no descriptions and no annotations. The overall context (prerequisites, relationship to sibling tools like detectar_sinergias) is missing, making it inadequate for correct invocation.
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%, and the description provides no explanation of the 'ruta' and 'documento' parameters. Their names give limited clues, but the required 'documento' parameter is not defined, leaving the agent unable to construct a valid invocation confidently.
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 clearly states the tool's function: generating the interactive synergy map ('mapa interactivo de sinergias') and returning the file path. The verb 'Genera' and the specific resource distinguish it from sibling render tools like render_guia and render_chuleta.
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 guidance is provided on when to use this tool versus alternatives. It does not mention any prerequisites, exclusions, or scenarios where other render tools (e.g., render_guia) would be more appropriate.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
resolver_mazoA
Resuelve una lista de mazo contra Scryfall y devuelve el texto de oráculo real.
Acepta las exportaciones de MTG Arena, Moxfield, Archidekt, MTGO, el CSV de ManaBox o una lista suelta ("4 Lightning Helix" por línea). Úsalo SIEMPRE antes de afirmar nada sobre lo que hace una carta: no cites de memoria.
| Name | Required | Description | Default |
|---|---|---|---|
| lista | Yes | ||
| nombre | No | Mazo |
Output Schema
| Name | Required | Description |
|---|---|---|
| result | Yes |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the burden. It discloses the core behavior: querying Scryfall and returning authoritative oracle text, and warns against citing from memory. It does not cover rate limits or failure modes, but for a read-only resolver the key behavioral trait is well explained.
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 concise and front-loaded: the first sentence states the purpose, the second gives formats and usage guidance. Every sentence adds value with no repetition or fluff.
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 has an output schema, so return value details are not needed. The description provides input format details and a strong usage rule. It is moderately complete, though it does not mention potential errors or network dependencies, which would be useful but not essential.
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 thoroughly explains the 'lista' parameter, including supported formats and example line format. The 'nombre' parameter is only implied by its default value 'Mazo', but that is low-risk and easily inferred.
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 clearly states the tool resolves a deck list against Scryfall and returns the real oracle text. It distinguishes itself from sibling tools by specifying its unique function of resolving card text, not analyzing synergies or rendering guides.
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 explicitly instructs to always use this tool before claiming anything about what a card does, and lists accepted input formats. It does not name alternatives or explicitly say when not to use it, but the guidance is clear and actionable.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Tool Schema Changelog
Recent tool additions, removals, and schema changes observed during successful MCP inspections. Dates show when Glama detected each change.
9 tool updates
v0.1.0- First observed
analizar - First observed
combos_conocidos - First observed
detectar_sinergias - First observed
listar_reglas - First observed
radiografia_del_mazo - First observed
render_chuleta - First observed
render_guia - First observed
render_mapa - First observed
resolver_mazo
TDQS
Each tool has a clearly distinct role in the deck analysis workflow: resolving, radiographing, synergy detection, rule listing, known combos, and three rendering formats. The descriptions effectively highlight the unique purpose of each, even where there is some underlying overlap in resolving the deck.
Most tools follow a verb_noun pattern in Spanish (resolver_mazo, detectar_sinergias), but a few use noun phrases (radiografia_del_mazo, combos_conocidos) or an English verb (render_*). The snake_case consistency and readable Spanish keep the names predictable overall, but the mix of syntactic patterns prevents a perfect score.
The 9 tools are well-scoped for a Magic deck analysis server, covering resolution, analysis, synergy detection, and output generation without redundancy or bloat. The count feels appropriate for the purpose, fitting comfortably within the effective range.
The server provides a complete lifecycle for deck analysis: resolving against Scryfall, deep fact extraction, synergy discovery, known combo lookup, and multiple rendering options. The inclusion of an 'analizar' shortcut also covers the full automatic pipeline, leaving no critical gaps in the core workflow.
Maintenance
Resources
Unclaimed servers have limited discoverability.
Looking for Admin?
If you are the server author, to access and configure the admin panel.
Related MCP Connectors
Magic: The Gathering card search, rules, rulings, deck analysis, brackets, and combo detection.
Live TCG card and decklist prices for AI assistants. 22+ games, no account, ready-to-buy links.
Daily EU card prices, deal detection and EU-vs-US arbitrage for 19 trading card games.
Look up Pokemon TCG Pocket cards, sets, packs, and evaluate decks with battle simulations.
111
Related MCP Servers
- FlicenseNot gradedqualityDmaintenanceEnables Magic: The Gathering players to manage decks and access card information through Claude, supporting gameplay actions like drawing cards and mulligans while providing Scryfall API integration for card lookups.15-
- AlicenseAqualityDmaintenanceProvides AI assistants with 69 tools, 19 prompts, and 21 resources for deep access to Magic: The Gathering, including card data, combos, draft analytics, Commander metagame, competitive constructed, sideboard strategy, deck building, and rules engine, working with any MCP client.5617MIT
- AlicenseNot gradedqualityBmaintenanceUnified MCP server for Magic: The Gathering, combining Scryfall card search and pricing, EDHRec commander recommendations, Archidekt deck reading, and decklist validation into a single service.MIT
- FlicenseNot gradedqualityBmaintenanceProvides access to Magic: The Gathering card data via Scryfall API, including search, rulings, sets, and local deck management with multi-owner support.-
Latest Blog Posts
- Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)By Om-Shree-0709 on .mcpAgent IdentityOAuth 2.1
- Your AI Chatbot Just Exposed Your CEO's Salary to an InternBy Om-Shree-0709 on .Agent IdentityMCP SecurityOAuth Delegation
- Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)By Om-Shree-0709 on .Agentic AiPrompt InjectionWebAssembly
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/grutino/mtg-forja'
If you have feedback or need assistance with the MCP directory API, please join our Discord server