chatgpt-apps

Guides building, scaffolding, refactoring, and troubleshooting ChatGPT Apps SDK applications, which pair an MCP server with a widget UI. It enforces a docs-first, example-first workflow: before writing code the OpenAI docs are consulted (via the openai-docs skill or the OpenAI developer docs MCP tools), baseline Apps SDK pages are fetched for server, UI, examples, tool planning, and reference, and the doc URLs used are cited when explaining design choices. Current docs guidance takes precedence over older repository patterns, and compatibility aliases are called out explicitly.

Each request is classified into one primary app archetype (tool-only, vanilla-widget, react-widget, interactive-decoupled, or submission-ready) to decide whether a UI is needed, whether to keep a split server and web layout, which examples or scaffolds to prefer, and which validation checks matter. Tools are planned before code with one job per tool, explicit machine-friendly inputs, and accurate annotations such as readOnlyHint, destructiveHint, openWorldHint, and idempotentHint. Connector-like, data-only, or deep-research apps default to the standard search and fetch tools rather than custom read-only equivalents.

For greenfield work the recommended starting points are ordered: official OpenAI examples first, then version-matched @modelcontextprotocol/ext-apps examples, and only a small local Node scaffold when nothing else fits. Generated widgets favor the MCP Apps bridge first and window.openai compatibility second. The output includes an MCP server scaffold, widget scaffold, a validation report against a minimum-working-repo contract, local dev and connector setup, and covers CSP allowlists, domain settings, and URI versioning for production-ready structure.