Skip to main content

Steps

Publishing in ChatGPT and Claude means submitting a specific app version for review. Once approved, that version is served to users, and experience changes require resubmission. This playbook walks through the Alpic process and the key checks for passing review.
0

Create your account

Go to app.alpic.ai, click on Sign in with GitHub and authorize Alpic AI to access your GitHub account.
1

Deploy

Deploy your app with zero config. Views and assets, environments, OAuth and custom domains are built in, on SOC 2 Type II infrastructure. (Details)
2

Test like a user

Try your app in the Playground, a production-like host with a shareable link, before it is listed anywhere. UseTunnelto test local changes. (Details)
3

Audit

Run Beacon to check protocol, tool metadata, view rendering and CSP against the ChatGPT and Claude directory rules to ensure successful review. (Details)
4

Submit

The submission helper pre-fills both directories’ forms and test cases from your deployed server. (Details)
5

Ship updates safely

Follow the versioning rules so an update never breaks the approved version. (Details)
6

Observe and grow

Analytics show sessions, clients, tool calls, errors and latency, and User Insights shows what people ask your app for. (Details)

Details

1. Deploy to a dedicated environment

In the Alpic dashboard, click New Project, then start from a starter template, import your own Git repository, or clone a ready-to-use example project. The first time, Alpic asks you to connect your GitHub account, so it can create or read the repository and redeploy on every push.
Skybridge is Alpic’s open-source TypeScript framework for MCP Apps. You write your views in React, get end-to-end type safety between tools and views, and develop with hot reload and devtools. The same app runs in ChatGPT, Claude and any client that supports MCP Apps, and Alpic deploys it with no configuration.
Prefer another framework? Alpic also detects and builds servers written with the official TypeScript and Python MCP SDKs, FastMCP and xmcp. See Builds for how detection works.

2. Test like a user

Every Alpic environment has a Playground at /try, a full MCP host with a preconfigured model. It renders your views the way ChatGPT and Claude do.
  • Add example prompts to the Playground. They show testers what the app can do, and they make good test cases for your submission.
  • Check each view in every display mode your app uses: inline, picture-in-picture and fullscreen.
  • Share the /try link with teammates and beta testers before any directory lists the app.
  • To test changes before deploying them, run alpic tunnel and open /try on your tunnel URL.

3. Audit with Beacon

Beacon checks your server against the same specifications and platform rules the directories apply in review. It also launches your app in a real ChatGPT and Claude conversation and checks that each view renders. Run it from the dashboard, or from your terminal or CI:
Fix all errors before you submit; the directories reject apps that fail them. The checks that most often block a listing are:
  • Tool annotations. Every tool declares readOnlyHint, destructiveHint and openWorldHint.
  • CSP and domains. Your widget is JavaScript running inside an iframe inside ChatGPT. ChatGPT can’t trust arbitrary code, so it sandboxes it. CSP - Content Security Policy - is how you tell the sandbox what your code legitimately needs. Make sure you declare the most critical domains:
    • connectDomains: every domain your view fetches data from. Without it, requests are blocked.
    • resourceDomains: every domain serving static assets such as scripts, images and fonts. Without it, the view renders broken.
    • redirectDomains: every external site your app sends users to. Without it, ChatGPT warns users that they are leaving ChatGPT.
  • Edge-case input handling. Reviewers don’t always test edge cases by hand, but they do run automated checks. Once your app is live, every weird input will eventually hit your tools, so this shapes your users’ experience too. Make sure you handle cases like empty strings (""), null values; dates in the past (2020-05), out-of-range numbers (-50) as well as unicode oddities, such as emoji or accented characters (France 🇫🇷)
Beacon and the submission helper don’t support OAuth-protected servers yet.

4. Prepare the package and submit

Set up the version you will submit

Before you create the submission:
  • Create an environment per submitted version. Name it after the release (v1, v2) so it is obvious which environment backs which listing. Directories cache part of your server at submission time, so a dedicated environment keeps that version stable while you keep developing elsewhere. See Recommended release workflow.
  • Decide on your domain now. ChatGPT expects the same domain across versions. If you plan more than one version, put a custom domain in front and route each version with a path prefix, for example https://mcp.example.com/v1.
  • Name your view assets deterministically. With stable asset names, you can fix a view after approval by redeploying, without a new submission. See Asset naming strategy.
  • Protect it if needed. Add authentication or IP allowlisting before you share the URL.
Open Submissions in your project and create one submission per directory. The submission helper reads your deployed server, fills in what it can, drafts the narrative fields and runs Beacon again. Before you start, have these ready:

Submit and respond to review

When the submission shows Ready to export, open the handoff for its directory: If a reviewer asks for changes, fix them in the same environment and re-run Beacon before you resubmit. Keep the submitted environment stable while the review is open.

5. Ship updates safely

Once approved, ChatGPT and Claude cache your tools/list response and, for MCP Apps, your views’ entrypoint HTML. Calls still reach your latest deployment. A change that doesn’t match the cached schema can break every call to a tool.
  • Safe to ship with a redeploy: handler logic, and view assets with stable names.
  • Needs a new submission: new tools, new or changed parameters, new views and changed entrypoint HTML.
  • Never add a required parameter or remove a tool before the new version is approved.
The versioning guide lists the safe migration path for each operation.

6. Observe and grow

After launch, the dashboard shows how the app is really used:
  • Analytics: sessions by client, tool calls, errors and latency.
  • Telemetry export: send logs, metrics and traces to your OTEL stack.
  • User Intents: what people asked for when they called each tool.
  • User Feedback: what the model and users said about the answers.
Use them to plan the next version, then start again from step 1 with a new environment.
Want Alpic to build the app for you? Alpic Studio designs, builds and submits MCP Apps, and your team owns the result.