MCP.so
ログイン

Yes2SDK MCP Server

@Yes2SDK

基本情報

トランスポート

streamable-http

認証方式

提供元の文書を確認

カテゴリ

開発者ツール

作者

Yes2SDK

Yes2SDK MCP Server について

Yes2SDK MCP Server は、HTML5 ゲームを Poki、CrazyGames、Yandex Games、YouTube Playables、GameDistribution、Jest に配信する開発者向けに Yes2Games が公式にホストするサーバーです。AI アシスタントに SDK のクイックスタート、API リファレンス、プラットフォームルールを提供し、プラットフォームのリジェクトルールに照らしてビルドをチェックします。

接続情報

https://mcp.yes2games.com/mcp

セットアップ

claude mcp add yes2sdk --transport http https://mcp.yes2games.com/mcp

Yes2SDK MCP Server のツール

21

Version-pinned steps for adding the Yes2SDK to a Unity, Defold, or JavaScript/TypeScript game (Phaser, three.js, plain canvas), including post-install setup such as Unity's required WebGL template or the JS local-dev mock and Vite base: './', and a check that confirms the SDK resolves. Answers "how do I add the Yes2SDK to this project?" — until these steps complete, code referencing the Yes2SDK namespace (Unity), the yes2sdk module (Defold), or window.Yes2SDK (JS) will not compile. Returns text; the project is never modified, and what is already installed is reported by detect_sdk instead.

A readiness report for one game project: the engine it uses (unity, defold, js), whether the Yes2SDK is installed, the installed version, and any install steps still required. Answers "can this project compile Yes2SDK code yet?", and pairs with get_install_instructions when the SDK is missing. Two input modes, exactly one per request: - `projectPath`: absolute path to the project root, available when this server runs LOCALLY over stdio and can read the disk. - `files`: inline map of repo-relative path → contents, keyed on "game.project", "Packages/manifest.json" or "package.json" — the mode for the HOSTED/sandboxed server, which has no disk access. For JS/TS projects it reads the @yes2games/js dependency (version from the lockfile when present), detects Phaser, three.js and Vite, and lists the integration steps still missing (local-dev mock, Vite base: './', data-yes2-canvas, setLoadingProgress, engine helpers). A package.json without @yes2games/js is reported as engine js with the package not installed. Project files are inspected, never modified.

Keyword search across the Yes2SDK documentation — quickstarts, API reference, dashboard guide, integration rules — returning up to the top 5 matching sections with the doc slug of each, for follow-up via get_quickstart(platform) or get_api_reference(module). The way in when the question about integration, platform requirements, or the SDK's API is still open-ended: a specific error resolves faster through troubleshoot(symptom), and per-platform module support through get_platform_capabilities(). Searches the bundled docs only, with no web access.

The full quickstart integration guide for one target platform (poki, crazygames, yandex, gamedistribution, youtube, jest): mandatory call sequence, per-engine examples, critical rules, and the common rejection reasons. The starting point for a new integration, before the first SDK call is written. The TypeScript/JavaScript examples apply to any JS game; engine setup (Phaser, three.js, the local-dev mock) is in get_install_instructions("js").

The full API reference for one Yes2SDK module — exact method signatures, parameters, return values, and per-platform behavior. Modules: overview, lifecycle, ads, analytics, auth, banners, data, errors, friends, game, player, score, session, leaderboard, stats, iap, config, review, upcoming.

The names of every Yes2SDK API reference module. A directory for get_api_reference(module) and the yes2sdk://docs/{module} resource when the right module name is not known yet.

A pre-upload verdict on a Yes2SDK game, checked against the real platform rejection rules and reported as FAIL/WARN/INFO findings. Answers "would this build be rejected?" for a target `platform`, using either or both of the two modes below. 1) STATIC build checks — two ways to supply the build: a) `buildPath`: absolute path to an ALREADY-EXTRACTED build folder, available when this server runs LOCALLY over stdio; the HOSTED/sandboxed server has no disk access. b) INLINE content for the hosted server: `indexHtml` (the index.html text), `fileList` (file paths in the build) and/or `jsContents` (the build's JS file contents). Bundling is verifiable only when `jsContents` is present. Covered: the engine the dashboard would detect, the game's own JS calling the SDK, no external <script src="http..."> tags (platforms block them), index.html present (Poki also needs index.json), a responsive full-viewport canvas heuristic, and root-absolute paths (a warning; FAIL for Jest on index.html, as the dashboard's Jest gate). JavaScript/TypeScript builds (engine vanilla, "HTML5 / JavaScript") also get warnings mirroring what the dashboard does with them: a copy of yes2sdk.umd.js in the build, the @yes2games/js mock in a production build, and no data-yes2-canvas marker. 2) BEHAVIORAL compliance checks, from `eventLogJson`: a JSON string of an exported Yes2SDK Inspector event log (LogEntry objects with type, method, params, success). Covers the platform's runtime rules such as gameplayStop before ads, reward only on adViewed, and no ads in the first 30s. These rules need a real run in the QA Inspector; static files cannot produce them. Jest runs its automated rules J-001 to J-014 alongside the universal ones; its remaining launch checklist items are manual, and the verdict points at them. A platform with no automated rules of its own runs only the universal rules and the verdict says so.

The compliance rules a build must satisfy for one platform (poki, crazygames, yandex, gamedistribution, youtube, jest), each as 'id [severity]: description'. These are the same checks validate_integration runs. Where a platform publishes a launch checklist (Jest), its items follow as [manual] entries, and a platform whose automated rules are not built yet says so explicitly. Answers "what do I have to get right for this platform?" up front; one rule's detail and fix comes from get_compliance_rule(ruleId), and an actual build is graded by validate_integration. Returns the rule list only; no build is evaluated.

Which Yes2SDK modules are supported on which platforms (poki, crazygames, yandex, gamedistribution, youtube, jest, portal), as a Ready / Partial / not-offered matrix, optionally narrowed to one platform (a column) or one module (a row). Answers "do I need to guard this module behind isSupported()?": Friends is CrazyGames-only, Auth is CrazyGames, Yandex and Jest only, banners are not offered on Poki, Jest has no ads, and portal is the Yes2Games portal (play.yes2games.com). Reads the bundled API docs; per-method detail comes from get_api_reference(module).

One Yes2SDK platform-compliance rule by id (e.g. 'P-002', 'U-001', 'CG-003'): its severity (FAIL/WARN/INFO), the platform it applies to, what it checks, and the concrete fix(es). Answers "what is this rule id and how do I satisfy it?" when validate_integration or get_platform_requirements surfaces one. A platform's full rule set comes from get_platform_requirements(platform); grading a build is validate_integration.

The likely cause and ordered fix for a reported Yes2SDK integration symptom, given an error string or a plain-language description. Covers the common failures: missing namespace or module (SDK not installed), window.Yes2SDK undefined (the JS local-dev mock), JS builds with root-absolute /assets paths, the mock in a production build, the wrong canvas captured, audio after ads in Phaser or three.js, Unity build-guard and template problems, Defold editor no-ops, rewards not granted, platform rejections such as ads without gameplayStop or an unbundled SDK, and Jest specifics (ads that always report no fill, saving on exit, the loading timeout, launch data, the registration prompt). Each answer points at the tool that resolves it (detect_sdk, get_install_instructions, get_compliance_rule, validate_integration), or at where to look next when nothing matches.

Sign in to the Yes2 dashboard so dashboard tools (upload, edit games) work; only needed for those tools. Call it when the user asks to sign in to Yes2, or after a dashboard tool answered that they are not signed in: the client then opens the Yes2 sign-in in the browser and retries. Already signed in (or with an API key), it reports who the user is, the studio and the scopes. The docs and validation tools never need it.

The games in the caller's studio on the Yes2 dashboard, newest first, with each game's id, engine and build count. The id is the gameId that prepare_upload, finalize_upload and get_build_status take; a game that is not listed yet comes from create_game. Acts as the signed-in Yes2 dashboard user. Sign-in is opt-in and only needed for the dashboard tools, never for the docs tools: call sign_in (or in Claude Code run /mcp → Authenticate, in Codex `codex mcp login yes2sdk`), or provide an API key instead (a y2g_ personal key from Dashboard → Settings, sent as the bare key in X-Yes2-Api-Key, or for the local stdio server the YES2_API_KEY env var). Without either it returns the sign-in steps. The credential is passed through to the dashboard and never stored.

Creates a game in the caller's studio on the Yes2 dashboard and returns its id, the gameId for uploading builds. Each call makes a new game, so list_games is the way to check whether it already exists. Acts as the signed-in Yes2 dashboard user. Sign-in is opt-in and only needed for the dashboard tools, never for the docs tools: call sign_in (or in Claude Code run /mcp → Authenticate, in Codex `codex mcp login yes2sdk`), or provide an API key instead (a y2g_ personal key from Dashboard → Settings, sent as the bare key in X-Yes2-Api-Key, or for the local stdio server the YES2_API_KEY env var). Without either it returns the sign-in steps. The credential is passed through to the dashboard and never stored.

Step 2 of uploading a build to the Yes2 dashboard: reserves the version and returns an uploadId, an expiry, and a ready-to-run curl command that PUTs the zip to a presigned storage URL. The URL is signed to the exact size given, so the size has to be the zip's byte count: `stat -f%z build.zip` on macOS, `stat -c%s build.zip` on Linux. This server never reads the zip; the curl command runs on the user's machine. Upload flow: (1) zip the built game with index.html at the root of the zip, not inside a folder; (2) prepare_upload with the zip's exact size in bytes; (3) the returned curl command PUTs the zip from the user's machine straight to storage; (4) finalize_upload; (5) get_build_status every few seconds until the status is ready or failed. Acts as the signed-in Yes2 dashboard user. Sign-in is opt-in and only needed for the dashboard tools, never for the docs tools: call sign_in (or in Claude Code run /mcp → Authenticate, in Codex `codex mcp login yes2sdk`), or provide an API key instead (a y2g_ personal key from Dashboard → Settings, sent as the bare key in X-Yes2-Api-Key, or for the local stdio server the YES2_API_KEY env var). Without either it returns the sign-in steps. The credential is passed through to the dashboard and never stored.

Step 4 of uploading a build to the Yes2 dashboard, after the curl PUT has succeeded: tells the dashboard the zip is in storage so it can check, analyse and register the build. Processing continues after this returns, and calling it again is safe and reports the current status. Upload flow: (1) zip the built game with index.html at the root of the zip, not inside a folder; (2) prepare_upload with the zip's exact size in bytes; (3) the returned curl command PUTs the zip from the user's machine straight to storage; (4) finalize_upload; (5) get_build_status every few seconds until the status is ready or failed. Acts as the signed-in Yes2 dashboard user. Sign-in is opt-in and only needed for the dashboard tools, never for the docs tools: call sign_in (or in Claude Code run /mcp → Authenticate, in Codex `codex mcp login yes2sdk`), or provide an API key instead (a y2g_ personal key from Dashboard → Settings, sent as the bare key in X-Yes2-Api-Key, or for the local stdio server the YES2_API_KEY env var). Without either it returns the sign-in steps. The credential is passed through to the dashboard and never stored.

Step 5 of uploading a build to the Yes2 dashboard: the status of an upload (gameId + uploadId: pending, processing, ready or failed) or of an existing build (gameId + buildId). When ready it returns the build id, the detected engine, upload warnings, bundle errors and the Inspector link where the user can play and QA the build. While processing, polling every few seconds is expected. Upload flow: (1) zip the built game with index.html at the root of the zip, not inside a folder; (2) prepare_upload with the zip's exact size in bytes; (3) the returned curl command PUTs the zip from the user's machine straight to storage; (4) finalize_upload; (5) get_build_status every few seconds until the status is ready or failed. Acts as the signed-in Yes2 dashboard user. Sign-in is opt-in and only needed for the dashboard tools, never for the docs tools: call sign_in (or in Claude Code run /mcp → Authenticate, in Codex `codex mcp login yes2sdk`), or provide an API key instead (a y2g_ personal key from Dashboard → Settings, sent as the bare key in X-Yes2-Api-Key, or for the local stdio server the YES2_API_KEY env var). Without either it returns the sign-in steps. The credential is passed through to the dashboard and never stored.

Changes a game's details on the Yes2 dashboard: name, description, engine, category, tags, orientation, the Yandex Metrica counter and the Jest auto-login reminders. Only the fields given are touched, and at least one is required. null clears description, engine, category or yandexMetricaCounterId; tags replaces the whole list ([] clears it). The icon and banner are set with set_game_image, a build's display name with rename_build. Acts as the signed-in Yes2 dashboard user. Sign-in is opt-in and only needed for the dashboard tools, never for the docs tools: call sign_in (or in Claude Code run /mcp → Authenticate, in Codex `codex mcp login yes2sdk`), or provide an API key instead (a y2g_ personal key from Dashboard → Settings, sent as the bare key in X-Yes2-Api-Key, or for the local stdio server the YES2_API_KEY env var). Without either it returns the sign-in steps. The credential is passed through to the dashboard and never stored.

Sets or removes a game's icon or banner on the Yes2 dashboard. Setting one: give the image's exact size in bytes (`stat -f%z <file>` on macOS, `stat -c%s <file>` on Linux) and its type, as contentType or as imagePath (the type comes from the extension). It returns an uploadId and a ready-to-run curl command that PUTs the file from the user's machine to a presigned storage URL; the command carries no credential, and this server never reads the file. After the PUT succeeds, finalize_image_upload stores it. PNG, JPEG or WebP, at most 15 MB; no dimensions are enforced; the new image replaces the current one. With remove: true it deletes the current image directly instead. Image flow: (1) set_game_image with the image's exact size in bytes and its type (contentType, or imagePath to derive it from the extension); (2) the returned curl command PUTs the file from the user's machine straight to storage, within 10 minutes; (3) finalize_image_upload with the uploadId. Acts as the signed-in Yes2 dashboard user. Sign-in is opt-in and only needed for the dashboard tools, never for the docs tools: call sign_in (or in Claude Code run /mcp → Authenticate, in Codex `codex mcp login yes2sdk`), or provide an API key instead (a y2g_ personal key from Dashboard → Settings, sent as the bare key in X-Yes2-Api-Key, or for the local stdio server the YES2_API_KEY env var). Without either it returns the sign-in steps. The credential is passed through to the dashboard and never stored.

Last step of setting a game's icon or banner, after the curl PUT from set_game_image has succeeded: the dashboard checks the image and makes it the game's icon or banner. Calling it again is safe. Image flow: (1) set_game_image with the image's exact size in bytes and its type (contentType, or imagePath to derive it from the extension); (2) the returned curl command PUTs the file from the user's machine straight to storage, within 10 minutes; (3) finalize_image_upload with the uploadId. Acts as the signed-in Yes2 dashboard user. Sign-in is opt-in and only needed for the dashboard tools, never for the docs tools: call sign_in (or in Claude Code run /mcp → Authenticate, in Codex `codex mcp login yes2sdk`), or provide an API key instead (a y2g_ personal key from Dashboard → Settings, sent as the bare key in X-Yes2-Api-Key, or for the local stdio server the YES2_API_KEY env var). Without either it returns the sign-in steps. The credential is passed through to the dashboard and never stored.

Sets a build's display name on the Yes2 dashboard, the label shown instead of the zip file name. Up to 100 characters, trimmed; null or a blank name clears it back to the zip file name. Acts as the signed-in Yes2 dashboard user. Sign-in is opt-in and only needed for the dashboard tools, never for the docs tools: call sign_in (or in Claude Code run /mcp → Authenticate, in Codex `codex mcp login yes2sdk`), or provide an API key instead (a y2g_ personal key from Dashboard → Settings, sent as the bare key in X-Yes2-Api-Key, or for the local stdio server the YES2_API_KEY env var). Without either it returns the sign-in steps. The credential is passed through to the dashboard and never stored.

概要

Yes2SDK MCP Server とは?

Yes2SDK MCP Server は Yes2Games が公式にホストする MCP サーバーで、AI コーディングアシスタントに Yes2SDK のドキュメント、API リファレンス、プラットフォームのコンプライアンスルール、ビルドバリデーターへのライブアクセスを提供します。サインインや API キーは不要です。

Yes2SDK は、Unity、Defold、または素の JavaScript で作った HTML5 ゲームを Poki、CrazyGames、Yandex Games、YouTube Playables、GameDistribution、Jest などのウェブゲームプラットフォームに配信するための単一の SDK です。Yes2Games は、Claude Code、Cursor、Windsurf、VS Code Copilot などのアシスタントの助けを借りて SDK を統合する開発者向けにこの MCP サーバーを用意しました。アシスタントは必要なときに正確な API リファレンス、クイックスタート、プラットフォームルールを取得し、各プラットフォームが実際に適用するリジェクトルールでビルドをチェックできます。

Yes2SDK MCP Server の使い方

ホスト型サーバーは https://mcp.yes2games.com/mcp にあり、Streamable HTTP で通信します。ビルドや実行の必要はなく、認証もありません。

Claude Code

Yes2Games によると、最も手早い方法はこのサーバーを自動登録する Claude Code プラグインです。手動で追加する場合は次のとおりです。

claude mcp add --transport http yes2sdk https://mcp.yes2games.com/mcp

/mcp を実行して yes2sdk サーバーが表示されることを確認します。

Claude Desktop と claude.ai

カスタムコネクタを追加し(Settings → Connectors → Add custom connector)、URL に https://mcp.yes2games.com/mcp を貼り付けます。サインインの手順はありません。

Cursor

~/.cursor/mcp.json またはプロジェクトの .cursor/mcp.json にエントリを追加します。Yes2SDK のドキュメントでは次の形式が示されています。

{
  "mcpServers": {
    "yes2sdk": {
      "type": "http",
      "url": "https://mcp.yes2games.com/mcp"
    }
  }
}

VS Code

.vscode/mcp.json に次のように記述します。

{
  "servers": {
    "yes2sdk": {
      "type": "http",
      "url": "https://mcp.yes2games.com/mcp"
    }
  }
}

ローカルで実行(代替手段)

stdio でサーバーを自分で動かしたい場合のために、Yes2Games は npm パッケージを公開しています。

{
  "mcpServers": {
    "yes2sdk": {
      "command": "npx",
      "args": ["-y", "@yes2games/yes2sdk-mcp"]
    }
  }
}

Yes2SDK MCP Server の主な機能

  • Yes2Games の公式サーバーで、mcp.yes2games.com でホストされ、アカウントもキーも不要
  • Unity、Defold、JavaScript ゲーム向けのバージョン固定のインストール手順
  • Poki、CrazyGames、Yandex Games、GameDistribution、YouTube Playables、Jest の完全なクイックスタートガイド
  • ads、analytics、auth、banners、data、leaderboard、IAP など、すべての SDK モジュールの正確なメソッドシグネチャ
  • プラットフォームのリジェクトルールに基づくアップロード前のビルド検証(FAIL/WARN/INFO で報告)
  • isSupported() によるガードが必要な機能がわかる、プラットフォーム × モジュールの対応表
  • よくある統合トラブルを症状から調べるトラブルシューティング

Yes2SDK MCP Server のツール

プローブでは 11 個のツールが返され、4 つのグループに分けられます。

  • セットアップ:get_install_instructions は Unity、Defold、JS プロジェクトに SDK を追加するバージョン固定の手順を返し、プロジェクトを変更することはありません。detect_sdk はプロジェクトのエンジン、SDK がインストール済みかどうか、残りのインストール手順を報告します。ホスト型サーバーでは関連ファイル(package.json や Packages/manifest.json など)をインラインで渡し、ローカルサーバーでは projectPath を読み取れます。
  • ドキュメント:search_docs はキーワード検索を行い、上位 5 件のセクションを返します。get_quickstart は 1 つのプラットフォームのガイドを、get_api_reference は 1 つのモジュールのリファレンスを返します。list_sdk_modules はモジュールの一覧を返します。
  • コンプライアンス:get_platform_requirements はプラットフォームのルールを一覧表示します。get_compliance_rule は P-002 などの ID でルールとその修正方法を説明します。get_platform_capabilities は各プラットフォームでどのモジュールが Ready または Partial かを示します。たとえば Friends は CrazyGames のみで、Poki では banners が提供されません。
  • 検証とデバッグ:validate_integration は対象プラットフォームに対してビルドを評価します。ホスト型サーバーはディスクにアクセスできないため、indexHtml やファイル一覧などのインラインコンテンツを渡します。troubleshoot はエラー文字列や症状から考えられる原因と順序立てた修正方法を示します。

Yes2SDK MCP Server のユースケース

  • 統合の開始:「この Unity プロジェクトに Yes2SDK を追加して、WebGL テンプレートを設定して。」
  • プラットフォームの準備:「このゲームを CrazyGames に提出する前に何を押さえておくべき?」
  • アップロード前チェック:「このビルドの index.html を Poki 向けに検証して、リジェクトされそうな点を教えて。」
  • 機能のガード:「Yandex はどの Yes2SDK モジュールに対応している?isSupported() でガードすべき呼び出しは?」
  • デバッグ:「JS ビルドで window.Yes2SDK が undefined になる。原因は?」

Yes2SDK MCP Server のトラブルシューティング

  • サーバーが表示されない:Claude Code で /mcp を実行し、yes2sdk があるか確認します。なければ上の claude mcp add コマンドを再実行します。
  • SDK を使ったコードがコンパイルできない:インストール手順が完了するまで、Yes2SDK 名前空間(Unity)、yes2sdk モジュール(Defold)、window.Yes2SDK(JS)への参照は解決されません。アシスタントに detect_sdk、続いて get_install_instructions を実行させてください。
  • バリデーターがビルドを読めない:ホスト型サーバーにはディスクアクセスがありません。インラインコンテンツを渡すか、ローカルの @yes2games/yes2sdk-mcp パッケージを実行して buildPath を使います。
  • 見覚えのないルール ID が出た:アシスタントに get_compliance_rule で重大度と修正方法を調べさせます。

よくある質問

1

Yes2SDK MCP Server は公式ですか?

はい。Yes2Games が開発者ポータル developer.yes2games.com/docs/mcp-server で文書化し、`mcp.yes2games.com` でホストしています。

2

利用に API キーやアカウントは必要ですか?

いいえ。プローブでは認証なしで接続してツール一覧を取得でき、セットアップ手順にもキーやヘッダーはありません。

3

どのゲームエンジンとプラットフォームに対応していますか?

ツールは Unity、Defold、JavaScript のプロジェクトに対応します。プラットフォームは Poki、CrazyGames、Yandex Games、GameDistribution、YouTube Playables、Jest で、対応表には Yes2Games ポータルも含まれます。

4

プロジェクトのファイルを変更しますか?

いいえ。`get_install_instructions` はテキストを返すだけで、プロジェクトを変更しません。ホスト型サーバーでは、ツールはインラインで渡した内容だけを扱います。

5

ホスト型とローカル版の違いは何ですか?

`https://mcp.yes2games.com/mcp` のホスト型サーバーはセットアップ不要ですが、ディスクにはアクセスできません。ローカルの npm パッケージは stdio で動作し、パスを指定してプロジェクトやビルドフォルダを読み取れます。

6

Claude Code、Cursor、VS Code で使えますか?

はい。Yes2SDK のドキュメントには Claude Code、Cursor、Windsurf、VS Code Copilot が記載されています。Claude Code ユーザーは、サーバーを登録してくれる Yes2SDK Claude Code プラグインも利用できます。

7

Yes2SDK のリモート MCP サーバーとは何ですか?

Yes2SDK のリモート MCP サーバーは、https://mcp.yes2games.com/mcp にホストされた Model Context Protocol エンドポイントです。AI アシスタントはローカルに何もインストール・実行することなく接続できます。

8

Yes2SDK の MCP サーバーにはどう接続しますか?

エンドポイント https://mcp.yes2games.com/mcp を Claude Code、Cursor、VS Code など任意の MCP 対応クライアントに追加してください。このページのセットアップ手順で各クライアントを一度に設定できます。

9

Yes2SDK の MCP サーバーは認証が必要ですか?

この掲載では Yes2SDK の認証要件がまだ確認されていません。接続前に提供元のドキュメントをご確認ください。

10

Yes2SDK の MCP サーバーはどのトランスポートを使用しますか?

Yes2SDK は streamable-http エンドポイントを公開しており、これはリモート MCP サーバーで広く使われ、主要な MCP クライアントがサポートするトランスポートです。

コメント