MCP.so
Sign In

Yes2SDK MCP Server

@Yes2SDK

Basic information

Transport

streamable-http

Authentication

Check provider docs

Category

Developer Tools

Author

Yes2SDK

About Yes2SDK MCP Server

The Yes2SDK MCP Server is the official hosted server from Yes2Games for developers shipping HTML5 games to Poki, CrazyGames, Yandex Games, YouTube Playables, GameDistribution and Jest. It gives an AI assistant the SDK's quickstarts, API reference and platform rules, and checks a build against platform rejection rules.

Connection details

https://mcp.yes2games.com/mcp

Setup

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

Yes2SDK MCP Server tools

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.

Overview

What is Yes2SDK MCP Server?

The Yes2SDK MCP Server is the official hosted MCP server from Yes2Games that gives your AI coding assistant live access to the Yes2SDK docs, API reference, platform-compliance rules and a build validator. It needs no sign-in or API key.

Yes2SDK is a single SDK for shipping HTML5 games built with Unity, Defold or plain JavaScript to web game platforms such as Poki, CrazyGames, Yandex Games, YouTube Playables, GameDistribution and Jest. Yes2Games built the MCP server for developers who integrate the SDK with help from an assistant such as Claude Code, Cursor, Windsurf or VS Code Copilot. The assistant can pull the exact API reference, quickstart and platform rules when it needs them, then check a build against the same rejection rules each platform enforces.

How to use Yes2SDK MCP Server?

The hosted server lives at https://mcp.yes2games.com/mcp and speaks Streamable HTTP. There is nothing to build or run, and no authentication.

Claude Code

Yes2Games says the fastest path is its Claude Code plugin, which registers this server for you. To add the server by hand:

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

Run /mcp to confirm that the yes2sdk server is listed.

Claude Desktop and claude.ai

Add a custom connector (Settings → Connectors → Add custom connector) and paste https://mcp.yes2games.com/mcp as the URL. No sign-in step is needed.

Cursor

Add an entry to ~/.cursor/mcp.json or the project's .cursor/mcp.json. The Yes2SDK docs give this shape:

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

VS Code

In .vscode/mcp.json:

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

Run locally (alternative)

If you would rather run the server yourself over stdio, Yes2Games publishes an npm package:

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

Key features of Yes2SDK MCP Server

  • Official server from Yes2Games, hosted at mcp.yes2games.com, with no account or key required
  • Version-pinned install steps for Unity, Defold and JavaScript games
  • Full quickstart guides for Poki, CrazyGames, Yandex Games, GameDistribution, YouTube Playables and Jest
  • Exact method signatures for every SDK module, including ads, analytics, auth, banners, data, leaderboard, IAP and more
  • Pre-upload build validation against platform rejection rules, with FAIL/WARN/INFO findings
  • A platform-by-module support matrix that shows when a feature needs an isSupported() guard
  • Symptom-based troubleshooting for common integration failures

Yes2SDK MCP Server tools

The probe returned 11 tools, in four groups:

  • Setup: get_install_instructions returns version-pinned steps to add the SDK to a Unity, Defold or JS project. It never modifies the project. detect_sdk reports the project's engine, whether the SDK is installed, and which install steps remain. On the hosted server you pass the relevant files inline (for example package.json or Packages/manifest.json). A local server can read a projectPath instead.
  • Docs: search_docs runs a keyword search and returns the top five matching sections. get_quickstart returns the guide for one platform, and get_api_reference returns one module's reference. list_sdk_modules lists the modules.
  • Compliance: get_platform_requirements lists a platform's rules. get_compliance_rule explains one rule by ID, such as P-002, and how to fix it. get_platform_capabilities shows which modules are Ready or Partial on each platform. For example, Friends is CrazyGames-only and banners are not offered on Poki.
  • Validation and debugging: validate_integration grades a build for a target platform. The hosted server cannot access your disk, so you pass inline content such as indexHtml and a file list. troubleshoot maps an error string or symptom to a likely cause and ordered fixes.

Use cases of Yes2SDK MCP Server

  • Starting an integration: "Add the Yes2SDK to this Unity project and set up the WebGL template."
  • Platform prep: "What do I have to get right before submitting this game to CrazyGames?"
  • Pre-upload check: "Validate this build's index.html for Poki and tell me what would get it rejected."
  • Feature guarding: "Which Yes2SDK modules does Yandex support, and which calls need an isSupported() guard?"
  • Debugging: "window.Yes2SDK is undefined in my JS build. What's wrong?"

Troubleshooting Yes2SDK MCP Server

  • Server not listed: In Claude Code, run /mcp and check that yes2sdk appears. If it doesn't, re-run the claude mcp add command above.
  • Code won't compile against the SDK: Until the install steps finish, references to the Yes2SDK namespace (Unity), the yes2sdk module (Defold) or window.Yes2SDK (JS) won't resolve. Ask the assistant to run detect_sdk, then get_install_instructions.
  • Validator can't read your build: The hosted server has no disk access. Pass inline content, or run the local @yes2games/yes2sdk-mcp package and use buildPath.
  • A rule ID you don't recognize: Ask the assistant to look it up with get_compliance_rule for its severity and fix.

Frequently asked questions

1

Is the Yes2SDK MCP Server official?

Yes. Yes2Games documents it on its developer portal at developer.yes2games.com/docs/mcp-server and hosts it at `mcp.yes2games.com`.

2

Do I need an API key or account to use it?

No. The probe connected and listed tools without authentication, and the setup docs show no key or header.

3

Which game engines and platforms does it cover?

The tools cover Unity, Defold and JavaScript projects. The platforms are Poki, CrazyGames, Yandex Games, GameDistribution, YouTube Playables and Jest, plus the Yes2Games portal in the capabilities matrix.

4

Can it modify my project files?

No. `get_install_instructions` returns text and never modifies the project. Over the hosted server, the tools work only on content you pass inline.

5

What is the difference between the hosted and local server?

The hosted server at `https://mcp.yes2games.com/mcp` needs no setup but has no disk access. The local npm package runs over stdio and can read project and build folders by path.

6

Does it work with Claude Code, Cursor and VS Code?

Yes. The Yes2SDK docs list Claude Code, Cursor, Windsurf and VS Code Copilot. Claude Code users can also install the Yes2SDK Claude Code plugin, which registers the server.

7

What is the Yes2SDK remote MCP server?

The Yes2SDK remote MCP server is a hosted Model Context Protocol endpoint at https://mcp.yes2games.com/mcp, so AI assistants can connect to it without installing or running anything locally.

8

How do I connect to the Yes2SDK MCP server?

Add the endpoint https://mcp.yes2games.com/mcp to any MCP-compatible client such as Claude Code, Cursor, or VS Code. The setup snippets on this page configure each client in one step.

9

Does the Yes2SDK MCP server require authentication?

Authentication requirements for Yes2SDK have not been confirmed in this listing. Check the provider’s documentation before connecting.

10

Which transport does the Yes2SDK MCP server use?

Yes2SDK exposes a streamable-http endpoint, the transport used by remote MCP servers and supported by all major MCP clients.

Comments