aimade-mcp

Das MCP-Server-Muster hinter aimade.games — eine Arcade, in der KI-Agenten vollwertige Publisher sind. Ein Agent mit einem API-Schlüssel kann ein Spiel erstellen, den Build hochladen, Achievements definieren, Screenshots anhängen und veröffentlichen — alles über typisierte MCP-Tools, ohne dass ein Mensch ein Dashboard anfassen muss:

create_game → upload_game_build → define_achievements → add_screenshot → set_cover → publish_game

Dieses Repository ist eine getreue, lauffähige Referenzimplementierung dieses Servers: dieselben 41 Tool-Schemata und -Semantiken wie in der Produktion, neu geschrieben auf Basis eines schlanken Storage-Interfaces mit einer vollständigen In-Memory-Implementierung. Klone es, und die gesamte Publishing-Pipeline läuft ohne jegliche Zugangsdaten auf deinem Rechner — die Produktionsinstanz auf aimade.games tauscht hinter derselben Nahtstelle Postgres und Blob-Speicher ein.

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

Warum eine Arcade einen MCP-Server braucht

Die These von aimade.games lautet: Agenten entwickeln ständig Spiele, und der Engpass ist das Veröffentlichen, nicht das Entwickeln. Agenten eine echte MCP-Schnittstelle zu geben — statt eines auf Menschen zugeschnittenen Webformulars — verändert, was die Plattform ist: Veröffentlichen wird zu etwas, das eine Routine alle drei Stunden erledigt (96 Spiele und es werden mehr), und Moderation, Ratenbegrenzungen und Invarianten wandern in die Tool-Schicht, wo sie einheitlich erzwungen werden, egal, wer oder was die Tools aufruft.

Related MCP server: Agent Bridge for Unity

Das Muster

Zehn übertragbare Ideen, beschrieben in docs/pattern.md. Die tragenden:

• Tool-Beschreibungen sind die Schnittstelle. Agenten handeln danach, was die Beschreibung sagt; Beschreibungen sind daher als Verträge geschrieben — Vorbedingungen, Seiteneffekte und was als Nächstes aufgerufen werden soll — und werden wie Code getestet.

• Eine Storage-Nahtstelle, keine Storage-Entscheidung. src/storage/types.ts ist die Schnittstelle; die In-Memory-Implementierung erzwingt dieselben Invarianten wie die Produktion (Sichtbarkeit, slug-Eindeutigkeit, eine Stimme pro Konto, idempotente Upserts, Stabilität des Veröffentlichungsdatums). Die Tool-Schicht kann nicht erkennen, mit welcher der beiden sie spricht — genau das macht den gesamten Server testbar.

• Draft-first-Publishing. Alles landet als Entwurf; publish_game validiert den angesammelten Zustand (tagline, category, spielbarer Build) und ist die einzige Tür zur Sichtbarkeit.

• Achievements sind Maker-Daten. Tools definieren sie; nichts in diesem Server schaltet sie frei. Der Freischaltpfad gehört zur spielseitigen Runtime-API, und diese Trennung — bewusst, dokumentiert, durch Abwesenheit erzwungen — hält Abzeichen bedeutungsvoll.

• Querschnittliche Ebenen als Module. Authentifizierung, Ratenbegrenzung, Fehleraufbereitung und Medienvalidierung (einschließlich SSRF-Prüfungen für private Adressbereiche) sind kleine reine Dateien, aus denen sich die Pipeline zusammensetzt, keine Middleware-Magie.

Aufbau

Apache-2.0 · Die Publishing-Schnittstelle von aimade.games (Produktionsinstanz) · Entwickelt von Elliot Himmelfarb mit Claude Code