Build the required MCP server before the optional UI
Describe the user job, tool contract, data boundary, and optional embedded interface. Playcode can build the server, widget, deterministic tests, and HTTPS deployment path while you own the OpenAI account, Developer Mode connection, privacy policy, and plugin review.
No credit card required · No coding needed
Quick answer
A ChatGPT app needs an MCP server with clearly described tools, validated inputs, predictable outputs, accurate impact annotations, and secure data handling. An embedded UI is optional. Playcode can build and test those files and host the endpoint, while Developer Mode connection, real prompt selection, plugin submission, review, and publication remain manual OpenAI account steps.
Used by people at
Counts registered accounts using corporate email domains from the companies above. Playcode is a self-serve product, not a contracted vendor to these brands.
Define the tool contract first, then add UI only when it improves the outcome
Write direct, indirect, and negative prompts. Give each user intent one tool with an explicit input schema, output schema, description, authentication rule, rate limit, and read-only, destructive, and open-world annotations.
Keep data tools separate from presentation tools when the model should reason over the result before a widget renders it.
Ask Playcode to build the server with the current MCP SDK, deterministic handlers, and a versioned text/html;profile=mcp-app resource when a UI is useful. Return concise model-visible structuredContent and keep widget-only detail in _meta.
Declare exact CSP domains, enforce authorization on the server, and make handlers safe to retry before exposing the endpoint.
Run unit and MCP client tests, inspect the local endpoint with MCP Inspector, then deploy to public HTTPS. Connect it in ChatGPT Developer Mode and exercise the real prompt set on web and mobile.
For public distribution, prepare the plugin that contains the app, scan tools, complete privacy and company fields, submit it for review, and publish only after approval.
Your website is live!
Action-oriented names, precise descriptions, Zod input and output schemas, accurate impact annotations, and handlers that validate every request again on the server.
A versioned HTML resource, portable MCP Apps bridge, accessible states, and widget calls only where interaction adds value beyond a clear text result.
Concise structuredContent for the model, optional narration in content, and large or widget-only detail in _meta so private context does not enter model narration.
Anonymous read paths where appropriate, OAuth 2.1 for user-specific access, scope checks per call, and explicit confirmation before writes or irreversible actions.
Direct, indirect, and negative prompt fixtures plus MCP discovery, schema, tool-call, resource, invalid-input, retry, CSP, and payload-separation tests.
A public HTTPS endpoint, privacy and retention checklist, exact CSP allowlists, tool-scan inputs, review test prompts, and a reproducible downloadable package.
The local artifact proves code and protocol behavior. ChatGPT Developer Mode and public plugin review remain separate manual checks.
Tool discovery depends on metadata, so the server needs direct prompts, indirect prompts, and negative prompts that should not invoke it.
Ready when: Every intended prompt maps to one tool and every negative prompt has a reason to abstain or use another path.
ChatGPT needs a reachable HTTPS MCP endpoint, and review needs exact CSP, privacy, retention, authentication, and user-data disclosures.
Ready when: The brief lists the endpoint owner, allowed network domains, stored fields, retention and deletion rules, scopes, and human owner for review.
Developer Mode, organization verification, tool scanning, submission, approval, and publication happen in OpenAI-managed account surfaces.
Ready when: The owner can access the intended organization and knows who holds api.apps.read and api.apps.write permissions.
Define one tool per intent, a Use this when description, every input and output field, read-only, destructive, and open-world annotations, auth requirement, rate limit, and examples that should and should not select it.
The intended tool is unambiguous for direct and indirect prompts and stays out of unrelated or negative requests.
Review every prompt against tool name, description, schemas, and annotations before writing the handler.
Use the current @modelcontextprotocol/sdk and Zod, validate every input, return only model-needed JSON in structuredContent, optional narration in content, and widget-only detail in _meta. Keep read handlers idempotent and writes confirmation-gated.
An MCP client can discover the tool, reject invalid input, call the handler repeatedly, and inspect a deterministic result without private widget detail entering model-visible fields.
Run MCP list, call, invalid-input, duplicate-call, and serialization tests and assert the exact response keys.
Register a text/html;profile=mcp-app resource with @modelcontextprotocol/ext-apps, use the MCP Apps bridge by default, declare exact CSP domains, and connect it with _meta.ui.resourceUri.
The widget renders the structured result without broad network access, hidden instructions, or a second conflicting business-logic path.
Read the resource through an MCP client, inspect MIME type and CSP metadata, then render it in MCP Inspector and check console and network errors.
Publish the exact tested artifact to a stable HTTPS /mcp URL, repeat protocol tests, connect the endpoint in Developer Mode, and exercise direct, indirect, negative, auth, failure, retry, web, and mobile cases.
The real ChatGPT host selects the intended tools, renders the optional UI, respects confirmation and auth, and avoids the app for negative prompts.
Record the endpoint version, prompt results, web and mobile observations, console errors, tool payloads, and unresolved differences from local Inspector behavior.
Verify the organization, use a real public MCP URL, scan tools, review imported schemas, annotations, instructions, CSP, and UI metadata, complete privacy and company fields plus test prompts, then submit the plugin that contains the app for review.
The portal accepts a reviewable draft whose server-advertised metadata matches actual behavior. Approval and publication remain pending until OpenAI completes review.
Re-scan after every server metadata change, rerun all submitted prompts, and compare disclosures with every user-related field before selecting Submit for review.
Choose: Start tool-only when a concise answer or JSON result completes the job. Add a widget for comparison, selection, editing, visualization, or repeated interaction that is materially clearer than narration.
Tradeoff: A widget improves interaction but adds CSP, accessibility, state, caching, host compatibility, screenshot, and review work. The MCP server remains required either way.
Choose: Prove an anonymous or fictional read-only path first when the product allows it. Add OAuth only to tools that truly need user-specific data or writes, and enforce tokens, audience, scopes, and policy on every server call.
Tradeoff: Authentication protects private data but introduces provider metadata, token verification, reauthorization, scope, test-account, and review complexity.
List tools and resources, call the read-only tool with valid input, and render the optional widget from the returned structuredContent.
Expected: Schemas, annotations, resource URI, MIME type, structured fields, narration, and widget output all match the declared contract.
Send an unknown enum, oversized value, missing credential, wrong scope, and a negative prompt that should not invoke the tool.
Expected: The server rejects invalid calls without side effects or secrets, auth returns a useful challenge, and the real host abstains on the negative prompt.
Repeat the same read call and retry a proposed write with the same idempotency key after an interrupted response.
Expected: Reads remain deterministic and the write applies at most once only after explicit confirmation and current authorization.
Connect the deployed HTTPS endpoint in ChatGPT Developer Mode and run direct, indirect, negative, auth, UI, web, and mobile prompts.
Expected: The real host behavior matches the golden prompt expectations with no CSP, console, auth, privacy, or unexpected tool-selection failure.
A widget can make status and next actions easier to scan, but the typed MCP tool remains the real contract.
The Launch Checklist package uses the current official dependency family and keeps live ChatGPT exercise outside the automated claim.
| What you need | Tool-only MCP app | MCP app with UI |
|---|---|---|
| Best result | A lookup, calculation, validation, or short structured answer | A comparison, selector, editor, status board, or interactive detail view |
| Required boundary | MCP server and tool contract | The same MCP server plus a versioned text/html;profile=mcp-app resource |
| Model data | Concise structuredContent and optional narration | The same model data plus widget-only _meta where needed |
| Extra review surface | Tools, auth, privacy, prompts, and server behavior | CSP, iframe behavior, accessibility, screenshots, state, and mobile rendering |
Read-only checklist
Turn a product name, audience, and stage into a transparent checklist without claiming that a live connection, review, or publication has occurred.
Cited source result
Search approved records with bounded filters, return concise model-visible citations, and keep large display data in the widget-only payload.
Structured snapshot
Read a private project only after OAuth scope checks, then render milestones and blockers without exposing tokens, logs, or internal debug fields.
Review before write
Separate preview from execution, show the exact target and consequence, require current authorization and confirmation, and make the write idempotent.
Playcode AI runs the same frontier models that power ChatGPT and Claude - and orchestrates them like a team: it plans the work, delegates to sub-agents, runs long jobs in the background, and reviews its own changes.
The latest models from every major lab, in one picker. Switch anytime.
Big jobs split across specialists - one explores your code, one writes, one audits - working in parallel.
Long builds and migrations keep running while you keep talking. They report back when done.
Have a design in Figma? Paste a screenshot - or a page you like, or a bug - and it builds from what it sees.
Tuned by years of iteration to write production software - structured, typed, maintainable - not throwaway prototypes.
Under every project is a codebase the agent keeps production-grade. And you are never locked out of it: open the file explorer and edit any file yourself - server included. No AI required.
Complete states, secure boundaries, structured code - the bar is what a professional agency would ship.
Browse the whole project - frontend, backend, configuration - and edit directly in the built-in editor.
Invite your developer with the right role, or export the project code and files. Nothing is trapped in Playcode.
Playcode is built for organizations, not just solo builders. Workspaces hold your projects, people, and billing; roles and teams decide exactly who sees what.
Create a workspace per company, client, or department - each with its own members, projects, and subscription.
Admins manage, editors build, viewers watch. Set roles on the whole workspace, on a team, or on a single project.
Group people into teams and give each team its own projects - or a whole folder of them. Private projects stay private, even inside a shared workspace.
Send a project to any email - a client, a contractor - with exactly the access you choose. No extra seat needed.
Work on one project together. Write in the same AI chat together. Every message, edit, and setting is fully synchronized - live, for everyone, on every device.
Everyone works in the project at the same time - even in the code editor - without lock-outs or "who has the latest version".
Start on the laptop, check from your phone: the same live state follows you everywhere you sign in.
Changes arrive over a live connection the instant they happen. Reloading the page is a habit you can drop.
Every click applies immediately on your device. Syncing happens behind you, not in front of you.
Connection dropped? Your changes queue locally and replay the moment you are back.
The queue survives closing the tab. Nothing you did is lost while you are away.
"I built my entire portfolio site in 20 minutes. My clients think I hired a designer. Already got 3 new inquiries this month."
"We switched from Wix to Playcode. The AI actually understands what we need instead of giving us cookie-cutter templates. Saved us thousands."
"I update my property listings from my phone while showing apartments. Clients are impressed when I tell them I built the site myself."
Start small. Upgrade when you're ready.
Try the AI website builder and see results
Everything you need to build
Cancel anytime. No hidden fees.
Credits are used when AI helps you. Simple edits cost less, complex features cost more.
Most users never run out. 100 credits = lots of building.
Yes. The current Apps SDK architecture uses your MCP server to define tools, enforce authentication, return data, and point to any UI resource. An embedded widget is optional; the MCP server and tool contract are the required foundation.
Yes. A tool-only app is often the better first release for lookups, calculations, checks, and concise structured results. Add an MCP Apps UI when selection, comparison, editing, or visualization materially improves the user outcome.
Put concise JSON that the model may read and narrate in structuredContent. Put large or widget-only detail in _meta. Optional content can contain short narration. Never treat _meta as a substitute for server authorization or privacy minimization.
Playcode can build, test, package, and host the general MCP server and optional UI. Connecting the HTTPS endpoint in ChatGPT Developer Mode requires your OpenAI account and remains a manual host test, including real prompt selection and mobile behavior.
Current OpenAI documentation describes submitting the plugin that contains the MCP-backed app through the plugin submission portal. The flow includes organization verification, a real public MCP URL, tool scanning, privacy and company information, test prompts, review, approval, and a separate Publish step.
No. Local tests establish the code and protocol contract. OpenAI review evaluates the deployed endpoint, metadata, tool behavior, privacy disclosures, annotations, test prompts, UI when present, policies, and other requirements. Review timing and approval are not guaranteed.
Use OAuth 2.1 when a tool reads user-specific data or performs an authorized action. Prefer an anonymous or fictional read-only path for early proof when possible. The server must still validate tokens, audience, expiry, scopes, and app policy on every protected call.
Negative prompts prove that metadata does not make the app appear for unrelated work, unsupported claims, or requests that should use another tool. They are essential because ChatGPT selects tools from names, descriptions, schemas, and context rather than from your handler alone.
Still have questions? Contact us
Start with one user job, one typed read-only tool, one prompt set, and one explicit privacy boundary. Add a widget only when it improves the outcome.
A launch-readiness app with one read-only checklist tool and compact widget...Build My ChatGPT AppNo credit card required. AI credits included.