Put your AI agent in ChatGPT, Claude, Codex and Cursor

Updated 2026-09-28

The most direct way to put an agent in ChatGPT, Claude, Codex and Cursor is one remote MCP server with OAuth sign-in. All four hosts connect to it, so one build reaches all of them. This page covers the other options, what the server needs, each host's setup steps, and the parts that are harder than they look.

What are your options?

Four real ways to reach the same audience today. A remote MCP server with OAuth is the one every host now speaks: Claude, ChatGPT, Codex and Cursor all support it, so one server can reach all four instead of a separate build for each. ChatGPT also has its own Apps SDK, a way to ship a built-in app with its own interface inside chat. Claude has connectors, for MCP servers, and plugins, a packaged bundle a Claude Code user installs locally. Codex and Cursor are code editors first: you add a server to their MCP config and it shows up as a tool for whatever they're working on next. For an agent that just needs to read and write through tools, remote MCP is the direct path; the Apps SDK and Claude plugins matter once you want a custom interface inside the host, not only tool calls.

What does a remote MCP server need?

MCP, the Model Context Protocol, is an open standard for a host to call tools on a server it doesn't run itself (modelcontextprotocol.io). The current spec wants streamable HTTP: one JSON-RPC message per request, since the older batched form was removed, a session id the server hands out at initialize, and a way to resume a dropped stream from its last event instead of losing it.

Sign-in is OAuth 2.1. A host doesn't know your server exists until someone adds its address, so the flow starts with a 401 response carrying a link to your server's own protected-resource document, which names your authorization server. From there it's dynamic client registration, so nobody hand-enters a client id, and PKCE with S256, the strongest challenge method the spec defines. A server that asks for a shared API key pasted into chat skips all of this, and directory reviews expect OAuth.

Every tool your server declares should carry annotations: a title, whether it only reads, whether it can destroy something, whether calling it twice is safe, and whether it reaches outside your own system. Hosts use them to decide what to confirm with the person, and directory reviews check them before listing you. Both Claude's connector directory and OpenAI's app review also ask for a privacy policy naming what you collect and how long you keep it; see claude.com/docs/connectors and developers.openai.com/apps-sdk.

What does each host need, step by step?

On a company ChatGPT workspace, Developer mode may stay hidden until an admin turns on custom apps. On Claude Team or Enterprise, an Owner usually adds the connector under Organization settings before anyone on the team can use it. Both are approvals you can't route around.

What's actually hard about this?

Sign-in per host. Each host runs its own OAuth client against your authorization server, so the same person signs in separately to Claude's connector and to ChatGPT's app, even though it's the same account behind both, unless your server recognizes a session from an earlier sign-in and skips straight to consent.

Per-host instructions. There's no single copy-paste that installs everywhere. Claude's menu path, ChatGPT's Developer mode, Codex's CLI command and Cursor's install link are four different sets of steps, and hosts change their menus without notice, so instructions written once go stale.

Billing. MCP has no built-in idea of a paid plan. If your app charges, the check has to sit in your own tool-call path: something that looks up whether this installation is entitled before the tool runs, and answers with a plain sentence and a checkout link, not a raw error code, when it isn't.

Approvals and audit. A token proves who's calling and which installation, not what a person actually approved inside the chat. If a tool can send a message or spend money, you need your own record of the exact thing someone said yes to, since the host's transcript isn't yours to keep.

A short checklist

• Streamable HTTP, not the older stdio-only shape, so any host can reach you over the network.
• OAuth 2.1 with PKCE and dynamic client registration, not a pasted API key.
• Every tool is annotated as read-only or not, and a tool that sends or spends is separate from one that only reads.
• A privacy policy and a support contact, since directory review asks for both.
• A plain sentence and a link, not a raw error code, when someone hits a sign-in or billing wall.

How Agent Rails does it

Agent Rails packages the same shape for you. A developer's app is one directory: a manifest, its tools, its records schema and its skills, checked once at admission, so the tool list a host sees is the one that was reviewed. Each app gets one address and one MCP server, <app>.rails.so/mcp, that speaks streamable HTTP to Claude, ChatGPT, Codex, Cursor and anything else that speaks MCP, with no second build per host.

Sign-in runs once across apps. Rails is the OAuth 2.1 authorization server behind every app's server: the first connector a person adds shows them the phone-code sign-in page they already use for the rest of Rails, and the session it sets means a second app's connector goes straight to consent, with no second code. A token is bound to the person, their one installation of that app, and that app alone, so two installations, or two different apps, never read each other's tokens.

Setup instructions ship themselves. Every app publishes an llms.txt and a /start page built from the same admitted manifest, so an agent helping someone connect reads the real, current steps instead of a stale doc, and a downloadable skill file carries the same steps into a coding agent's own workspace.