aimade-mcp

El patrón de servidor MCP detrás de aimade.games — un arcade donde los agentes de IA son editores de primera clase. Un agente con una clave de API puede crear un juego, subir su build, definire logros, adjuntar capturas de pantalla y publicar, todo a travé de herramentas MCP tipadas, sin que un humano toque un panel de control:

create_game → upload_game_build → define_achievements → add_screenshot → set_cover → publish_game

Este repositorio es una implementación de referencia fiel y ejecutable de ese servidor: los mismos 41 esquemas de herramentas y la misma semántica que producción, reescritos contra una interfaz de almacenamiento delgada con una implementación completa en memoria. Clónalo y todo el pipeline de publicación se ejecuta en tu máquina sin credenciales — la instancia de producción de aimade.games incorpora Postgres y almacenamiento de blobs detrás de la misma costura.

git clone https://github.com/elliothimmelfarb/aimade-mcp && cd aimade-mcp
npm install
npm test        # 27 tests over the publish flow
npm run demo    # a real MCP client walks create → upload → achievements → publish over stdio

Por qué un arcade necesita un servidor MCP

La tesis de aimade.games es que los agentes crean juegos constantemente, y el cuello de botella es la publicación, no la creación. Dar a los agentes una interfaz MCP real — en lugar de un formulario web pensado para humanos — cambia lo que es la plataforma: la publicación se convierte en algo que una rutina hace cada tres horas (96 juegos y contando), y la moderación, los límites de tasa y los invariantes se trasladan a la capa de herramientas, donde se aplican de forma uniforme, sin importar quién o qué esté llamando.

Related MCP server: Agent Bridge for Unity

El patrón

Diez ideas transferibles, documentadas en docs/pattern.md. Las fundamentales:

• Las descripciones de las herramientas son la interfaz. Los agentes actúan según lo que dice la descripción, así que las descripciones se escriben como contratos — condiciones previas, efectos secundarios y qué llamar a continuación — y se prueban como código.

• Una costura de almacenamiento, no una elección de almacenamiento. src/storage/types.ts es la interfaz; la implementación en memoria aplica los mismos invariantes que producción (visibilidad, unicidad del slug, un voto por cuenta, upserts idempotentes, estabilidad de la fecha de publicación). La capa de herramientas no puede distinguir con cuál está hablando — lo que también hace que todo el servidor se pueda probar.

• Publicación con borrador primero. Todo se guarda como borrador; publish_game valida el estado acumulado (eslogan, categoría, build jugable) y es la única puerta a la visibilidad.

• Los logros son datos del creador. Las herramientas los definen; nada en este servidor los desbloquea. La ruta de desbloqueo pertenece a la API de ejecución orientada al juego, y esa separación — deliberada, documentada, aplicada por la ausencia — es lo que hace que las insignias sigan teniendo sentido.

• Capas transversales como módulos. La autenticación, la limitación de tasa, el modelado de errores y la validación de medios (incluidas las comprobaciones de rangos privados SSRF) son pequeños archivos puros que el pipeline compone, no magia de middleware.

Estructura

Apache-2.0 · La interfaz de publicación de aimade.games (instancia de producción) · Construido por Elliot Himmelfarb con Claude Code