Tank Fight MCP — la especificación del juego como servicio

Un servidor MCP que sirve la especificación canónica de Tank Fight: tamaño del campo y de la ventana, estadísticas de tanques y balas, reglas de aparición, puntuación, controles, comportamiento de los menús, estrategias de IA, la rampa de dificultad y un laberinto destruible por nivel.

Se ejecuta como un servicio local en un puerto. Cualquier cliente MCP puede conectarse, preguntar qué herramientas ofrece y consultar la especificación — mientras se construye el juego en Java, en TypeScript o en cualquier otro lenguaje.

Para qué sirve

Dos tareas, y la segunda importa más de lo que parece a primera vista.

1. Mantener las implementaciones independientes de acuerdo. Dos compilaciones del mismo juego, escritas por separado, divergen en el momento en que necesitan un número que nadie anotó. Que ambas pregunten al mismo servicio qué tamaño tiene un tanque elimina las conjeturas.

2. Evitar que el modelo invente requisitos. Cada detalle que una especificación omite es un lugar donde un asistente de codificación de IA elige silenciosamente algo plausible y sigue adelante — ¿las balas se detienen en las paredes? ¿pueden los aliados dispararse entre sí? ¿qué ocurre cuando un jugador es destruido a mitad de ronda? Rara vez menciona que lo decidió. Cada una de esas preguntas se responde aquí, de modo que la cuestión se convierte en una consulta en lugar de una suposición, y open_questions nombra lo que genuinamente no está decidido, para que la respuesta honesta sea "pregunta a un humano" en lugar de una invención con total seguridad.

Related MCP server: OWASP Pentest Guide Knowledge Base

Ejecutarlo

Requiere uv.

uv sync

uv run server.py

Eso sirve la especificación en http://127.0.0.1:8082/mcp. Usa --port para escuchar en otro puerto, --host para enlazar otra interfaz y --stdio para clientes que solo hablan stdio.

Conectar un cliente

Cualquier cliente MCP, cualquier número de ellos a la vez. Para Claude Code:

claude mcp add --transport http tank-spec http://localhost:8082/mcp

Añade --scope project para registrarlo en el repositorio en el que estás trabajando, de modo que todos los que trabajen en esa implementación obtengan la misma especificación. Luego /mcp para confirmar la conexión, y el cliente puede preguntar al servidor qué herramientas existen y cómo llamarlas — aquí no hay nada que configurar por cliente.

Herramientas

Lo que este servidor deliberadamente no hace

No tiene idea de quién está conectado ni de qué están construyendo, y eso es a propósito. Conoce la especificación; los clientes conocen el servidor. Nada apunta en la otra dirección.

Así que comprobar si una implementación sigue coincidiendo con la especificación es tarea del cliente. Un cliente puede leer los valores de su propio código y compararlos con lo que devuelven estas herramientas — está en ese repositorio y el servidor no. Un servidor que se metiera en un checkout para inspeccionarlo tendría que conocer el lenguaje, la estructura de archivos y la ruta, y necesitaría actualizarse cada vez que apareciera otra implementación.

El mismo razonamiento es por el que la especificación se sirve en lugar de distribuirse como archivo:

• Está fuera de cada implementación. Una sesión que trabaja en un repositorio no puede leer los archivos de otro, pero puede llamar a un servicio.

• Se consulta, no se vuelca. search_spec("friendly fire") devuelve una regla. Cargar toda la especificación en el contexto de un modelo para responder una pregunta es exactamente el desperdicio que esto evita.

• Algunas respuestas se calculan, no se almacenan. Los niveles se generan a partir de una fórmula de rampa — el nivel 6 no existe en ningún archivo. resolve_level es la única forma correcta de preguntar, y su truncamiento de enteros es esencial: una versión en coma flotante discrepa en cuatro de los ocho niveles.

Ladrillos destruibles y laberintos por nivel

Todo lo que está dentro del borde es ladrillo, y el ladrillo puede ser destruido a tiros — por ambos bandos, ya que los bandos importan para los tanques y nunca para las paredes. Una casilla es de 20x20 y recibe 40 de daño, así que dos balas estándar abren un agujero por el que luego pasan los tanques. El borde en sí es inmune.

Cada nivel tiene su propio laberinto, así que el número de nivel es la única perilla de dificultad: determina cuántos enemigos llegan, con qué rapidez y el terreno en el que aparecen. El nivel 1 es casi abierto; el nivel 8 es lo bastante denso como para que abrir un camino a tiros suela ser más rápido que encontrarlo.

get_maze(level) devuelve los rectángulos, la lista de casillas expandida y una imagen:

########################################
#EE................EE................EE#
#EE................EE................EE#
#......................................#
#......BBBBBBBBBBB....BBBBBBBBBBB......#
...
#.............AA...AA...AA.............#
########################################

Usa las casillas expandidas en lugar de expandir tú mismo los rectángulos — ese paso, y la regla de qué casilla daña una bala cuando está a caballo entre dos, son donde dos compilaciones terminan más fácilmente cavando agujeros distintos con los mismos disparos.

Añadir un laberinto es solo añadir rectángulos bajo mazes.levels en el YAML. El conjunto de pruebas lo somete entonces a los invariantes que hacen que un nivel sea jugable: alineado con las casillas, dentro del área, sin solapamientos, cajas de aparición y de aliados despejadas, y todos los puntos de entrada accesibles a pie sin destruir nada — cavar es un atajo, nunca un requisito.

Editar la especificación

spec/game-spec.yaml es todo el contenido, y está pensado para editarse a mano — ese es el punto. El servidor lo relee en cada llamada, así que un cambio surte efecto de inmediato sin reiniciar nada.

La especificación se sembró a partir de una implementación funcional y es independiente de ella desde ese momento. Es la que manda: cambia un valor aquí primero y luego haz que las implementaciones lo sigan.

Pruebas

uv run pytest

tests/test_spec.py fija los valores de la especificación y somete cada laberinto a los invariantes de jugabilidad. tests/test_server.py maneja el servidor a través de un cliente MCP — descubre las herramientas, lee sus descripciones, llámalas. tests/test_http.py inicia el proceso real en un puerto y se conecta a él por HTTP, como hace un cliente.

Estructura

spec/game-spec.yaml   the specification — the actual source of truth
server.py             MCP server: tool definitions, their descriptions, and the transport
tank_spec/spec.py     loading, searching, level maths, maze expansion
tests/                spec and maze invariants, MCP integration, HTTP transport