Our MCP server is now a ChatGPT plugin
DEV Community

Our MCP server is now a ChatGPT plugin

GoodBarber is now listed in the ChatGPT plugin directory. Find GoodBarber in the directory, connect your app, and run it from the chat: content, catalog, members, push notifications.

This post extends the announcement on our blog with the developer view, and it closes a loop we opened when we wrote up how we built that server.

One line of context for new readers: GoodBarber is a no-code app builder (running since 2011). Customers configure an app in a web back office; the platform compiles native iOS and Android builds plus a PWA. We built a public MCP server so that MCP clients (Claude, ChatGPT, Codex, Cursor, n8n and others) can operate those apps.

One server, two ways in

Nothing changed server-side. Both paths land on the MCP connection your app already has, scoped to that single app and authorized by you. What changed is the effort to get connected:

  • The official app in the directory. Find GoodBarber, connect, authorize access to your app. No Developer mode, no URL to paste.
  • The full GoodBarber MCP server as a custom connector. Enable ChatGPT's Developer mode and add https://mcp.goodbarber.dev/mcp/sse (the /sse is a route name; the server speaks Streamable HTTP). This is also the path for Codex: Settings, Integrations, MCP servers, leave the bearer token field empty and the save opens the OAuth flow in a browser.

The step-by-step for both lives on our setup page.

What the connection actually is

If you have read our write-up on building the server, you know the architecture. The short version:

  • One connection = one app. Each GoodBarber app has its own MCP URL with a unique app id; an agent authorized on app A cannot reach app B. You authorize the connection in a browser via OAuth; there is no API key to paste into the chat.
  • Writes are policy-flagged. Every write returns _mcp_policy.verification_required: true, so a well-behaved client reads back what it just changed before claiming success.
  • The tool surface is documented, not hardcoded. The authoritative list is the server card; what a given app exposes can be a subset, depending on its features and plan.

Our own tests, including the β€œSend my users a push about the spring sale.” example that opens the announcement, ran from a free ChatGPT account through the MCP connection: we drafted the push, confirmed it, and it landed on the test phones.

Why the listing matters

Building the server was engineering. Being found is distribution, and for an agent-facing product the distribution surface is inside the assistant, not on your marketing site.

Until now, connecting GoodBarber to ChatGPT meant knowing the endpoint existed, enabling a developer toggle, and pasting a URL. That filters out almost everyone who would benefit. A directory listing replaces all of that with a search box: something a non-technical app owner can actually do, without reading a single setup doc.

What we do not control: how the directory surfaces or ranks apps. That side is OpenAI's. For us, building the server turned out to be the easy half. The listing is what puts it in front of the people it was built for.

Read on DEV Community ↗ ← Back to News

Comments

No comments yet. Start the discussion.