aimade-mcp

aimade.games の背後にある MCP サーババー パターン — AI エージェントが第一級のパブリッシャーとなるアーケード。API キーを持つエージェントは、型付きの MCP ツールを通じて、ゲームの作成、ビルドのアップロード、実績の定義、スクリーンショットの添付、公開を、人間がダッシュボードに触れることなくすべて行えます:

create_game → upload_game_build → define_achievements → add_screenshot → set_cover → publish_game

このリポジトリは、そのサーバーの忠実かつ実行可能なリファレンス実装です。本番と同じ 41 個のツールスキーマとセマンティクスを、薄いストレージインターフェース向けに書き直し、完全なインメモリ実装を備えています。クローンするだけで、公開パイプライン全体がクレデンシャルなしで自分のマシン上で動作します。aimade.games の本番インスタンスは、同じシーム(継ぎ目)の背後で Postgres と blob ストレージに差し替えられています。

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

なぜアーケードに MCP サーバーが必要なのか

aimade.games の主張は、エージェントは絶えずゲームを作るが、ボトルネックは制作ではなく公開にある、というものです。人間向けの Web フォームではなく、エージェントに真の MCP インターフェースを与えることで、プラットフォームのあり方が変わります。公開は、ルーチンが 3 時間ごとに行う処理になり(96本のゲーム、現在も増加中)、モデレーション、レート制限、不変条件はツール層に移され、呼び出し元が誰であれ何であれ統一的に強制されます。

Related MCP server: Agent Bridge for Unity

パターン

転用可能な 10 のアイデアを docs/pattern.md にまとめています。特に重要なのは次のとおりです:

• ツールの説明がインターフェースである。 エージェントは説明に書かれた内容に従って行動するため、説明は契約として書かれます。前提条件、副作用、次に呼び出すべきものが明記され、コードと同じようにテストされます。

• ストレージの選択ではなく、ストレージのシーム。 src/storage/types.ts がインターフェースであり、インメメモリ実装は本番と同じ不変条件(可視性、slug の一意性、アカウントごとに1票、冪等な upsert、公開日の安定性)を強制します。ツール層はどちらと通信しているのか判別できません。これこそがサーバー全体をテスト可能にしている理由でもあります。

• ドラフト優先の公開。 すべてはドラフトとして置かれます。publish_game は蓄積された状態(タグライン、カテゴリ、プレイ可能なビルド)を検証し、公開への唯一の入り口です。

• 実績は作り手のデータである。 ツールが実績を定義し、このサーバー内で実績をアンロックするものは何もありません。アンロックの経路はゲーム向けのランタイム API に属します。この分離は、意図的で、文書化され、不在によって強制されるものであり、それがバッジの意味を保っています。

• 横断的レイヤーをモジュールとして。 認証、レート制限、エラー整形、メディア検証(SSRF のプライベートレンジチェックを含む)は、パイプラインが組み合わせる小さな純粋なファイルであり、ミドルウェアの魔法ではありません。

レイアウト

Apache-2.0 · aimade.games の公開インターフェース(本番インスタンス) · Ellot Himmelfarb が Claude Code で構築