Yes2SDK

Measured conclusion: Deep-tested. L2 outcome: tools_ok.

Hosted MCP server that gives AI coding assistants the Yes2SDK docs, platform compliance rules and a build validator.

Add to your agent

Copy this into your MCP client config:

{
  "mcpServers": {
    "Yes2SDK": {
      "url": "https://mcp.yes2games.com/mcp",
      "transport": "streamable-http"
    }
  }
}

Measured tools (21)

• get_install_instructions read-only

  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.

  Parameters:

  • engine (required) — string — Target engine: 'unity' (UPM package), 'defold' (native extension), or 'js' (any HTML5 JavaScript/TypeScript game, including Phaser and three.js: the @yes2games/js npm package, with the SDK itself injected by the dashboard at upload).
  • platform — string — Optional target platform. Install is the same across platforms; this only adds a context note.

  Hints: read-only yes · destructive no · idempotent yes · open-world no

• detect_sdk read-only

  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.

  Parameters:

  • files — object — Inline map of repo-relative path → file contents for hosted/sandboxed use. Include at least the engine-marker files: game.project (Defold), ProjectSettings/* and Packages/manifest.json (Unity), or package.json (JS). For JS also include the lockfile, vite.config.*, index.html and the entry sources so the remaining steps can be tailored.
  • projectPath — string — Absolute path to the root of the game project to inspect (local stdio mode only).

  Hints: read-only yes · destructive no · idempotent yes · open-world no

• search_docs read-only

  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.

  Parameters:

  • query (required) — string — Keywords to search for, e.g. 'rewarded ad reward callback' or 'poki gameplayStop'.

  Hints: read-only yes · destructive no · idempotent yes · open-world no

• get_quickstart read-only

  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").

  Parameters:

  • platform (required) — string — Target platform.

  Hints: read-only yes · destructive no · idempotent yes · open-world no

• get_api_reference read-only

  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.

  Parameters:

  • module (required) — string — API module name.

  Hints: read-only yes · destructive no · idempotent yes · open-world no

• list_sdk_modules read-only

  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.

  Hints: read-only yes · destructive no · idempotent yes · open-world no

• validate_integration read-only

  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.

  Parameters:

  • platform (required) — string — Target platform to validate against.
  • fileList — array — Inline static mode: a flat list of file paths in the build, relative to index.html (engine detection, the Poki index.json check, and matching root-absolute paths in jsContents).
  • buildPath — string — Absolute path to an already-extracted (unzipped) build folder for static checks (local stdio mode only — the hosted server cannot read disk).
  • indexHtml — string — Inline static mode: the contents of the build's index.html.
  • jsContents — array — Inline static mode: the contents of the build's JavaScript files. Required to verify SDK integration inline; also scanned for a bundled SDK copy, a bundled mock, the canvas marker and root-absolute paths.
  • eventLogJson — string — JSON string: an exported Yes2SDK Inspector event log (array of LogEntry) for behavioral compliance checks.

  Hints: read-only yes · destructive no · idempotent yes · open-world no

• get_platform_requirements read-only

  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.

  Parameters:

  • platform (required) — string — Target platform.

  Hints: read-only yes · destructive no · idempotent yes · open-world no

• get_platform_capabilities read-only

  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).

  Parameters:

  • module — string — Optional: restrict to modules whose name contains this text (e.g. 'ads', 'player'). Omit for all modules.
  • platform — string — Optional: restrict to one platform's column. Omit for the full matrix.

  Hints: read-only yes · destructive no · idempotent yes · open-world no

• get_compliance_rule read-only

  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.

  Parameters:

  • ruleId (required) — string — Rule id, e.g. 'P-002' (Poki), 'U-001' (universal), 'CG-003' (CrazyGames), 'Y-010' (Yandex), 'GD-002' (GameDistribution), 'YT-001' (YouTube), 'J-001' (Jest). Case-insensitive.

  Hints: read-only yes · destructive no · idempotent yes · open-world no

• troubleshoot read-only

  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.

  Parameters:

  • symptom (required) — string — The error message or a short description of what is going wrong, e.g. "namespace Yes2SDK could not be found" or "rewarded ad gave no reward".

  Hints: read-only yes · destructive no · idempotent yes · open-world no

• sign_in read-only

  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. Calling it does not open a browser by itself; after calling it, tell the user the step for their client. In Claude Code: run /mcp, pick the Yes2SDK server and choose Authenticate (the dashboard opens in the browser). Until Authenticate finishes, Claude Code pauses all of this server's tools, docs included; Disable then Enable on the server in /mcp reverts it to anonymous use without signing in. In claude.ai: a Connect card appears for the user to click. In Codex: the user runs `codex mcp login yes2sdk`. 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.

  Hints: read-only yes · destructive no · idempotent yes · open-world yes

• list_games read-only

  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, then in Claude Code the user runs /mcp, picks the Yes2SDK server and chooses Authenticate (in claude.ai a Connect card appears; in Codex the user runs `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.

  Hints: read-only yes · destructive no · idempotent yes · open-world yes

• create_game

  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, then in Claude Code the user runs /mcp, picks the Yes2SDK server and chooses Authenticate (in claude.ai a Connect card appears; in Codex the user runs `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.

  Parameters:

  • name (required) — string — Game name as studios and reviewers will see it.
  • engine — string — Engine: 'unity', 'defold', 'playcanvas', 'cocos', 'vanilla' (any JavaScript/TypeScript game: plain JS, Phaser, three.js) or 'other'.
  • description — string — Optional short description of the game.
  • orientation — string — 'portrait', 'landscape' or 'both'. The dashboard defaults to 'both'.

  Hints: read-only no · destructive no · idempotent no · open-world yes

• prepare_upload

  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. Preview accounts: unlimited games; one build per game, and a new upload replaces the previous one unless that build is in review or live. For a preview account, tell the user before uploading that the new build replaces the game's current one. 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, then in Claude Code the user runs /mcp, picks the Yes2SDK server and chooses Authenticate (in claude.ai a Connect card appears; in Codex the user runs `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.

  Parameters:

  • gameId (required) — string — Game id from list_games or create_game.
  • version (required) — string — Build version, free-form (e.g. '1.4.2' or '2026.10.23-nightly'). Unique per game.
  • size (required) — integer — Exact size of the zip in bytes. Max 500 MB.
  • name — string — Optional display name for the build.
  • notes — string — Optional release notes shown on the build.
  • zipPath — string — Optional local path of the zip on the user's machine, filled into the curl command. Omitted, the command carries a <path/to/build.zip> placeholder.

  Hints: read-only no · destructive no · idempotent no · open-world yes

• finalize_upload

  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, then in Claude Code the user runs /mcp, picks the Yes2SDK server and chooses Authenticate (in claude.ai a Connect card appears; in Codex the user runs `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.

  Parameters:

  • gameId (required) — string — Game id the upload was prepared for.
  • uploadId (required) — string — uploadId returned by prepare_upload.

  Hints: read-only no · destructive no · idempotent yes · open-world yes

• get_build_status read-only

  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, then in Claude Code the user runs /mcp, picks the Yes2SDK server and chooses Authenticate (in claude.ai a Connect card appears; in Codex the user runs `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.

  Parameters:

  • gameId (required) — string — Game id.
  • buildId — string — Id of an existing build. Give this or uploadId.
  • uploadId — string — uploadId from prepare_upload. Give this or buildId.

  Hints: read-only yes · destructive no · idempotent yes · open-world yes

• update_game

  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, then in Claude Code the user runs /mcp, picks the Yes2SDK server and chooses Authenticate (in claude.ai a Connect card appears; in Codex the user runs `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.

  Parameters:

  • gameId (required) — string — Game id from list_games or create_game.
  • name — string — New game name. Cannot be blank.
  • tags — array — The full tag list, replacing the current one: up to 20 tags of up to 50 characters each. [] clears it.
  • engine — 'unity', 'defold', 'playcanvas', 'cocos', 'vanilla' (any JavaScript/TypeScript game) or 'other'. null clears it.
  • category — Category, up to 100 characters (e.g. 'Action'). null clears it.
  • description — ['string', 'null'] — New description, trimmed by the dashboard. null clears it.
  • orientation — string — 'portrait', 'landscape' or 'both'.
  • jestAutoLoginReminders — boolean — Whether the Jest bundle shows its auto-login reminders.
  • yandexMetricaCounterId — Yandex Metrica counter id used by the Yandex bundle, a positive integer. null clears it.

  Hints: read-only no · destructive no · idempotent yes · open-world yes

• set_game_image destructive

  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, then in Claude Code the user runs /mcp, picks the Yes2SDK server and chooses Authenticate (in claude.ai a Connect card appears; in Codex the user runs `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.

  Parameters:

  • gameId (required) — string — Game id from list_games or create_game.
  • kind (required) — string — 'icon' or 'banner'.
  • size — integer — Exact size of the image file in bytes, at most 15728640 (15 MB). Required unless remove is true.
  • remove — boolean — true deletes the current icon or banner instead of preparing an upload.
  • imagePath — string — Optional local path of the image on the user's machine (.png, .jpg, .jpeg or .webp), filled into the curl command and used for the type. Omitted, the command carries a placeholder.
  • contentType — string — The image's type: image/png, image/jpeg or image/webp. Omit it when imagePath is given; the extension decides.

  Hints: read-only no · destructive yes · idempotent no · open-world yes

• finalize_image_upload

  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, then in Claude Code the user runs /mcp, picks the Yes2SDK server and chooses Authenticate (in claude.ai a Connect card appears; in Codex the user runs `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.

  Parameters:

  • gameId (required) — string — Game id the image upload was prepared for.
  • uploadId (required) — string — uploadId returned by set_game_image.

  Hints: read-only no · destructive no · idempotent yes · open-world yes

• rename_build

  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, then in Claude Code the user runs /mcp, picks the Yes2SDK server and chooses Authenticate (in claude.ai a Connect card appears; in Codex the user runs `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.

  Parameters:

  • gameId (required) — string — Game id the build belongs to.
  • buildId (required) — string — Build id, from get_build_status once an upload is ready.
  • name (required) — New display name, up to 100 characters after trimming. null or blank clears it.

  Hints: read-only no · destructive no · idempotent yes · open-world yes

Measured by MCPYP probing. Untested fields are omitted, never estimated. Listing is always free; MCPYP never proxies calls or stores user tokens.