Skip to main content
Glama

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.

Mapa de sinergias del mazo

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.

Guía de sinergias

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.

Chuleta imprimible


Related MCP server: mtg-mcp-server

De qué se compone

Pieza

Qué es

Su papel aquí

reglas.json

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.

lexico.json

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

reglas.py y su gemelo motor.js

Cruza el mazo con los patrones y devuelve las candidatas, cada una con la frase de oráculo que la disparó.

scryfall.py

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

guia.js, chuleta.js, grafo.js

Convierten el análisis en HTML autónomo. Una sola implementación, compartida por la web y la terminal.

El servidor MCP

server.py

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

skill/SKILL.md

Lo que Claude debe saber: qué verificar antes de afirmar nada, qué documento pide cada situación, cómo redactar.

El CLI

cli.py

Los mismos tres documentos sin pasar por Claude.

La web

docs/

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

La web

Pedírselo a Claude en lenguaje natural

Claude Desktop · Claude Code

Usarlo desde otro programa con soporte MCP

Otros clientes MCP

Generar los HTML desde la terminal

Línea de comandos

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 | sh

En 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

  1. Abre el archivo de configuración de conectores:

    • macOS: ~/Library/Application Support/Claude/claude_desktop_config.json

    • Windows: %APPDATA%\Claude\claude_desktop_config.json

    • Linux: ~/.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 del mcpServers que ya tengas.

  2. 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.

  1. Cierra Claude Desktop del todo y vuelve a abrirlo. No basta con cerrar la ventana.

  2. Comprueba que ha cargado: en el icono de conectores debe aparecer mtg-forja con sus nueve herramientas. Si no sale, mira Si algo falla.

  3. Instala además la skill de skill/SKILL.md para 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

stdio

Comando

uvx

Argumentos

--from · git+https://github.com/grutino/mtg-forja · mtg-forja-mcp

Variable de entorno

MTG_FORJA_SALIDA = la carpeta donde quieres los HTML

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-forja

Y 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 salida

O instalándolo de una vez:

pip install git+https://github.com/grutino/mtg-forja
mtg-forja mazo.txt -n "Mi mazo" -o salida

Genera 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 salida

Opción

Qué hace

mazo.txt

Archivo con la lista. Usa - para leer de la entrada estándar.

-n, --nombre

Nombre del mazo, el que sale en los títulos.

-o, --salida

Carpeta de destino.

--json

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

  1. Entra en https://grutino.github.io/mtg-forja/

  2. Pega la lista, o pulsa Cargar ejemplo para ver cómo funciona con un mazo de prueba.

  3. Pulsa Analizar mazo.

  4. 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.

  5. 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

uv no está instalado, o el cliente no ve tu PATH. Usa la alternativa sin uv con ruta absoluta.

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

MTG_FORJA_SALIDA apunta a una carpeta que no existe. Créala o cambia la ruta.

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

resolver_mazo

Resuelve la lista contra Scryfall y devuelve el oráculo real.

radiografia_del_mazo

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.

detectar_sinergias

Busca patrones de interacción y devuelve candidatas con la frase de oráculo que disparó cada una.

combos_conocidos

Combos ya catalogados por Commander Spellbook, con sus pasos. Única fuente que no es oráculo verificado: hay que contrastarla.

listar_reglas

Enseña los patrones que conoce el motor.

render_guia / render_chuleta / render_mapa

Generan cada HTML a partir del documento.

analizar

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 (reglas.json)

solo los arquetipos que alguien escribió

alta — ve asimetrías y casos raros

Léxico de recursos (lexico.json)

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 nuevaFerocious 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 25

Pregunta 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:

  1. 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.

  2. 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

Enlightened Tutor

Busca «an artifact or enchantment card»: encuentra cinco cartas del mazo

Worship

«If you control a creature…» y el mazo lleva diecinueve

Mother of Runes

«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ó: drawback, pitch-spell, tutor

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, Thwart

drawback 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.py

Una 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 consulta

Solo 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:

  1. Un ruling oficial. Es la regla escrita por Wizards. Si contradice una sinergia detectada, se descarta la sinergia.

  2. 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_no y cuenta como sinergia aunque no aparezca en el mapa.

  3. 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

target creature you control

criaturas

target nonland permanent

todo menos tierras

target permanent

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 Wildfire a 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é

Mobilize

Crea fichas de criatura: recurso claro

Warp

No

Solo se relanza a sí misma. Meterla inventaría relaciones de «parpadeo tus permanentes» que no existen

Kicker

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.py

Montarlo 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

python3 --version

git

Clonar el repositorio

git --version

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 -e instala en modo editable: si tocas el código, no hay que reinstalar. Si usas conda, crea igualmente el venv: mezclar ambos da problemas.

Paso 2 — Comprobar que funciona

pip install pytest
pytest -q

Deben 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-prueba

Debe 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-dragones

Salen 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/salida

Paso 3 — Levantar la web en local

python scripts/sync_docs.py
python -m http.server -d docs 8000

Y 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:8000

Desarrollo

# prueba sin red, con el fixture de ejemplo
MTG_FORJA_FIXTURE=ejemplos/fixture-pruebas.json mtg-forja ejemplos/prueba.txt -o /tmp/salida

Variables de entorno:

MTG_FORJA_CACHE

Dónde cachear las cartas (por defecto ~/.cache/mtg-forja).

MTG_FORJA_SALIDA

Carpeta por defecto de los HTML del servidor MCP.

MTG_FORJA_FIXTURE

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 red

Los 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 find-my-combos acepta el mazo entero de una vez y devuelve combos con sus pasos redactados. Es la única fuente del proyecto que no es oráculo verificado, y por eso siempre se contrasta

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 /combos/<carta> engaña con el título: no lista combos de esa carta, sino los combos que aparecen en mazos que la juegan. En la de Momo, Momo no sale en ninguno de los 133. Su propia ficha enlaza a Commander Spellbook para buscar los combos de una carta — la fuente que ya usamos

Moxfield

Devuelve 403 a cualquier cliente automatizado

MTGGoldfish

Sin API y con Content-Signal: ai-train=no

Draftsim

Su robots.txt prohíbe explícitamente al agente anthropic-ai

TCGplayer

La API pide clave de socio, y da precios

Cardmarket

410 Gone

MTGSimilar

Protección anti-bot

Untapped.gg

Su API devuelve 403 y su bucket JSON no tiene índice público. El sitio sí permite rastreo, pero lo que ofrece es metajuego de MTG Arena: tasas de victoria y popularidad

edh-combos.com

La más abierta de todas —robots.txt vacío, sin restricciones— pero su propio pie lo dice: «Combo data is based on the Commander Spellbook, and card images are provided by Scryfall». Es un buscador montado sobre las dos fuentes que ya usamos, así que rascarla sería pedir por HTML lo que ya pedimos por API a la fuente original

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 tools
analizarA

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_*.

ParametersJSON Schema
NameRequiredDescriptionDefault
rutaNo
listaYes
nombreNoMazo

Output Schema

ParametersJSON Schema
NameRequiredDescription
resultYes

TDQS

A3.7/5.0
Behavior4/5

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.

Conciseness5/5

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.

Completeness2/5

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.

Parameters1/5

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.

Purpose4/5

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.

Usage Guidelines5/5

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:

  1. Comprueba con resolver_mazo o radiografia_del_mazo que las cartas hacen de verdad lo que el combo dice.

  2. Si el oráculo real no sostiene los pasos, descarta el combo.

  3. 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.

ParametersJSON Schema
NameRequiredDescriptionDefault
listaYes
nombreNoMazo

Output Schema

ParametersJSON Schema
NameRequiredDescription
resultYes

TDQS

A4.4/5.0
Behavior5/5

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.

Conciseness5/5

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.

Completeness4/5

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.

Parameters2/5

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.

Purpose5/5

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.

Usage Guidelines5/5

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.

ParametersJSON Schema
NameRequiredDescriptionDefault
listaYes
nombreNoMazo

Output Schema

ParametersJSON Schema
NameRequiredDescription
resultYes

TDQS

A3.5/5.0
Behavior4/5

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.

Conciseness4/5

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.

Completeness3/5

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.

Parameters1/5

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.

Purpose5/5

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.

Usage Guidelines3/5

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.

ParametersJSON Schema
NameRequiredDescriptionDefault

No parameters

Output Schema

ParametersJSON Schema
NameRequiredDescription
resultYes

TDQS

A3.5/5.0
Behavior3/5

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.

Conciseness5/5

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.

Completeness4/5

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.

Parameters4/5

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.

Purpose4/5

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.

Usage Guidelines2/5

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_toca y velocidad — 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ú.

ParametersJSON Schema
NameRequiredDescriptionDefault
listaYes
nombreNoMazo

Output Schema

ParametersJSON Schema
NameRequiredDescription
resultYes

TDQS

A4.3/5.0
Behavior4/5

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.

Conciseness5/5

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.

Completeness4/5

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.

Parameters2/5

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.

Purpose5/5

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.

Usage Guidelines5/5

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.

ParametersJSON Schema
NameRequiredDescriptionDefault
rutaNo
documentoYes

Output Schema

ParametersJSON Schema
NameRequiredDescription
resultYes

TDQS

C2.9/5.0
Behavior3/5

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.

Conciseness5/5

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.

Completeness2/5

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.

Parameters1/5

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.

Purpose4/5

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.

Usage Guidelines2/5

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.

ParametersJSON Schema
NameRequiredDescriptionDefault
rutaNo
documentoYes

Output Schema

ParametersJSON Schema
NameRequiredDescription
resultYes

TDQS

A4.2/5.0
Behavior4/5

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.

Conciseness5/5

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.

Completeness4/5

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.

Parameters3/5

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.

Purpose5/5

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.

Usage Guidelines4/5

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.

ParametersJSON Schema
NameRequiredDescriptionDefault
rutaNo
documentoYes

Output Schema

ParametersJSON Schema
NameRequiredDescription
resultYes

TDQS

C2.9/5.0
Behavior2/5

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.

Conciseness5/5

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.

Completeness2/5

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.

Parameters1/5

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.

Purpose5/5

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.

Usage Guidelines2/5

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.

ParametersJSON Schema
NameRequiredDescriptionDefault
listaYes
nombreNoMazo

Output Schema

ParametersJSON Schema
NameRequiredDescription
resultYes

TDQS

A4.4/5.0
Behavior4/5

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.

Conciseness5/5

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.

Completeness4/5

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.

Parameters4/5

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.

Purpose5/5

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.

Usage Guidelines4/5

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.

  1. 9 tool updatesv0.1.0
    • First observedanalizar
    • First observedcombos_conocidos
    • First observeddetectar_sinergias
    • First observedlistar_reglas
    • First observedradiografia_del_mazo
    • First observedrender_chuleta
    • First observedrender_guia
    • First observedrender_mapa
    • First observedresolver_mazo

TDQS

A3.8/5.0
Disambiguation5/5

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.

Naming Consistency4/5

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.

Tool Count5/5

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.

Completeness5/5

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

ActivityMaintained
ResponsivenessUnresponsive

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

Related MCP Servers

  • F
    license
    Not graded
    quality
    D
    maintenance
    Enables 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
    -
  • A
    license
    A
    quality
    D
    maintenance
    Provides 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.
    56
    17
    MIT
  • A
    license
    Not graded
    quality
    B
    maintenance
    Unified 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
  • F
    license
    Not graded
    quality
    B
    maintenance
    Provides 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

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