MCP.so
登录

Yes2SDK MCP Server

@Yes2SDK

基本信息

传输方式

streamable-http

认证方式

请查阅提供方文档

分类

开发工具

作者

Yes2SDK

关于 Yes2SDK MCP Server

Yes2SDK MCP Server 是 Yes2Games 官方托管的服务器,面向将 HTML5 游戏发布到 Poki、CrazyGames、Yandex Games、YouTube Playables、GameDistribution 和 Jest 的开发者。它为 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 Key。

Yes2SDK 是一个统一的 SDK,用于把基于 Unity、Defold 或纯 JavaScript 开发的 HTML5 游戏发布到 Poki、CrazyGames、Yandex Games、YouTube Playables、GameDistribution 和 Jest 等网页游戏平台。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),将 https://mcp.yes2games.com/mcp 粘贴为 URL。无需登录步骤。

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 的完整快速入门指南
  • 每个 SDK 模块的准确方法签名,包括 ads、analytics、auth、banners、data、leaderboard、IAP 等
  • 按平台拒审规则进行上传前构建验证,输出 FAIL/WARN/INFO 结果
  • 平台与模块的支持矩阵,说明哪些功能需要用 isSupported() 做保护
  • 基于症状的常见集成故障排查

Yes2SDK MCP Server 工具

探测共返回 11 个工具,分为四组:

  • 安装:get_install_instructions 返回为 Unity、Defold 或 JS 项目添加 SDK 的版本锁定步骤,从不修改项目。detect_sdk 报告项目使用的引擎、SDK 是否已安装以及剩余的安装步骤。在托管服务器上需以内联方式传入相关文件(例如 package.json 或 Packages/manifest.json),本地服务器则可以读取 projectPath。
  • 文档:search_docs 执行关键词搜索,返回最匹配的五个章节。get_quickstart 返回某个平台的指南,get_api_reference 返回某个模块的参考。list_sdk_modules 列出所有模块。
  • 合规:get_platform_requirements 列出某平台的规则。get_compliance_rule 按 ID(如 P-002)解释一条规则及修复方法。get_platform_capabilities 显示各平台上哪些模块为 Ready 或 Partial,例如 Friends 仅支持 CrazyGames,Poki 不提供 banners。
  • 验证与调试:validate_integration 针对目标平台为构建打分。托管服务器无法访问你的磁盘,因此需传入 indexHtml 和文件列表等内联内容。troubleshoot 将错误字符串或症状映射到可能原因和按顺序的修复步骤。

Yes2SDK MCP Server 的使用场景

  • 开始集成:“把 Yes2SDK 添加到这个 Unity 项目,并设置 WebGL 模板。”
  • 平台准备:“把这款游戏提交到 CrazyGames 之前,我必须做好哪些事?”
  • 上传前检查:“针对 Poki 验证这个构建的 index.html,告诉我哪些地方会导致被拒。”
  • 功能保护:“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 Key 或账号吗?

不需要。探测时无需认证即可连接并列出工具,安装文档中也没有任何密钥或请求头。

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 服务器是一个托管的 Model Context Protocol 端点,地址是 https://mcp.yes2games.com/mcp,AI 助手无需在本地安装或运行任何东西即可连接。

8

怎么连接 Yes2SDK 的 MCP 服务器?

把端点 https://mcp.yes2games.com/mcp 添加到任意支持 MCP 的客户端,比如 Claude Code、Cursor 或 VS Code。本页的接入代码块可以一步配置好每个客户端。

9

Yes2SDK 的 MCP 服务器需要认证吗?

此收录尚未确认 Yes2SDK 的认证要求。连接前请查阅提供方文档。

10

Yes2SDK 的 MCP 服务器用的是哪种传输方式?

Yes2SDK 暴露的是 streamable-http 端点,这是远程 MCP 服务器普遍使用、主流客户端都支持的传输方式。

评论