Dora NodaIn July 2026, Railway did what every ambitious platform is doing this year: it put deploys inside the chat window. On July 16, an official Railway plugin landed in the Grok Build marketplace. On July 31, an official Railway plugin launched in ChatGPT, able to plan work, provision services, and debug a 502 — all from a conversation.
Here is the sentence that matters more than either launch: under the hood, the ChatGPT plugin is powered by Railway's hosted MCP server at mcp.railway.com. Railway didn't build two integrations. It built one protocol-standard server, bundled its agent skills, and dressed it in two different chat vendors' packaging. The deploy-from-chat arms race has a winner already, and the winner is the layer underneath the plugins.
That is the whole article in miniature: own one machine-readable server, generate N thin wrappers. The rest of this post substantiates it — what Railway actually shipped, what each wrapper costs, and the playbook for a self-hosted platform that doesn't have Railway's headcount.
What Railway actually shipped: one server, two (then three) wrappers
Start with the receipts, because the architecture is visible in the changelogs themselves.
July 16, changelog #0299: the Grok plugin. The official Railway plugin appears in the Grok Build plugin marketplace — xAI's coding agent surfaces an install hint when your prompt mentions Railway, or you install it manually from the marketplace list. What the plugin "packages," per Railway, is everything the agent needs to work on your Railway projects: API access plus the Railway Agent skills, the same operating knowledge its other integrations carry, so the agent knows how Railway works instead of guessing.
July 31, changelog #0301: the ChatGPT plugin. Install it, connect your Railway account, and the Railway Agent inside ChatGPT provisions services ("an API with a Postgres database behind it"), debugs from logs ("why is checkout returning 502s?"), and mutates config ("set LOG_LEVEL to debug and redeploy"). Two facts in that entry do all the argumentative work of this post.
First, the plugin acts with your personal access level — ChatGPT can only see and change what you already can, which means auth is delegated identity, not a new per-chatbot credential universe. Second, and explicitly: the plugin is powered by the hosted MCP server, and it bundles the Railway Agent skills. A reader of that changelog knows exactly how to reproduce the integration without OpenAI's involvement: point any MCP client at the server, hand it the skills, done.
August 28, changelog #0305: the Grok Bot plugin. Weeks later, the same Railway plugin lands in yet another surface — Grok Bot — giving bots "an authenticated way to deploy, configure, monitor, and troubleshoot Railway infrastructure." Same verbs. New wrapper.
Trace one concrete task through both architectures and the difference stops being philosophical. Take "set LOG_LEVEL to debug and redeploy." In the wrapper world, that sentence must be implemented, reviewed, and maintained once per surface: the ChatGPT app definition, the Grok marketplace plugin, the Claude Code plugin, the Cursor marketplace entry, the bot integration. In the server world, it is one tool call — update-variable, redeploy — defined once on the MCP server, and every surface that speaks MCP inherits it the day it ships. Railway's own history demonstrates the direction of reuse: each new launch announcement reads less like a new integration and more like a new adapter over the same backend. By the ChatGPT entry, Railway says so outright.
The scoreboard: N wrappers versus one server
Generalize the trace into the decision table a platform team actually faces. Rows are the costs; columns are the two strategies.
| Cost | One plugin per chatbot (N surfaces) | One MCP server (+ thin adapters) |
|---|---|---|
| Distribution and review gate | Each vendor's own: ChatGPT app submission and review, Grok marketplace listing, Cursor marketplace entry — N queues, N policy regimes, N reasons a launch slips | One HTTPS endpoint you control; no vendor approval to ship a new tool |
| Capability parity | Drifts by surface: what the Grok plugin can do vs. the ChatGPT app vs. the bot is a per-wrapper implementation detail that rots independently | Every client inherits every tool the day it ships; parity is structural, not a QA project |
| Auth model | Negotiated per surface: OAuth flows, bot tokens, marketplace identity quirks — each wrapper re-answers "who is acting, with whose permissions" | One answer, enforced once: Railway's "acts with your personal access level" holds for every client of the server |
| Cost of surface N+1 | A new project: new SDK, new manifest format, new review, new maintenance tail (see: Grok Bot, five weeks after ChatGPT) | Near-zero if the surface speaks MCP: point it at the endpoint and hand it the skills |
| Who controls the roadmap | The chat vendors: a manifest-format change or a marketplace policy update becomes your migration (in 2026, vendors still ship per-client manifest folders — .grok-plugin, .claude-plugin, .codex-plugin, .cursor-plugin — rather than one portable manifest) | You: version the server, deprecate tools on your schedule, keep the skills file in your repo |
Now run the sensitivity analysis, because the table alone undersells how fast the left column compounds. The per-surface costs are roughly fixed per wrapper — one review gate, one manifest dialect, one auth negotiation, one maintenance tail per changelog cycle. Total cost scales as O(N): with Claude Code, Cursor, Grok, ChatGPT, and Grok Bot, Railway is already maintaining five surfaces, and the next chatbot launch (there is always a next chatbot) starts the meter again.
The right column is O(1) plus adapters so thin they barely count — Railway's ChatGPT "plugin" is the existence proof that the adapter can be a few pages of app definition over an unchanged server.
The delta, stated plainly: every quarter, the wrapper strategy re-pays the integration cost once per surface; the server strategy pays it once, total. A team with Railway's headcount can afford to pay it five times and smile in five changelogs. A self-hosted platform team cannot, which is exactly why it should not try.
The fragmentation tax, itemized — and the honest reason wrappers still exist
If the server already won, why does anyone ship wrappers at all? Three exhibits from 2026 show the tax is real, and one honest counter-argument explains why vendors keep paying it.
Exhibit 1: per-client manifests never died. The agent-plugin ecosystem spent 2026 standardizing portable plugin manifests — and vendors kept shipping per-client folders anyway. Railway's own skills repo carries separate .grok-plugin, .cursor-plugin, .claude-plugin, and .codex-plugin manifests for what is substantially the same plugin. A community directory of agent plugins notes dryly that per-client manifests "have not gone away," listing Railway alongside Vercel, Cloudflare, Stripe, and MongoDB as vendors maintaining them. The protocol converged; the packaging didn't.
Exhibit 2: every new surface is a new launch. The Grok Bot plugin, five weeks after ChatGPT, is the pattern in miniature. Bots needed "an authenticated way" to do what the server already let every other client do — which means each surface's auth story was negotiated separately, on that surface's schedule, announced as its own changelog entry. Five surfaces, five launches, five maintenance tails.
Exhibit 3: install friction differs by surface, and vendors absorb it per wrapper. Pointing an MCP client at an endpoint is trivial for developers and somewhere between annoying and gated for everyone else: ChatGPT's full MCP connectors live behind Developer Mode, plan-dependent availability, and a multi-step connector setup. A listed plugin ("install, connect account, ask") removes that friction — but the removal is hand-built per surface, and it rots per surface.
And here is the honest counter-argument, because the reader who feels cheated by a one-sided ledger should get the other side's best point: wrappers buy distribution and native UI, and those are real. A ChatGPT plugin puts your platform where the questions happen — Railway's changelog says exactly that: most agent integrations live where code lives, this one lives where the questions happen. OpenAI's Apps SDK, built on MCP, additionally lets an app render interactive UI inside the conversation, which a bare tool call cannot do. Marketplace presence is discoverability; one-click install beats "enable Developer Mode and paste an endpoint" for every user who is not you.
Concede all of it — then apply the rule this post's title promises: own the protocol, generate the wrappers. Distribution is a packaging problem, and packaging should be the thinnest, most mechanical layer in the stack: app definitions and manifest folders generated from the server's tool schema, not five hand-maintained integrations with five independent understandings of your platform. Railway's architecture already points there — one server, one skills bundle, N adapters. The tax isn't the adapters existing. The tax is maintaining them as if each were the product.
Why MCP won the protocol war anyway
Step back, because the numbers say this stopped being a bet sometime in early 2026. Anthropic launched the Model Context Protocol in November 2024 as an open JSON-RPC standard for agent-to-tool calls — "USB-C for AI." OpenAI adopted it in March 2025; Google DeepMind followed. In December 2025 Anthropic donated it to the Linux Foundation's Agentic AI Foundation as a multi-vendor standard.
By March 2026, monthly MCP SDK downloads hit 97 million — up roughly 970x from launch — with more than 10,000 public servers indexed across registries and more than a quarter of the Fortune 500 running MCP in AI workflows.
The clincher for this post's argument is what OpenAI built on top: the Apps SDK — the framework behind the ChatGPT plugin Railway shipped — is itself built on MCP. ChatGPT connects to external tools through MCP and extends it for UI rendering. So the scoreboard isn't "MCP vs. ChatGPT plugins." It is MCP vs. MCP-in-a-vendor-trench-coat, and the trench coat adds review queues and manifest dialects while the body underneath does the work.
One nuance deserves honesty: 2026 also hosted a loud "MCP vs. skills" debate, and the resolution matters for the playbook below. Skills — markdown operating knowledge like Railway's agent skills — are not the enemy of the server; they are its documentation layer. Railway bundles both: the server defines what the agent can do, the skills teach it how things are done here. The thing to stop hand-maintaining per surface is neither. It is the wrapper.
The self-hosted playbook: one server your agents (and cron jobs) share
For a platform team without five integrations' worth of headcount, the strategy compresses to five steps:
- Expose one MCP server as the machine-readable front door. Every operation a human does in your dashboard — deploy, provision, set variables, read logs, roll back — becomes a tool call. If an action has no tool, agents can't do it, and neither can your own automation.
- Enforce identity once, at the server. Copy Railway's load-bearing sentence: the agent acts with the user's access level. One auth answer, inherited by ChatGPT, Claude Code, Cursor, a cron job, and whatever launches next quarter.
- Ship skills, not just tools. A tool schema says
redeploy(service); a skills file says how your platform expects deploys to be sequenced, what to check first, what never to touch. Keep it in your repo, versioned with everything else. - Generate the wrappers; never hand-write two of them. If ChatGPT distribution matters, write the Apps SDK adapter as a projection of the server schema. If a marketplace wants its manifest dialect, generate that folder. The day a wrapper needs bespoke logic is the day a tool is missing from the server — fix it there.
- Treat scheduled agents as first-class clients. The quiet advantage of the server strategy: a nightly "check preview-env staleness and tear down the dead ones" job speaks the same protocol as the chatbot. No separate automation API to build, version, or secure.
Predictions are cheap, but this one is just extrapolation: within a year, every major chat vendor's "plugin SDK" will be a thin projection over MCP transports — OpenAI has already shown the shape — and the teams that hand-built N integrations will be maintaining N wrappers around one protocol they could have owned from the start. Railway read this correctly: it celebrated two plugin launches while quietly building the thing that made both of them cheap.
Build the server. Generate the wrappers. Let the chatbots come to you.
Bex.co is the open-source, AI-native Render alternative — push a git repo, get a running HTTPS service on machines you own. Machine-readable infrastructure state plus one protocol-standard server is exactly how a self-hosted platform should meet AI agents, so that's the interface we're building toward. Star the repo on GitHub or deploy your first app today.
