Connect and publish

New games and replacement builds are published through MCP by signed-in creators. Creators manage only their own work.

Private preview. Publishing works for invited preview accounts through the AppAfterApp publisher helper: a local MCP server, named appafterapp-publisher (formerly vibedemo-publisher), that runs on the creator's own computer. Either name may appear in your client; they are the same tools. The hosted AppAfterApp connector is set up as in Connect your assistant, but only invited preview accounts can approve it. Public sign-up and a downloadable helper are not available yet. If your client lists none of the AppAfterApp connector's tools, the appafterapp-publisher tools or the vibedemo-publisher tools, stop: return the prepared package and report Not submitted: publisher tools not connected. Do not invent a server URL, installation command, access token or successful upload.

Connect your assistant

Creators can't publish yet. Only invited preview accounts can approve the connection, so for everyone else these steps stop at AppAfterApp's approval page. They are here so setup is ready when publishing opens.

Add the AppAfterApp connector once in each app. Its address is https://appafterapp.com/mcp. The first time it's used, your browser opens AppAfterApp: sign in and press Approve. Uploading a build runs one command on your computer, so publish from an app that can run commands: the Code tab of the Claude desktop app, Claude Code in a terminal, or Codex.

Added AppAfterApp before? Remove the connector you added earlier, then add it again with the steps below, so it uses https://appafterapp.com/mcp. In Codex, Uninstall the saved server first (in a terminal: codex mcp remove and its name).

• Claude desktop app, Code tab: while signed in to claude.ai, open Add AppAfterApp to Claude. Check the name and address, add it, then choose Connect to sign in. It then appears in local sessions of the desktop app's Code tab. On Team and Enterprise plans, an admin adds it.

• Claude Code in a terminal (beta): add the connector with the same link. It appears in Claude Code when you're signed in with the same claude.ai account. The terminal asks you to sign in to AppAfterApp once more, even when the desktop app is already connected: run /mcp, choose claude.ai AppAfterApp, then Authenticate. On Windows, if PowerShell's script policy blocks claude, start it with claude.cmd.

  Having trouble? Email support@appafterapp.com.

Codex (beta). For now Codex is set up by hand; a listing in OpenAI's directory will replace these steps.

• Codex app: open Plugins → MCPs → Add → Connect to a custom MCP.
  1. Choose the type Streamable HTTP first. The default, STDIO, looks similar but silently fails, with no sign-in button.
  2. Name: appafterapp. URL: https://appafterapp.com/mcp. Leave Bearer token and Headers empty.
  3. Save. Then open appafterapp, choose Authenticate, and press Approve on AppAfterApp's page.
• To change a saved server's type, Uninstall it first, then add it again.

Codex in a terminal takes two commands. The Codex app and terminal share these settings, so set up either one.

codex mcp add appafterapp --url https://appafterapp.com/mcp
codex mcp login appafterapp

Which account? Your AppAfterApp account is whichever account your browser is signed in to on appafterapp.com when you approve. Check the name on the approval page.

If Codex stops showing the AppAfterApp tools, or doesn't offer to sign in, its saved sign-in has expired, and reinstalling doesn't clear it. In a terminal, run codex mcp logout appafterapp, then codex mcp login appafterapp, press Approve, and restart Codex. On Windows, codex may not be on your PATH: it's at %LOCALAPPDATA%\OpenAI\Codex\bin\<folder>\codex.exe.

Having trouble? Email support@appafterapp.com.

The connector has three tools: get_account, submit_build and get_submission. submit_build takes the build's details, its TESTING report and the file's size and SHA-256, never its contents, and returns a one-time upload address. The assistant uploads the file there with one command, which the app asks you to approve, then calls get_submission.

Client readiness

The publisher helper is set up only on the preview owner's computer. There is no download or setup guide for it, so creators can't publish yet.

Use a client running on the creator's computer: the helper reads the package from local disk, so a cloud or browser-chat session cannot reach it. Website file-upload forms are not part of this workflow.

Metadata through MCP

The assistant fills in structured metadata through the creator's authorised MCP connection. The creator signs in and approves the connection in the browser when asked; they do not need to write JSON or fill in website forms. MCP is the primary submission route, and optional demo.json is a portable copy that fills gaps only. Explicit publishing-request values take priority.

Submit the exact tested build, its metadata and the separate private TESTING record using the tools' own input schemas. Do not place private testing information inside publicly served game files.

Publish step by step

The helper has six tools. Read each tool's description and input schema before calling it; the schemas are authoritative.

Say this once, at the start of an upload. Tell the creator in one or two sentences that uploading is mostly mechanical, so maximum effort is not needed (a fast model, or their usual model at normal effort, is enough), and how long your play-test will take: about 5 minutes, or up to 10 for a bigger game. You cannot change your own model or effort; the creator decides whether to switch before you begin. Play-test it yourself by default. If your browser fails, retry once; only if it fails again, say what failed and offer the creator's choices from Keep testing proportionate: "Me (the creator): I'll test it and tell you the results" or "Me: I already tested it". Ask the creator one question at a time, with clear choices where possible; never bundle questions.

1. connect_account opens the creator's browser to approve the connection; if that browser is not signed in to AppAfterApp, the creator signs in first and the approval continues. It returns the account it connected. The game belongs to that account. Confirm it is the account the creator intends.
2. Add the required cover, then place the final ZIP in the helper's build folder. Every build needs a cover at publishing/coverImage.webp in the ZIP: AI-generated cover art, a designed SVG rendered to PNG or WebP, or a screenshot of the game. It must look like the real game and show the game's name in the image; see Make a cover. A single HTML file can't carry a cover: package it as index.html in a ZIP with the publishing/ folder. The helper reads only that one folder, set when the helper was installed; paths are relative to it. A path on another machine, or outside that folder, is not reachable.
3. begin_testing with that packagePath stages a clean private copy and returns a testRunId and a servedRoot. Its warnings say at once if the cover is missing or unusable. Serve servedRoot from a fresh local static server, test it in a fresh browser context against the testing checklist, and do not edit its files.
4. finish_testing with the testRunId and the compact TESTING report from the actual testing. Unperformed checks are Not run, never Pass.
5. submit_build with the packagePath, the testRunId and the metadata. For a replacement, pass the existing project's projectId; do not create a duplicate project. It refuses a build without a usable cover before uploading anything; otherwise it uploads the package and returns an operationId, the projectId and a state.
6. get_submission with the operationId reports the current state. amend_submission corrects details, or attaches a newly finished test report, without uploading unchanged files again.

Supply the title, build file, project type, phone capability, explicit Active yes/no, public creationModels attribution and the engine/framework in engine. Present optional engineVersion beside Engine as Version (optional); omit it if unavailable. Reuse existing valid values and ask for missing choices. If the creation model cannot be established, explicitly record Unknown; never guess or silently omit it. Optional files remain optional, including demo.json. Keep testing-model attribution in the separate private TESTING record.

Ask once whether the creator wants the One Shot label, and explain it in one line: one creator prompt, with no follow-up instructions or manual code changes. It is the creator's call: follow their answer, and don't refuse or argue. If yes, send oneShot true and their exact original prompt, verbatim, as originalPrompt; it is shown publicly. If no, leave both out.

For a replacement, preserve still-valid project details and the saved explicit Active answer unless the creator changes them. Reassess the submitted build's engine/version, creation models, capabilities and One Shot eligibility; use a fresh test run for the new files rather than inheriting stale claims. Reuse accurate information already available instead of asking the creator to re-enter it.

Submission and checks

The platform receives a candidate, checks the package and assets, and assesses isolated hosted gameplay, UX and UI. A candidate is not playable simply because the transfer succeeded. During the private preview, a person also plays each candidate before it publishes. Failed, suspicious, incomplete or uncertain assessments remain held with reasons; the live build stays untouched until a replacement passes.

UX/UI findings block publication when they prevent normal play, such as essential controls that cannot be reached or required instructions that cannot be read. Cosmetic preferences and style suggestions are feedback, not blockers or review holds by themselves. Package/security and functional gameplay checks still apply.

Cover codes

A build without a usable cover is refused at upload, before any check runs. The helper's submit_build refuses it before uploading anything, and the platform refuses it again if a submission arrives without one or the received package's cover breaks a rule. The refusal gives a code and a message saying what to add or fix:

Add or fix the cover, run begin_testing and finish_testing on the new ZIP, and submit again. The game's name on the cover can't be checked automatically, so the reviewer checks it; a cover without it, or one that doesn't look like the real game, can be held.

Invalid optional metadata returns a warning and is ignored, keeping valid values. Such a warning alone does not reject or hold the build. Required details must still be valid. See metadata.

Understand the outcome

Interruptions and corrections

Keep the operationId and projectId returned by submit_build. After a timeout or interruption, call get_submission before starting another submission. To resume an interrupted upload of the same unchanged package, pass the same operationKey to submit_build; changed files are a new test run and a new submission. Do not blindly duplicate uploads.

Use returned errors to correct the affected file or detail while preserving valid information. Each correction through amend_submission takes a new amendmentKey; reuse a key only to retry the same correction. Review response times are not guaranteed.

Report back

Give the creator a compact, evidence-based result:

• Artifact: filename, format, size, SHA-256 and engine/export version.
• Prepared details: title, project type, phone capability, explicit Active answer, creation-model attribution including any explicit Unknown, Engine and optional Version; name any answers still missing.
• Tests: browser/device, real hardware or emulation, actions and Pass / Fail / Not run / Not applicable with reasons.
• Submission: not submitted (and why), or the returned operationId, projectId and state.
• Publication and play: whether publication was confirmed, and which hosted checks were actually performed.
• Next action: the specific correction, missing decision or remaining check.