# Building a production MCP server: How we made GoodBarber agent-ready (without the glue code) > Source: > Published: 2026-07-15 12:10:40+00:00 We wanted an AI agent to manage a real production app (its content, its catalog, its push notifications) natively, not through screenshots and simulated clicks. So we built an MCP server. Here's the whole thing: why, how, a real session, and where it still falls short. One line of context so the rest makes sense: 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. The question we set out to answer: can an AI agent operate one of those apps, end to end, the way its owner does? The platform has had APIs for years. Exposing endpoints was never the problem. The problem was that every "connect your assistant" integration is custom glue: tool definitions written for one vendor, an auth flow, retry logic, docs written for a model to read. Then you do it all again for the next assistant. The classic N×M integration mess: N assistants × M platforms. The Model Context Protocol (introduced by Anthropic in November 2024, donated to the Linux Foundation in late 2025) standardizes exactly the parts we kept rewriting: The practical difference is blunt: with a classic API, you write an integration for each agent. With an MCP server, any MCP client (Claude, ChatGPT, Claude Code, Cursor, n8n) connects and figures out how to drive the app on its own. We shipped one server and got every current and future MCP client for free. So the goal was never "another API". It was: make the app itself drivable by an agent. Here's how that's wired. ``` Claude · ChatGPT · Cursor · n8n (any MCP client) │ natural language → typed tool calls ▼ GoodBarber MCP server (hosted) https://mcp.goodbarber.dev/mcp/sse │ OAuth 2 sign-in · scoped to *your* app ▼ Platform APIs CMS · push · shop · orders · customers · stats ▼ Your live app iOS · Android · PWA ``` To be clear up front: **the server itself is a hosted GoodBarber service, not an open-source package you install.** What's open source is the Skills layer (below). The reproducible part for you as a reader is the connection: plug the endpoint into an MCP client, sign in, and an agent is operating a live app a couple of minutes later. **Tool design.** Tools are namespaced by domain (`cms_*` , `shop_*` , `classic_*` ) and map one-to-one onto what the back office can do. The full machine-readable inventory is public in the [server card](https://mcp.goodbarber.dev/.well-known/mcp/server-card.json): 150 tools at the time of writing (July 2026). That card is the contract: when the platform grows, the card grows, and connected agents pick up the new tools automatically. **Scoping.** Sign-in is OAuth 2, and every session is scoped to the authenticated customer's app. An agent connected to app A cannot see or touch app B. Agencies running several client apps connect each one separately. **Server-side guardrails.** Two design decisions we'd defend in any review: `_mcp_policy.verification_required: true` . The agent is expected to re-read the object it just created or changed and confirm the result. Hallucinated success is the failure mode we fear most.**The open-source layer: 44 Claude Skills.** On top of the server we publish [ goodbarber-skills](https://github.com/goodbarber/goodbarber-skills): 44 open-source Claude Skills, plain markdown recipes that wrap common workflows (create a product with variants, schedule a push campaign, refund an order…). Two distinct artifacts: the server is the live connection; the Skills are curated entry points that call it. The repo is deliberately white-label-friendly, so agencies can rebrand and redistribute it. Enough theory. A real task, run from Claude with the server connected: Add a black "Storm" T-shirt at €29 in S, M and L, put it in the Summer 2026 collection, and schedule a push for 6 p.m. announcing the drop. What the agent actually does: ``` shop_list_collections → resolves "Summer 2026" to a collection id shop_create_product → creates the product (name, €29, collection) ← verification_required: true shop_get_product → read-back: confirms the product exists as intended shop_create_variant ×3 → S, M, L shop_create_push_broadcast → drafts the push, scheduled for 18:00 ``` Then it stops and shows me the push copy before anything is scheduled: interactive clients like Claude ask before executing writes. The agent does the plumbing (id resolution, argument formatting, sequencing, verification); I approve what goes out. In the back office this task is a dozen screens; by conversation it's one prompt and one approval. Nothing in the session is Claude-specific: the same flow works from ChatGPT connectors, Claude Code, or Cursor. And because the tools are typed, the failure mode is honest: pass a malformed price and you get a schema error back, not a silently broken product. The honest list, because this is the part most write-ups skip: One thing we chose **not** to build into the server: a mandatory approval flow. How much autonomy an agent gets is the operator's decision, made in the client. Interactive assistants like Claude ask before they act; the same tools, [wired into n8n](https://www.goodbarber.com/blog/how-to-automate-your-goodbarber-app-with-n8n-and-mcp-no-code-required-a1523/), run fully unattended. The server's job is to keep both modes safe, with per-app OAuth scope, typed tools, and verified writes. We fully intend to take this further. The list above is just where the honest line sits today. If you have a GoodBarber app: add a custom connector in Claude (or any MCP client), point it at `https://mcp.goodbarber.dev/mcp/sse` , sign in with your account, and ask for something small. "Fix the typo in my latest article" is a good first test. The [complete MCP guide](https://www.goodbarber.com/mcp-complete-guide/) covers per-client setup. If you're building an MCP server for your own platform: the pattern that held up for us in production is boring and worth stealing. Typed tools namespaced by domain, per-tenant OAuth scoping, feature-gated tool exposure, and forced read-back on every write. Questions welcome in the comments; I'll answer with real payloads where I can.