DEV Community: Pierre- Laurent Medori

Our MCP server is now a ChatGPT plugin

Pierre- Laurent Medori — Fri, 14 Aug 2026 12:06:29 +0000

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.

MCP 2026-07-28 from the server side: Codex already speaks it, Claude doesn't yet

Pierre- Laurent Medori — Thu, 13 Aug 2026 12:52:51 +0000

On July 28, the Model Context Protocol project shipped a new spec revision, 2026-07-28. I run backend engineering at GoodBarber, and our public MCP server is a live production surface: real apps, real content, real push notifications. So for us a new revision is not a changelog to skim on a Friday. It is a migration with our name on it.

We have just brought the server up to the new revision. This post is three things: the operator's cut of what changed, what upgrading a public server actually involves, and the thing we found in our logs while checking the work. The last one is the reason I'm writing.

The operator's cut of 2026-07-28

The headline is the stateless core. MCP grew up as a stateful, bidirectional protocol: an initialize handshake, a negotiated session, an Mcp-Session-Id header to carry it all. The new revision retires that entirely. Every request now self-describes in _meta: protocol version, client identity, capabilities. The practical consequence is the one server operators have wanted since day one: you can put an MCP server behind a plain round-robin load balancer with no shared session storage. If you have ever kept session affinity alive with duct tape, you know exactly which muscle just relaxed.

The rest, fast:

Method and tool names now also travel in Mcp-Method and Mcp-Name HTTP headers, so gateways can route and meter without parsing JSON bodies.
Multi Round-Trip Requests: a call can come back with resultType: "input_required" and continue over stateless connections. Mid-call questions no longer need a held-open stream.
List results (tools, prompts, resources) carry ttlMs and cacheScope, so clients can finally cache your inventory honestly instead of guessing.
Authorization hardening: RFC 9207 issuer validation, and Client ID Metadata Documents replacing Dynamic Client Registration.
Tasks, MCP Apps, and Enterprise Managed Authorization become formal extensions instead of core features.
Roots, Sampling, and Logging are deprecated, with a minimum twelve months of support before removal.

All four Tier 1 SDKs spoke the revision on launch day, which for a protocol this young is genuinely good release engineering.

Upgrading without breaking anyone

Here is the constraint that shapes everything when your server is public: you do not get to move your clients. Every agent that connects brings its own dialect, and you serve all of them or you break someone's production workflow.

So "upgrading" really means "adding a dialect". The old initialize path stays up for clients that expect it. The stateless path answers clients that self-describe. And one rule keeps the whole thing sane: the declared protocol version selects the behavior, never the client name. You would be surprised how tempting user-agent sniffing becomes during a migration. Resist it. The version declaration is the contract; the client name is trivia.

The other rule is older than MCP: nothing gets removed the day the spec says "deprecated". The spec gives Roots, Sampling, and Logging at least twelve months. The real clock is not the spec calendar. It is in your own logs, which brings me to the fun part.

Then we read the logs

We still verify upgrades the old-school way at GoodBarber: a human reads the code, and a human reads the logs. No dashboard, no pipeline, just grep and eyes. Last week that habit produced a whole article about llms.txt. It keeps paying for itself.

The protocol version a client speaks sits in plain text: in the initialize params for old-style clients, in the version declaration on each request for new-style ones. So during the development phase of the upgrade, we looked at who declares what on our traffic.

What we saw surprised us. Requests from OpenAI's Codex were already declaring 2026-07-28. The revision was barely two weeks old. Meanwhile, Claude clients were still opening with initialize on an earlier revision, exactly as they always had.

Let me be precise about what this is not. It is not a scoreboard. Pinning a revision and upgrading deliberately is what a well-behaved client does. Serving several revisions at once is what a well-behaved server does. Both populations got exactly what they asked for, which is the entire point of version negotiation.

But it is a data point you can only see from the server side, and it killed a lazy assumption I was carrying: that adoption of a brand-new revision would sit near zero for months, so supporting it "eventually" would be fine. In reality, part of your traffic may speak the newest revision before your migration branch is merged. And the split does not fall where intuition puts it: I would not have bet on which client family moved first.

If you run an MCP server

Four suggestions, all cheap:

Log the declared protocol version. One field per request. It is the cheapest telemetry you will ever add, and it is the only ground truth you have for deprecation decisions.
Test against real clients, plural. If you validate against a single vendor's client, you will quietly extrapolate that client's dialect to the whole world. Our logs contradicted our intuition within days.
Plan removals from your version distribution, not from the spec calendar. Twelve months is a floor, not a schedule. If a revision still carries real traffic, it stays.
Key behavior on the declared version, never on the client name. Negotiation is the contract you both signed. Honor it in both directions.

The upgrade itself was the unglamorous kind of work that never makes a launch post. But the logs made it worth a story: protocol adoption is happening faster, and more unevenly, than the discourse suggests, and every server operator is sitting on the evidence.

If you operate an MCP server: what does your version distribution look like? I am genuinely curious whether "Codex first" is universal or just our traffic.

One line on where I'm writing from: I run engineering at GoodBarber, an app platform. We run a production MCP server and publish open-source Claude Skills — so the 2026-07-28 migration is a live problem for us, not a thought experiment.

llms.txt in the wild: 1,321 requests, and not one AI assistant came looking

Pierre- Laurent Medori — Tue, 11 Aug 2026 12:31:16 +0000

We publish an llms.txt on our main domain and on every language portal. It is exactly what the proposal asks for: a curated markdown index of the site, at the root, written for AI systems to read. I pulled four months of nginx logs to answer one question: who actually reads it?

From April 7 to August 5, 2026, our front-ends served 1,321 requests to /llms.txt and /llms-full.txt across eleven hostnames (plus a few stray subdomains). About eleven a day, 92 percent answered with a 200. That volume already tells you this is not a busy interface. But the volume is not the story. The story is who those requests came from, because I went through every one of them, checked the interesting ones against published IP ranges, and the answer says something uncomfortable about the file, and something genuinely funny about the ecosystem around it. Ahrefs and Evil Martians have already counted this traffic at scale, and I will point at both. What I wanted was per-request forensics: when a hit wears an AI badge, is it real, and who sent it?

One line of context so you know where I stand: I run engineering at GoodBarber, an app platform. We run a production MCP server, we publish Claude Skills, we want the machine-readable web to work. This is not a takedown by someone who resents agents. It is a log review by someone who ships for them.

What llms.txt promised

Quick recap, then the data. llms.txt was proposed by Jeremy Howard in September 2024: a markdown file at your site root "to provide information to help LLMs use a website at inference time". Same placement logic as robots.txt and sitemap.xml. Mintlify made it a default for every docs site it hosts in November 2024, Shopify quietly shipped it to storefronts in spring 2026, and Originality.ai's tracker counted an 8.8x adoption jump in a year. On the publish side, the format is a success.

The open question was always the other side: does anything read it? Not "does anything fetch any file on the internet", because scanners fetch everything. Does the intended audience, the assistants and their crawlers, actually consume it?

Who actually reads our llms.txt

Here is the reader board for our 1,321 requests, by user-agent:

Reader	Requests	What it is
Generic browser user-agents, HeadlessChrome, WebPageTest agents, assorted scripts	~600	tools that did not bother introducing themselves
`satoric-indexer/0.1`	116	unknown indexer; even Ahrefs could not identify it
Googlebot	80	URL crawling, and Google says it ignores the file
`closing-web-clock/1.0 (+policy-surface observation)`	54	anonymous project observing "policy surfaces"; zero public footprint
SemrushBot SiteAudit	46	SEO audit tool
BuiltWith	44	tech profiler
`LLMS-Txt-Scanner/1.0 (Research)`	31	anonymous scanner on Azure IPs, self-labeled research
`AgentRadar-Research/1.0 (BCG Henderson Institute; agentic-web-research)`	29	identifies itself as a BCG crawler studying the agentic web; Evil Martians logged the same operator
`statespace-indexer/0.1`	27	agentic-web indexer; its likely parent repo was archived on August 5, 2026
`prompt-injection-survey/1.0 (research)`	21	self-described security research scanning llms.txt as an attack surface

SEO auditors, tech profilers, headless browsers, and a small zoo of research scanners. So far this matches what Ahrefs found across 137,210 domains in June (97 percent of llms.txt files got zero requests; of the traffic that exists, SEO audit tools are the biggest reader at 21.7 percent, AI assistants 2.5 percent), and what Evil Martians found in their own logs in July. Both are worth your time. Neither answered the question I actually had, which is why this post exists: when a request does carry an AI assistant's name, is it real, and did the assistant come on its own?

The 26 requests that wore an AI badge

Out of 1,321 requests in four months, exactly 26 carried the user-agent of an AI assistant or its crawlers. I checked each one against the vendors' published IP ranges (gptbot.json, chatgpt-user.json, searchbot.json, perplexitybot.json, and Anthropic's known blocks). They decompose like this:

Three were impostors. A single DigitalOcean IP requested our llms.txt three times in the same second, presenting as GPTBot/1.0, then PerplexityBot/1.0, then ClaudeBot/1.0. Bare version strings, none of the vendors' real UA formats, an IP in nobody's published ranges. Somebody's compliance checker cycling through bot costumes to see if we cloak (serve different content to bots than to humans). If you count assistants by user-agent alone, your llms.txt numbers include this.

Four were GPTBot, genuinely. All four IPs validate against OpenAI's published gptbot.json ranges. This is the interesting part, because all four requests carried a Referer header. Three referers were https://agentready.md, an AI-readiness checker that validates llms.txt files and runs a public leaderboard of them. The fourth was https://sitestatsdb.com, which I could not even inspect, because it now sits behind a bot-verification wall. GPTBot did not wake up wanting our llms.txt. It crawled third-party pages that link to our llms.txt, and followed the links like it follows any link. In four months and 215,484 GPTBot requests to our sites, the number of times it requested llms.txt without a third party pointing at it: zero.

I think this detail matters beyond our logs. Ahrefs found GPTBot to be the single biggest AI fetcher of llms.txt files (4.51 percent of requests) and concluded, correctly, that "Zero requests came from AI bots for llms.txt files that don't exist. They never go looking." Our referer data shows the mechanism behind both facts: an ecosystem of llms.txt directories and audit tools now links out to these files, and a crawler that follows links will follow those too. The training crawler "reads" llms.txt the way it reads any URL it encounters: as content, not as protocol. The llms.txt promotion ecosystem is generating the llms.txt consumption statistics.

Ten were ChatGPT-User. Azure IPs, half of them in the current published rotation (the list rotates, and these hits go back to April). ChatGPT-User is OpenAI's on-demand fetcher: it fires when a human asks ChatGPT something that requires opening a specific page. Ten requests in four months, each one meaning a human request was behind the fetch. Given what people use ChatGPT for these days, my honest guess is "check my site's llms.txt" prompts and GEO (generative engine optimization) audit tools, and I cannot rule out that some of those humans were us.

Two were ClaudeBot. Anthropic's crawler, from its usual 216.73.216.x block. These are the only two requests in the entire window where a dedicated AI crawler fetched the file with no referer and no human in the loop. Two, out of 262,242 ClaudeBot requests to our sites in the same period. Credit where due, and note what it is: the training crawler stocking a corpus, not an assistant consulting an index on a user's behalf. No user-facing assistant ever came on its own.

Four were Claude-User and three were Claude Code. Claude-User is Anthropic's on-demand fetcher, same story as ChatGPT-User: a human asked. The Claude Code hits are the most telling: Claude-User (claude-code/2.1.x) requests coming from a residential ISP line in France and a French cloud box. That is a developer at a keyboard pointing Claude Code at the file, quite possibly someone on my own team. It is also the one documented use case that actually works: a coding agent reading a docs index because a human told it to.

Meanwhile, in the same logs

Now the control group, because "assistants do not read llms.txt" could just mean "assistants do not read us". They read us plenty. Same window, same domains, AI bots only:

User-agent	Requests, all paths	Requests to /llms*, unprompted
ChatGPT-User	472,985	0 (10 user-triggered)
Meta-ExternalAgent	369,504	0
ClaudeBot	262,242	2
GPTBot	215,484	0 (4 via directory links)
OAI-SearchBot	171,121	0
PerplexityBot	63,475	0
Perplexity-User	22,667	0
Claude-User	19,324	0 (4 user-triggered)
Claude-SearchBot	17,512	0
DuckAssistBot	6,511	0
Claude-User (claude-code)	4,513	0 (3 user-triggered)

That is 1.6 million requests from AI systems in four months. ChatGPT-User alone made 89,668 blog-article fetches, about 740 a day, triggered by real people asking real questions; our most-fetched pages are deep technical pieces on app store compliance that classic SEO metrics would call worthless. The assistants are not ignoring our content. They are devouring it, hundreds of article fetches a day. And in the same four months, the file that exists specifically for them was fetched unprompted exactly twice, both times by the training crawler. Every other AI-labeled visit had a human behind it or a link in front of it.

And the ratio that settles it: Claude Code user-agents made 4,513 requests to our pages in four months. Documentation pages mostly, 2,264 hits on /help/ alone, plus 1,182 on the blog. Number of those requests that went to llms.txt: three. Even the archetypal llms.txt consumer, the coding agent that the strongest case for llms.txt is built on, overwhelmingly goes straight to the actual pages.

This is consistent with everything the vendors themselves publish, by the way. OpenAI's bot documentation explains robots.txt directives and never mentions reading llms.txt. Same for Anthropic's and Perplexity's. Google wrote it into its official AI documentation in June: "Google Search ignores them." Meanwhile all three AI vendors publish llms.txt files for their own docs sites, largely because their docs platforms generate one by default. Everyone is publishing the format. Nobody is committing to consume it.

John Mueller said it plainly back in April 2025: none of the AI services have said they use it, "and you can tell when you look at your server logs that they don't even check for it." Fifteen months later, on our logs, still true.

An object of research before an object of use

So who is left? Go back to the reader board. Once you remove the SEO auditors, the profilers, and the scripts, the most attentive readers of our llms.txt are research crawlers: an agent presenting itself as BCG Henderson Institute research on the agentic web, an anonymous LLMS-Txt-Scanner running from Azure, a closing-web-clock observing "policy surfaces", a statespace-indexer whose likely operator archived its repo the day before I wrote this, and my personal favorite, prompt-injection-survey/1.0 (research): a self-described survey of llms.txt as a prompt injection attack surface, because a plaintext file that sites voluntarily write for LLMs to ingest is, of course, a lovely place to plant instructions. All of this assuming their user-agents tell the truth, which, as the DigitalOcean impostor demonstrated, is optional. Ahrefs found the same pattern at scale: 12 percent of all llms.txt requests come from tools auditing, scoring, validating, or studying llms.txt itself.

The file has a thriving ecosystem of directories that list it, auditors that score it, scanners that catalog it, researchers that study it, and security people who probe it. Every layer of that stack is real and shipping. The one layer that does not exist is the consumer it was designed for.

llms.txt has become an object of research before ever becoming an object of use.

I want to be fair to the proposal here: nothing in the spec is wrong. It is a reasonable, well-designed answer to a real problem, context windows are finite and HTML is noisy. The assistants simply built around the problem instead: they fetch the real pages on demand, at scale, triggered by user questions. The protocol layer the file was supposed to occupy got filled by retrieval.

What I would actually do

My recommendation, which is what we do ourselves:

Keep the file if it costs you an hour. Ours stays. It is one hour of maintenance, it is harmless, and if a platform someday announces real consumption, you are ready. Google's official position is literally "won't harm (nor help)".
Keep it accurate, precisely because humans send agents to it. Every genuine assistant-family read in our logs, the two ClaudeBot fetches aside, had a human behind it or a link in front of it. Those are the readers you are writing for: a developer pointing Claude Code at your docs, a prospect asking ChatGPT to look at your file. Stale content there is worse than no file.
If you have developer docs, that is the one real use case. Coding agents directed at an llms.txt index do consume it (tooling like mcpdoc is built on exactly this). If your product has no docs for developers, your llms.txt is decoration.
Never report it as an AI-visibility deliverable. If someone bills you for "GEO optimization" and the deliverable is an llms.txt file, you now have four months of somebody else's server logs saying what that is worth. What actually got our content into assistants, per the same logs: deep, specific, technical articles that answer the questions people actually ask, plus a robots.txt that lets retrieval bots in.
Treat the file as code, not copy. Version-control it, restrict who edits it, keep it to plain links and descriptions. The most motivated readers of the format right now include people studying it as an injection surface. Do not give them material.

Check your own logs

Methodology, so you can replicate: 121 days of nginx access logs (April 7 to August 5, 2026) across our production hostnames, every request matching GET /llms, user-agents tallied, and every AI-labeled hit checked against the vendors' published IP ranges where they exist (OpenAI, Perplexity), and, for Anthropic, which publishes no list, against the blocks that carry its 262,000 other requests in the same logs. One caveat cuts both ways: user-agent strings are claims, not proofs. Our ~600 generic-browser requests surely hide a few interesting readers, and any study that counts assistants by UA alone, including this one before the IP checks, will overcount them. Could an assistant fetch llms.txt in stealth, hiding in those 600? In principle. But a vendor that cheerfully declares itself on 1.6 million fetches to the same servers has no evident reason to go incognito for this one file.

The whole analysis is a couple of grep and awk commands. If you publish an llms.txt, run them. The base rate says you will find silence; if you find an AI assistant that came looking on its own, unprompted, no referer, IP in the vendor's published range, I genuinely want to see that log line. Comments are open.

Your MCP write returned 200. Did the right thing actually happen?

Pierre- Laurent Medori — Thu, 06 Aug 2026 13:09:00 +0000

The failure mode that worries me most in agent tooling is not a crash. It looks like success.

An operator, somewhere, asks their agent to put the summer collection on sale. The agent discovers the products, loops over the variants, fires four hundred write calls, collects four hundred 200s, and reports back, confident and polite: "Done! All prices are updated." And they are. On the wrong collection.

Nothing in that transcript failed. The transport worked. The writes persisted. The agent did not hallucinate a single call. Yet the one thing the operator actually wanted, "the summer collection, on sale, nothing else", is not what happened. If you have shipped distributed systems you know this smell: every component is green and the system is wrong.

I run engineering at GoodBarber, an app platform, and our MCP server exposes a live production surface: content, commerce, push notifications, real apps with real users. So this is not a thought experiment for me. And judging by the comments on my last piece and the threads landing on r/mcp lately, it is not a thought experiment for many of us anymore.

Three different things we call "success"

When an agent reports "done", that word is doing a lot of undeclared work. Unpack it and there are three separate claims stacked on top of each other:

Transport success. The request arrived, the server answered, nothing threw. HTTP 200, no protocol error. This is the only one of the three the agent gets for free.
State success. The write persisted: the article exists, the price changed, the push is scheduled. This is what a verified read-back proves.
Intent success. What persisted is what the operator meant, within the policies of the account. The right collection. The right segment. The right amount.

Language models are spectacular at conflating the three. A 200 becomes "done"; "done" becomes "what you wanted". Not because the model lies, but because nothing in the loop ever represented intent explicitly, so the model reports the only success it can observe.

After my last piece, an engineer I traded notes with put the gap in one line I have not managed to improve on: given only transport success, the agent will "faithfully confirm the wrong thing." Confirmation is not correctness. A model that is perfectly honest about what it saw can still be wrong about what it did.

Where verified read-back stops

In my last piece I argued that an application MCP server should verify writes as a matter of server contract. On our server, every write result carries _mcp_policy.verification_required: true: the server itself instructs the agent to read the object back through the public read path and confirm the result before declaring success. I still believe every word of that. Read-back closes the gap between transport and state, and it catches the most common agent failure in the wild, which is declaring success on a write that never landed.

But I want to be honest about where it stops. Read-back proves the object changed the way the call said it would. It cannot prove the call was the right call. In the repricing story above, read-back passes four hundred times in a row. Wrong collection, verified thoroughly.

Necessary, not sufficient. That exchange, and those threads, shaped the list below: the layers that close the rest of the gap.

The layers that close the gap

None of this is exotic. Most of it is decades of transactional common sense applied at a new boundary: the line between a language model and your production system. Each layer kills one specific class of failure.

1. Scope the credential, not the prompt

"Please only touch the blog" is not a permission model. The prompt is reachable territory for anyone who can get text in front of your agent: a product review, a support ticket, a pasted document. If the prompt is the only thing standing between the agent and a tool family it should never use, you do not have scoping, you have a suggestion.

Scoping has to live where the prompt cannot reach it: in the credential. On our server that takes two forms. Sessions are bound by OAuth to a single app, so an agent connected to app A cannot discover that app B exists. And the tool list is generated from what the app has enabled: no shop, no shop_ tools; push not configured, no push tools. The families the agent must not touch are not denied, they are absent from the inventory. Billing, design, and the build pipeline are not on the surface for anyone. The server card is public if you want to see what a feature-gated inventory looks like.

What this buys you: a compromised or confused session cannot escalate. There is nothing to escalate into.

2. Idempotency, because agents retry

Agents retry. Clients time out and replay. Runtimes resume interrupted loops. In human API usage a duplicate submit is rare; in agent usage, retry-on-ambiguity is standard behavior, which means "the network blinked between the request and the response" must never be able to mean two pushes or two charges.

The first half of the answer is declarative, and MCP already has the vocabulary for it: tool annotations. Every tool on our card declares idempotentHint (along with readOnlyHint and destructiveHint): updates are marked safe to replay, creates and push are not, and the server-side failure policy the meta tool returns caps retries at exactly one. A client that respects the annotations will not loop a non-idempotent write on its own initiative.

The second half is where most surfaces, ours included, still have work to do: true idempotency keys on the non-idempotent writes. The mechanism transfers unchanged from classic API design: the client sends a key with the write, the server stores the outcome under that key, and a replay returns the stored outcome instead of running the write again. Stripe drilled this into a generation of engineers. MCP write tools need it for a bigger reason: the thing doing the retrying now improvises.

3. Bind the write to the version you read

Between the agent's read and the agent's write, the ground can move: another agent, a colleague in the back office, a scheduled job. A write built on a stale read should be rejected, not applied. The mechanism is old and boring: the write carries the version (or etag, or updated-at) of the object as the agent read it, and the server refuses with a conflict if the object has moved since. The agent re-reads and re-decides, with current facts.

There is a coarser flavor of precondition you can get for free at schema-design time: make illegal transitions unrepresentable. On our order tooling, the shipping-status enum only contains FULFILLED and DELIVERED, and the state machine runs one way. An agent cannot un-deliver an order, however confused it gets. If you do nothing else from this section, enum your state machines.

4. High-impact writes get a plan, then a commit

A draft article is a non-event; delete it and nothing happened. A broadcast push has no undo: our card marks it destructiveHint: true, idempotentHint: false, which is the formal spelling of "no undo, no retry". Bulk repricing touches four hundred objects in one intent. Above a certain blast radius, one-shot writes are the wrong shape entirely.

The shape that works is plan-before-commit. The first call returns a plan: what will change, how many objects, a sample of them, bound to the exact context it was computed in, with an expiry:

{
  "plan_id": "pl_9f27",
  "action": "reprice",
  "objects_matched": 412,
  "sample": ["Home Kit Hoodie 2026", "Away Kit Hoodie 2026", "..."],
  "bound_to": {
    "app": "my-shop-app",
    "object_set_hash": "sha256:c41d...",
    "tool_schema_version": "2026-07-01",
    "policy_version": 14
  },
  "expires_at": "2026-08-05T18:00:00Z"
}

Commit is a second call that references plan_id and fails if any binding moved: the object set changed, the schema changed, the policy changed, the plan expired. Between the two calls sits a human or an explicit policy, looking at "412 objects" and deciding whether that number matches the intent.

We are partway there in production and heading the rest of the way. Every tool on our server publishes its recommended discover, call, verify sequence through a meta tool (meta_get_tool_plan), and my own standing rule for push is send: "at", never now: the agent schedules, which leaves a review window between the ask and the broadcast. The plan object is where this converges, because "a number a human saw before commit" is the single cheapest defense against the wrong-collection story.

5. Verified read-back stays

Everything above is why read-back is not enough. None of it is a reason to drop read-back: it remains the floor. After every write, read the object back through the same read path anyone else would use, and compare against what was sent. It is the layer that catches the write that silently did not land, the truncation, the default that filled a field you did not send. Keep it, make it the server's contract rather than the client's memory, and stack the rest on top.

One requirement I did not fully appreciate until I ran this article's checklist against our own server: the read path you verify through must be read-your-writes consistent. While testing, I hit the mirror image of the 200-that-failed: a delete succeeded, and the immediate read-back served a seconds-stale cached copy of the object, so the verification step swore the delete had not happened. An agent following the discipline to the letter would have retried a write that had already landed, which is exactly the failure class layer 2 exists for. Read-back through a cache lies in both directions. Verify against the source of truth, or invalidate on mutation for the writing session.

6. Make the 200-that-failed observable

The nastiest property of an intent failure is that your telemetry approves of it. A standard span records transport: status code, latency, maybe payload size. It has no opinion about whether the business outcome matched the ask. On a default dashboard, the span for the wrong-collection repricing is indistinguishable from the span for the right one. All green.

The signal has to be emitted on purpose, in two places. In the tool result, where the agent can see it: a server-side outcome flag, plus the read-back requirement, so "it worked" is a claim the server participates in. And on the span, where your on-call can see it:

http.status_code     = 200          # transport: the easy part
mcp.write.readback   = "match"      # state: persisted as sent
mcp.write.outcome    = "ok"         # intent: preconditions held, plan honored

Then alert on the combination that matters: status 200 with an outcome that is not ok. That alert is the entire point of this post compressed into one rule: the failures worth paging on are the ones that returned success.

You do not remove the human. You move them.

It would be easy to read all this as "add friction everywhere", and that would be the wrong lesson. Draft states, scheduled sends, version conflicts and plan gates are all ways of sorting writes into two lanes: low-impact writes flow without ceremony, high-impact writes pause at exactly one place, the commit line.

That is not less automation. It is oversight spent where it changes the outcome. The content agents I run create drafts all day without me. Nothing reaches a user's lock screen without a human having seen the plan. Both of those sentences are policy, and I can defend each one, which is more than I could say for "the agent seems careful."

The checklist

Before an agent gets write access to a production system, you should be able to answer yes six times:

☐ Scoped: can this credential reach only the tool families this agent needs, with everything else absent from the inventory, not just denied?
☐ Idempotent: does the same write, retried, produce one change instead of two?
☐ Version-bound: does a write built on a stale read get rejected instead of applied?
☐ Previewable: do high-blast-radius writes produce a plan that a human or a policy approves before commit?
☐ Read-back verified: is post-write verification part of the server contract, not client etiquette?
☐ Semantically observable: would a 200 that did the wrong thing show up on a dashboard, or only in a customer email?

Six noes is a demo. Six yeses is something you can hand to a customer.

Takeaway

Getting an agent to call your write tools and collect 200s is the easy 80 percent, and it is the part every MCP server demo shows. The remaining 20 percent, making sure the right thing happened and making it survivable when it did not, is unglamorous server work: scopes, keys, versions, plans, read-backs, span attributes. It is also, I think, where production MCP surfaces will actually differentiate from here on.

The surface these notes come from is documented at goodbarber.com/mcp if you want to see the choices in context.

What is in your write-safety stack that I missed? Genuinely curious. The comments on the last piece made this one better.

I gave an AI agent the keys to a live production app: here's the MCP setup

Pierre- Laurent Medori — Fri, 31 Jul 2026 13:21:47 +0000

AI agents are good at writing code. What they mostly cannot do is operate the software you already run in production: publish the article, schedule the push, fulfill the order. Not because the models are incapable, but because most production apps expose no structured surface an agent can act on.

MCP fixes exactly that. This post is the hands-on setup I use to let an agent operate a live mobile app: real endpoint, real tool calls, real payloads, and the gotchas I hit.

Disclosure up front: I run engineering at GoodBarber, an app platform, so the production app in this post runs on our MCP server. The patterns transfer to any remote MCP server you point an agent at.

Connect it

The server is a hosted remote MCP server. No npx, nothing local to run:

https://mcp.goodbarber.dev/mcp/sse

The /sse path is historical; the server answers both SSE and Streamable HTTP, so every current client works.

Claude Code:

claude mcp add --transport sse goodbarber https://mcp.goodbarber.dev/mcp/sse

or in .mcp.json:

{
  "mcpServers": {
    "goodbarber": {
      "type": "sse",
      "url": "https://mcp.goodbarber.dev/mcp/sse"
    }
  }
}

Claude (claude.ai): Settings, then Connectors, then add a custom connector with that URL.

ChatGPT: Settings, then Apps & Connectors, enable Developer mode, create a connector with the same URL. Write actions worked on a free account when I tested it; OpenAI's docs gate some of this by plan, so verify on yours.

Codex: add a custom MCP server, transport Streamable HTTP, leave the bearer token field empty. Saving opens the OAuth flow.

The first tool use triggers OAuth in the browser: you sign in with the app's account, and the session is scoped to that single app. No API key to paste anywhere. That scoping does a lot of security work later.

After OAuth, the client pulls the tool list. What the agent sees is not "the API": it is an operations menu, namespaced by domain. The cms_ tools cover articles, events, and media. The shop_ tools cover products, variants, orders, and promo codes. The classic_ tools cover push, analytics, and memberships. The full inventory is public in the server card, which is the file to read before writing any client code:

https://mcp.goodbarber.dev/.well-known/mcp/server-card.json

First real call: schedule a push

Push is the scariest operation to hand an agent (a sent push has no undo), which makes it the best test of a server's design.

Me, in the chat:

Schedule a push for 6 PM tonight: "Doors open at 7. First 50 people get the poster."

The agent calls classic_create_push_broadcast:

{
  "message": "Doors open at 7. First 50 people get the poster.",
  "send": "at",
  "send_at": "2026-07-29T18:00+02:00"
}

Three details in this schema are worth noticing:

message is capped at 255 characters server-side, so the agent gets a hard error instead of a silently truncated push.
send is an enum, now or at; scheduling requires the timezone-aware send_at, and the tool handles the UTC conversion. The agent does no date math.
The tap action is structured too: action_type is one of open_app, external_link, or section. "Open the tickets section" resolves to a real section id, not a guessed deeplink.

The result comes back confirming the scheduled send, along with something rarer: a policy block. Every write on this server returns _mcp_policy.verification_required: true. The server's own guidance tells the agent to read back what it just wrote before declaring success. There is even a meta tool for this: meta_get_tool_plan takes a tool name and returns the recommended discover, call, verify sequence plus the failure policy. Agents follow instructions embedded in tool results remarkably well; putting that discipline server-side beats hoping every client prompt remembers it.

Operate the app: one call per domain

Publish an article (CMS). cms_create_article wants a title and category ids, and category ids come from cms_list_cms_sections first. Discover, then write:

{
  "title": "Matchday guide: what to know before Saturday",
  "categories": [4821],
  "status": "stock",
  "publishedDate": "2026-08-01T08:00:00+02:00"
}

status is published, draft, or stock; a future publishedDate requires stock, which is the scheduled state. Body content is its own resource: cms_create_article_paragraph, one call per paragraph, with cms_reorder_article_paragraphs when the agent restructures. There is also an accessTier field (free or premium) that hooks straight into the app's paywall.

Add a product and a variant (shop). shop_create_product first:

{
  "title": "Home Kit Hoodie 2026",
  "status": "DRAFT",
  "collections": [312]
}

then shop_create_variant:

{
  "product_id": 88410,
  "price": "49.00000",
  "stock": 120,
  "sku": "HK26-M",
  "option_values": [{ "option_id": 17, "value": "M" }]
}

Two things I like here. price is a decimal string, not a float: whoever wrote this schema has met floating-point money. And the variant model is strict: all variants of a product must share the exact same set of option_ids, so introducing a Size option on one variant forces you to define it on all of them. That is a real invariant of the commerce domain, enforced at the tool layer. A raw database connection would let your agent violate it silently.

Look up and update an order (fulfillment). shop_list_orders filters by status and date range. shop_update_order_shipping moves an order along a one-way state machine, PENDING → FULFILLED → DELIVERED, with optional tracking:

{
  "order_id": 55231,
  "status": "FULFILLED",
  "shipping_tracking_num": "6A0301234567",
  "shipping_tracking_url": "https://tracking.example.com/6A0301234567"
}

The status enum only contains FULFILLED and DELIVERED. You cannot un-deliver an order through this surface, however confused the agent gets.

Pull the numbers (analytics). classic_list_downloads and classic_list_page_views take plain ISO date ranges and return aggregates. The stats family is read-only by construction; there is nothing to break. My standing Monday ask is one sentence: last week's downloads and page views versus the previous week, flag anything odd.

The security model (the part that actually matters)

This is what I would look at before connecting an agent to anything in production:

OAuth per app, not per account. The session is scoped to a single app. Connect App A and the agent cannot tell App B exists. Agencies operating many client apps add one connection per app; there is a per-app URL form for that, on a white-label domain if you resell.
Feature-gating shapes the tool list. The tools exposed are a function of what the app has enabled. Connect an app with no shop and the shop_ namespace is simply absent; push not configured, no push tools. The agent cannot call what it cannot see. Corollary if you write client code: never hardcode the tool list, read it at connect time or from the server card.
Verify-after-write is server policy, not client etiquette. The _mcp_policy block rides on every write result.
No design surface. Nothing in the inventory touches layout, navigation, or the build pipeline. The blast radius of a bad agent day is content, campaigns, and commerce state, all inspectable in the back office. Not the app itself.

Skills: the recipes layer

On top of the server, there is an open-source repo of 44 Skills: markdown recipes in the Claude Skills format, one per workflow (create a product with variants, schedule a push campaign, process the morning's orders, and so on). They encode the discover-then-write sequences above so the agent does not rediscover them every session:

https://github.com/goodbarber/goodbarber-skills

The terms allow rebranding and redistribution; they were written for resellers. The server itself is proprietary. The recipes are the open part.

Trade-offs and gotchas

Things I would want to know before recommending this to another engineer:

The tool list varies per app. A tool name from a tutorial (or this post) may be absent on your app because the feature is off. Check the list, not the docs.
Conversational operations do not batch. Three hundred products means three hundred shop_create_product calls. Bulk import stays a back-office job; the agent shines on the daily delta, not the migration.
Verify-after-write costs round trips. A multi-step ask (product, three variants, launch push) runs tens of seconds, not milliseconds. That is deliberate, and the right trade for writes on a live app.
IDs, not vibes. Agents guess names when you let them. Make them discover first (cms_list_cms_sections, shop_list_products); meta_get_tool_plan returns exactly that sequence per tool.
Keep a human on send. My own rule: the agent schedules pushes with send: "at" rather than now, so there is always a review window between the ask and the broadcast.
One app per connection. A multi-app morning means multiple connectors. Scoped beats convenient.

Takeaway

Everyone is racing to make agents build software. The quieter and, I think, more useful shift is agents operating the software you already have. Building is a one-time event. Operating is every day.

If you want to poke at a live implementation: the server card is public, the Skills repo is open, and the non-dev version of this story lives at goodbarber.com/mcp.

Not all MCP servers are equal: BaaS MCP vs application MCP

Pierre- Laurent Medori — Wed, 29 Jul 2026 13:10:29 +0000

Every platform now advertises an MCP server, and the label tells you almost nothing. Two servers can carry the same three letters and hand an AI agent completely different powers: one gives it your database, the other gives it your live app. Here is the difference between a BaaS MCP and an application MCP, and why that altitude decides what an agent can actually do for you.

"Has an MCP server" is the wrong question

The short version. An MCP server is only as useful as what it exposes. BaaS platforms such as Back4app and Supabase expose their backend: database tables, schemas, queries, cloud code. GoodBarber's MCP server exposes the operations of a live mobile app: publish an article, schedule a push, update the catalog, read the stats. 150 domain-typed tools at the time of writing, feature-gated, scoped to one app by OAuth, with a verified read-back on every write. Same protocol, very different altitude.

The Model Context Protocol has won fast. Introduced by Anthropic in November 2024 and donated to the Linux Foundation a year later, MCP is now the standard way to hand tools to an AI agent, with more than 9,400 public servers listed in the official MCP Registry in 2026. Which means the phrase "we have an MCP server" has quietly become a checkbox. Every platform can tick it, and the tick tells you nothing.

The questions that matter sit one level deeper. What does the server let an agent see? What does it let an agent change? And when the agent writes, what stands between a well-phrased prompt and a broken production system? The answers depend far less on the protocol, which is the same for everyone, than on the altitude at which a platform plugs into it.

Two altitudes: MCP for your database, MCP for your app

Backend-as-a-Service platforms plug MCP into their infrastructure layer. Back4app's MCP server, as its documentation describes it in July 2026, lets an agent create and manage Parse apps, define database schemas, query and modify objects through the Parse REST API, manage users and permissions, and deploy cloud code. Supabase's official MCP server points the same way: list tables, execute SQL, run migrations, manage branches and Edge Functions. These are real, useful capabilities. They are also unmistakably backend-shaped: what the agent reads and writes are rows, schemas and deployments. Call it MCP for your database.

GoodBarber plugs MCP in at a different altitude: the application itself. GoodBarber's MCP server exposes the operations of a finished, published mobile app: publish an article, schedule a push notification, create a product with its variants, update an order, read the analytics. The agent never sees a table. It sees the same product-level actions the app's owner sees in the back office. Call it MCP for your app.

A BaaS MCP hands an agent the keys to your data. An application MCP lets an agent run your product, safely.

Side by side:

Dimension	BaaS MCP server	Application MCP server
What the agent sees	Tables, schemas, rows, cloud functions	Articles, push campaigns, products, orders, stats
A typical tool	Run a SQL query, create a database class	`cms_create_article`, `classic_create_push_broadcast`
A write is	A raw data mutation	A product action, run through the application layer
Guardrails	Read-only modes, project scoping	Feature gating, per-app OAuth, verified read-back on every write
Built for	Developers in AI coding tools	Any operator, technical or not, in any MCP client
Examples	Back4app, Supabase	GoodBarber

Why the altitude changes everything

Same protocol, same JSON, same agents on the other end. Four things change completely.

Semantics: the agent knows what it is doing

A backend tool speaks data. An application tool speaks intent. When an agent's tool is a raw SQL query, the agent knows it is inserting a row; whether that row makes sense as a product, a subscriber or a campaign is entirely the prompt's problem. When an agent calls classic_create_push_broadcast on GoodBarber's server, the tool's name, its typed schema and its constraints already encode what a push campaign is. There is far less room to be confidently wrong, because the domain knowledge lives in the tool, not in the prompt.

Safety: where the guardrails live

Good BaaS MCP servers do ship controls, and they matter: Supabase, for instance, offers a read-only mode and project scoping. But at database altitude, a permitted write is still a raw mutation. Nothing checks that the new row respects the invariants your application enforces everywhere else.

GoodBarber's MCP server enforces its guardrails at the product level, on the server side. Feature gating: a tool only exists if the matching feature is active in the app, so an app without push configured exposes no push tools at all. Per-app OAuth scope: every session is bound to one authenticated app, an agent connected to app A cannot see or touch app B, and agencies connect each client app separately. Verified writes: every write returns a server-side flag requiring the agent to read the object back and confirm the result before moving on. Hallucinated success is the failure mode agents are most prone to; GoodBarber's answer is to make verification part of the server's contract rather than a best practice left to the prompt.

Completeness: a database is not a product

An agent with full control of your backend still controls no product. The mobile app around that backend remains yours to design, build, connect, submit to the App Store and Google Play, and maintain: exactly the gap we mapped in AI app builders can build an app. Can they run one? An application MCP starts on the other side of that gap. The app already exists: compiled native iOS and Android builds plus a PWA, with hosting, CMS, push infrastructure and payments included rather than assembled from separate subscriptions. The agent operates a live product from day one, and there is nothing left to build around it.

Operators: who can actually use it

Back4app's MCP documentation lists the clients it is built for: Cursor, Windsurf, VS Code, Claude Code. Developer tools, reasonably, because driving a backend safely requires a developer's judgment. An application MCP moves the interface up to plain language. A shop owner can ask Claude to reprice a product, a publisher can ask ChatGPT to publish the morning's article and schedule the push, a club manager can ask for last month's downloads, and none of them needs an IDE. GoodBarber built its MCP surface for that operator, the same person its no-code back office was built for, and it works from any MCP client, including automation platforms like Zapier.

What GoodBarber's MCP server exposes

GoodBarber runs a hosted, production MCP server: nothing to install, nothing to self-host. You plug the endpoint into your MCP client, sign in with OAuth 2, and the session is scoped to your app from the first call.The inventory is public and machine-readable. The server card lists 150 domain-typed tools at the time of writing (July 2026), namespaced by what they operate: tools prefixed cms_ cover content (articles, events, maps, photos, videos, podcasts, including scheduled publication), shop_ tools cover commerce (products and variants, collections, orders, promo codes, customers), and classic_ tools cover the running of the app (push broadcasts, analytics, memberships). The card is the contract: when the platform grows, the card grows, and connected agents pick up the new tools automatically. On top of the server, GoodBarber publishes 44 open-source Claude Skills that wrap common workflows as tested recipes, part of the same agent-ready platform push.

Just as deliberate is what the server does not expose. Design and layout stay in the builder, where GoodBarber's design system can protect them; pushing visual design through text-shaped tools does not produce good apps. And agent ready does not mean the human left the room: you grant the scope, you set the policies, and the server verifies what the agent does. Details and per-client setup live on the MCP page.

When a BaaS MCP server is the right choice

If you are a developer building custom software, with your own data model, your own business logic and your own frontend, a BaaS MCP server is exactly the right tool, and the good ones are genuinely good. Back4app's gives your coding agent a real Parse backend to build against; Supabase's does the same for Postgres, with scoping controls that show the category maturing. GoodBarber is not that tool and does not try to be: it will not host your custom backend, and it is built for content apps and mobile commerce, not for arbitrary software.

These are two altitudes for two different jobs, not two competitors on one axis. The practical test: if your project needs an agent that can touch raw data structures, you want a BaaS MCP. If it needs an agent that can run a live mobile app, you want an application MCP.

Which MCP server does your project need?

You are building custom software and want an agent working on your schema, data and cloud code: choose a BaaS MCP server such as Back4app or Supabase.
You want an agent to operate a real mobile app in production, across content, catalog, push notifications, orders and analytics: choose an application MCP server. That is what GoodBarber runs.
The app's day-to-day operator does not code: an application MCP is the only altitude that works in plain language from mainstream clients like Claude and ChatGPT.
You need both: some teams run them side by side, a BaaS MCP for the custom system a developer maintains, GoodBarber's MCP server for the mobile app the business operates. The protocol is the same; only the altitude differs.

FAQ

What is the difference between a BaaS MCP server and an application MCP server?
A BaaS MCP server exposes backend infrastructure to an agent: database tables, schemas, queries, cloud functions. An application MCP server exposes the operations of a finished product. GoodBarber's MCP server lets an agent publish content, schedule push notifications, manage a catalog and read analytics on a live mobile app, without ever touching raw data structures.

Does GoodBarber's MCP server give an agent access to my database?

No. GoodBarber's MCP server exposes product operations, not SQL. An agent works with articles, products, orders, push campaigns and stats through domain-typed tools, and every call runs through the same application layer as the back office, so business rules and validations apply. Raw table access is never on the menu.
Is an MCP server on a backend enough to run a mobile app?
No. A backend MCP server operates the data layer, and the app around it still has to be designed, built, connected, submitted to the App Store and Google Play, and maintained. An application MCP server operates an app that already exists. That is the difference between managing rows and running a product.

How does GoodBarber keep agent writes safe?
Through three server-enforced layers. Feature gating: a tool only exists if the matching feature is active in the app. Per-app OAuth scope: an agent connected to one app cannot reach another. Verified writes: after every write, the server requires the agent to read the object back and confirm the result. Safety lives on the server, not in the prompt.

What is the best MCP server for a no-code mobile app?
Judge any candidate on three criteria: tools that speak the app's language rather than raw SQL, authentication scoped to a single app, and server-enforced verification on writes. GoodBarber's MCP server checks all three, with 150 domain-typed tools at the time of writing and a public server card listing every one of them, so you can verify the inventory instead of taking the claim on faith.

See the altitude difference for yourself. Start a free trial, build your app, then plug its MCP endpoint into Claude, ChatGPT or any MCP client: connecting an agent to a live app takes about two minutes. The complete MCP guide covers setup client by client.

In-app purchases without writing StoreKit or Play Billing: selling subscriptions inside your app

Pierre- Laurent Medori — Mon, 27 Jul 2026 08:08:47 +0000

Selling a subscription inside a mobile app is one of the most demanding things you can build: StoreKit on iOS, Google Play Billing on Android, server-side receipt validation, renewals, refunds. Or, on our platform, one toggle. This post explains what that toggle actually hides, and the honest trade-off that comes with it, because there is one and it is not small.

Quick context: GoodBarber is a no-code app builder running since 2011; the platform compiles native iOS and Android apps for people who will never open Xcode. Some of those people live from their content. This is the machinery that lets them charge for it.

What in-app purchases are for (and not for)

In-app purchases sell access to digital content inside the app: premium articles, videos, podcasts, courses, members-only sections. On our platform that takes the form of subscriptions, monthly or annual, and it exists for Content Apps published as native iOS and Android builds.

What in-app purchases are not for: selling physical goods. That distinction is not a product choice, it is store law. Apple and Google require in-app purchase for digital content sold inside an app, and forbid it for physical goods and real-world services, which must go through a regular payment gateway. So an app that sells t-shirts checks out through Stripe or PayPal, and an app that sells premium podcasts checks out through the App Store and Google Play. Two different rails, two different cost structures, and no way to swap them.

Keep that in mind for the rest of this post: everything below is about the digital-content rail. The e-commerce rail is a separate module with separate economics (no store cut, standard processor fees). Mixing the two up is the single most common confusion in this topic.

When is the in-app rail the right call? When your audience is mobile-first, your product is content, and your growth depends on people subscribing at the exact moment they hit your paywall. Which is precisely the moment a payment form kills.

Why this is the hardest checkout in mobile

Here is what "selling a subscription in your app" means when you build it yourself:

Two APIs, two lifecycles. StoreKit on iOS and Play Billing on Android are separate systems with separate product models, separate testing sandboxes and separate failure modes. You implement everything twice.
A server you now operate. Purchases must be validated server-side: the store issues a receipt or purchase token, and your backend has to verify it, or your paywall can be bypassed. That means running a service, storing entitlements, and keeping it up for as long as you have subscribers.
A state machine that runs for years. A subscription is not one transaction. It renews, fails to renew (card expired), enters grace periods, gets cancelled, gets refunded, gets restored on a new phone. Every one of those events must reach your server and flip content access accordingly, or you have paying users locked out and free riders let in.
Store-specific edge cases. Restore purchases is mandatory on iOS. Refund handling differs per store. Review teams check your subscription UX against their guidelines.

None of this is exotic for a payments team. All of it is a wall for a creator, and a serious multi-week project for a developer doing it once. It is the hardest checkout in mobile because it is not a checkout: it is a long-running billing system with two masters.

What happens behind the toggle

On our side, the creator's job is to define the offer in the back office: the subscription products, monthly or annual, and the price for each store, because the App Store and Google Play each have their own pricing grids and currencies. Then they turn the feature on.

To be precise about what "we handle the rest" means: it is not one big automation. Behind the toggle there is software and there is a team, splitting the list from the previous section:

The billing machinery is software. Server-side receipt and purchase-token validation runs on infrastructure we already operate. Renewals, grace periods, cancellations, refunds and restores are processed and wired to content access: a subscriber sees the premium content, a lapsed one stops seeing it, with no code written by the creator.
The store side is our app-store experts. The creator's configuration drives the product setup with Apple and Google and the submission work around it, carried by the same team that publishes and maintains apps in the stores all day. Store-specific edge cases, and the drift of StoreKit and Play Billing over time, land on their desk, not the creator's.

One toggle on the creator's side does not mean one script on ours; it means the complexity moved to people and systems whose job it is.

For the end user, the entire experience is one tap on the store's native payment sheet. No form, no card number, no new account. The store already has their payment method on file.

The fine print, because a toggle this clean has some:

it is for Content Apps published as native builds, not PWA-only plans, and not eCommerce Apps (different rail, as covered above);
it sells subscriptions, monthly or annual, not one-time unlocks or consumable credits;
subscription access is binary: subscribers see the premium content, everyone else sees the public content. It also replaces the standard login flow; an app uses one or the other, and the back office makes you switch deliberately.

Very few no-code builders ship native in-app purchases at all; the usual answer is a plugin, a third-party billing service, and a validation server that becomes your problem. Shipping it as one toggle is rare, and it is one of the features we consider a signature.

The honest trade-off: the store cut

Apple and Google take 15% to 30% of every in-app subscription. Where you land in that range depends on their programs and your history: the small-business tiers, subscription retention past the first year. That cut is real money, and any article that shows you the toggle without the cut is selling you something.

GoodBarber adds no commission on subscriber revenue: the platform is flat-rate subscription pricing, and what your subscribers pay is yours, minus the store's share. But the store's share is structural. It is not our fee to waive; it is the cost of being on the rail.

So why accept it? Because of what the rail buys: the highest-converting checkout that exists on mobile. The user is already authenticated with the store, their card is on file, and the purchase completes in one tap at the exact moment of intent. Compare that with sending a mobile user to a web page to type a card number: conversion drops sharply, and the drop routinely costs more than the cut. The store cut is not a tax on the feature; it is the price of the smoothest checkout in mobile.

In-app or web checkout: how to choose

The alternative is legitimate: sell the subscription on your website, keep your full margin minus processing fees, and let subscribers sign in inside the app. Regulators and courts have also started forcing the stores to loosen their rules on external purchase links in some regions, so the legal ground is moving. The physics, so far, are not: a web checkout still asks a mobile user to leave the app and fill a form.

A short decision grid:

In-app wins on volume. Mobile-first audience, impulse subscriptions at the paywall moment, price points where 15-30% is absorbable: the conversion uplift usually outweighs the cut.
Web wins on margin. High-ticket subscriptions, an audience you already convert on the web, thin margins where the cut genuinely hurts.
Most creators are not choosing a religion. They are choosing a default for where their audience actually subscribes, and for a content app, that is usually inside the app.

If you are evaluating no-code platforms for premium content, here is the one question that sorts the field: who validates the receipts? If the answer involves you, a plugin and a server, you now know what you are signing up for.

Questions in the comments. happy to go deeper on the billing lifecycle or the store-specific quirks.

No-code at scale: Why the real engineering challenge is the treadmill, not the editor.

Pierre- Laurent Medori — Tue, 21 Jul 2026 07:52:11 +0000

"No-code" sounds effortless. Configure your app in a browser, hit publish, done. And that is exactly how it should feel, for one app, seen from the outside. Keeping thousands of no-code apps alive and published, for years, is another job entirely. This post opens the machine room: hosting, push delivery, store submissions, and the maintenance treadmill running underneath.

Quick context: GoodBarber is a no-code app builder running since 2011. Customers configure an app in a web back office; the platform compiles native builds (Swift for iOS, Kotlin for Android) plus a PWA, and operates everything those apps need at runtime. That last clause is the subject here.

What "at scale" means for a published app

The demo problem and the production problem are different problems. Any stack can produce one app that works today. A published app is a longer commitment: a binary sitting in two stores behind two review processes, a backend it calls every day, push credentials that expire, an OS release every year and store policies that move under your feet.

Scale, in our case, as of mid-2026:

thousands of live apps in production;
one download every 4 seconds across the fleet, about 20,000 a day and 8 million a year (measured over 29 days in April 2026);
paying customers in 152 countries;
a platform running since 2011, so "long-term" is measured in OS generations, not in sprints.

The operative definition of scale is multiplication. With one app, a store policy change costs you an afternoon. With thousands, every external change becomes a fleet event: whatever Apple or Google decides this quarter, multiply it by every app in production. The entire architecture below exists to make that multiplication survivable.

The infrastructure nobody sees

Hosting. GoodBarber is its own hosting provider. We rent rack space in large European datacenters and run our own machines there: several racks of hardware, not a tenancy on someone's hyperscaler. The backend is multi-tenant: thousands of apps share the platform's services, each with its own content, configuration and API surface, and the CDN in front of it moves several terabytes a day. Running the hardware ourselves keeps the data question short (one company, one jurisdiction, servers in Europe) and puts capacity planning where it belongs: on us, once, instead of on thousands of individual app owners.

Push, at volume. The platform delivers several million push notifications a week. The app owner's view of that sentence: write the message, pick the audience, send now or schedule. Everything else is ours:

fan-out to APNs and FCM, with per-app credentials provisioned and rotated;
device-token hygiene: tokens die constantly (uninstalls, device restores, OS reinstalls), so delivery responses have to be consumed and dead tokens pruned, or delivery rates rot silently;
payload limits, throttling, retries, and the scheduling queue that turns thousands of "send at 9am" campaigns into synchronized bursts of individual deliveries.

Reliable push is a data-hygiene problem at least as much as a throughput problem. The throughput is bursty and predictable; the token decay never stops.

Store submissions, handled by people who do it all day. A dedicated publication team submits and maintains apps in the App Store and Google Play. The baseline that team works against: Apple rejects approximately 42% of first submissions (measured across the submissions our team handled over the last 12 months; that is Apple's baseline, not our failure rate). The team recovers 91% of those first-submission rejections. On updates, upstream prevention work makes rejections rare in the first place. App review is not an API call that returns 200; it is a negotiation with guidelines that shift, and it goes measurably better when it is somebody's full-time job.

The treadmill: what a platform absorbs

An app left alone degrades. Not because its code changes, but because everything around it moves. A sample of what "around it" has meant, with dates:

Every year: Google Play raises the required target API level. Miss the deadline and you cannot ship updates; fall further behind and the app is hidden from new users.
April to December 2020: Apple stopped accepting new apps, then updates, still using UIWebView. Every app embedding web content had to move to WKWebView.
March 2021: APNs dropped its legacy binary protocol. Push senders had to migrate to the HTTP/2-based API or stop delivering.
July 2022: Google Play's Data safety form became mandatory for every listing.
May 2024: Apple began enforcing privacy manifests and "required reason" API declarations, including for third-party SDKs.

Add the annual rhythm on top: new iOS and Android majors every fall, Xcode and Gradle toolchains that move, SDKs that deprecate.

On a platform, each of these is absorbed exactly once. The fix lands in the shared codebase, the apps are rebuilt, and the fleet rolls forward through regular app updates. That is also why we advise owners to update regularly even when nothing visible changed: the update is the vehicle that carries those fixes into production, and the stores themselves are hostile to dormant apps (Apple periodically sweeps apps that have not been updated in years; Google buries apps targeting outdated API levels). An app that ships updates stays current, visible and installable. Most of our owners experienced the events above as a release note, if they noticed at all.

The bill, itemized

Strip the platform away and here is what one production app makes you own, permanently:

one target API level raise per year, so at least one rebuild and resubmission per year;
OS beta season: test every summer, fix before every fall;
your dependencies' CVEs, deprecations and license changes;
push infrastructure: credentials, token hygiene, delivery monitoring;
store policy watch: new forms, new manifests, new review guidelines;
monitoring, and someone reachable when it breaks.

None of these is hard in isolation. All of them are permanent, and they compound.
What a no-code platform actually sells is not the editor; it is amortization.
Which editor you came through — drag & drop, prompt, or both —
changes nothing to that list. One team absorbs it once, and thousands of apps
inherit the result with their next update.

Our own receipts are public: an engineer is on call year-round, and the platform status page is at goodbarberstatus.com.

Questions in the comments. happy to go one layer deeper on any of this, from colocation choices to the push pipeline to review stories.

Privacy by design at the binary level: no ghost SDK in your build

Pierre- Laurent Medori — Fri, 17 Jul 2026 07:15:20 +0000

Most apps ship with passengers nobody invited: trackers, analytics and ad SDKs baked into the binary by default. We took the problem the other way around: nothing ships unless the app's owner explicitly turned it on. Here's the engineering, down to the compilation flags.

Quick context: GoodBarber is a no-code app builder (running since 2011). Customers configure an app in a web back office and the platform compiles real native builds, Swift for iOS and Kotlin for Android, plus a PWA. The people who own these apps will never open Xcode. Which makes the question sharper: who decides what code ends up in their binary?

The ghost SDK problem

A ghost SDK is any library that lives in an app's binary without the app's maker having chosen it. The pattern is everywhere, no-code or not:

Template runtimes. Many app factories compile every app from the same master project. Every feature the platform supports, and every SDK behind it, ships in every binary, used or not.
Transitive passengers. An SDK pulls its own dependencies. You added a video player; you also got its analytics.
Default-on integrations. Analytics and crash reporting wired in "for your own good", opt-out at best.

Why it matters, concretely:

Data can move without anyone deciding it. An embedded SDK is code that runs with your users, and some of it phones home whether or not the feature is used.
Attack surface. Every library is code you now answer for, including its CVEs.
Weight. Dead SDKs are dead bytes on every install.
You can't answer the stores honestly. Apple's privacy manifests and Google Play's Data safety form ask what your app collects. If you don't know what's inside your binary, you're guessing on a compliance document.

The industry default is opt-out. We think a binary should be opt-in.

A library ships only if the feature is on

We call the model on-demand embedded code, and the principle fits in one sentence: a library is embedded in the binary only if the corresponding feature is activated in the app.

How it actually works:

Every app has a feature graph. Sections, extensions, monetization, push, integrations: the back office knows exactly what an app uses.
The graph drives conditional compilation. At build time, the feature graph toggles compilation flags (pragmas) that include or exclude whole modules and third-party SDKs from the project. Off doesn't mean disabled or dormant. It means the code is not compiled in at all.
The Privacy Center is the control tower. One place where the app's owner sees what runs in their app and decides what is allowed to.
Builds happen on demand. We don't recompile on every toggle. A binary is generated when it's needed, typically when an update is about to be submitted to the stores, with exactly what the app's current configuration requires. For the owner this is transparent: they configure, we tailor the build.

On iOS, for example: AdMob is in the binary only if ads are enabled. The Facebook SDK, only if that integration is on. Even the in-app purchase stack (our StoreKit integration) stays out of the build unless in-app purchases are part of the app.

The consequence is easy to state and rare in practice: the app doesn't just declare less, it contains less.

And it's measurable. An Apps for Kids build, which by construction embeds none of these third-party SDKs, weighs about a third of a full-featured build (from our build data, July 2026).

The data question: hosted by us, in Europe

A clean binary is half the story. The other half is where the data lives.

GoodBarber is its own hosting provider. Customer and end-user data is hosted exclusively on our servers in Europe, and it does not leave the EU. No hyperscaler region to audit, no transfer mechanism to squint at: sovereignty here is one company, one jurisdiction. That baseline is what makes GDPR (and Germany's stricter BDSG) tractable for the small teams who build on the platform.

Consent gets the same treatment. For apps that do turn on ads or analytics, the platform ships an integrated CMP supporting the IAB Transparency & Consent Framework v2, plus Google Funding Choices for ad-monetized apps. So what is in the binary is disclosed, and consented to, per user and per purpose.

What this changes at store review

Apple's privacy manifests and Play's Data safety form stop being archaeology. Our privacy declarations are fed by the same source of truth as the build itself: the feature graph. What we declare is what we compiled, because both derive from the same place. There is no "wait, what does that SDK actually collect?" moment, because an SDK nobody chose is not in the build to begin with.

The extreme case proves the model: Apps for Kids. One declaration in the back office marks an app as a kids' title (Apple Kids Category, Google Play Designed for Families), and the platform disables every feature incompatible with those programs: third-party analytics, behavioral ads, intrusive permissions. The build that comes out is compliant by construction, because compliance is enforced where it's real: in what gets compiled.

Now the honest limits, because a claim like "nothing you didn't invite" deserves its footnotes:

The iOS push stack is always there. Our pipeline has never been wired to produce an iOS binary without push. Nobody ever needed that build, so that path doesn't exist. If you never use push, its code is still in your binary.
"Clean" means no uninvited third parties, not zero code. GoodBarber's own runtime is in every build. The difference: we own it, we answer for it, and it is one vendor you already chose.
We don't make your app compliant by magic. What owners collect through their own content (forms, orders, accounts) is their responsibility. We ship a clean binary, honest declarations and the consent tooling; the rest is theirs.

The takeaway

If you build a platform that compiles other people's apps, the transferable pattern is this: derive everything from one feature graph. Binary contents, privacy declarations, consent configuration, all from the same source of truth. The moment two of those are maintained by hand, they drift, and drift in privacy is how ghost SDKs are born.

More on the platform's privacy stance: goodbarber.com/privacy-compliance.

Questions in the comments. I'll answer with build-level details where I can.

Building a production MCP server: How we made GoodBarber agent-ready (without the glue code)

Pierre- Laurent Medori — Wed, 15 Jul 2026 12:10:40 +0000

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?

We already had APIs. That wasn't the point.

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:

Discovery. The client asks the server what tools exist; no hardcoded catalog on the agent side.
Typing. Every tool ships a JSON Schema; the model knows what arguments are legal before it calls.
Auth. OAuth is part of the protocol conversation, not a bespoke setup doc.

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.

The architecture

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: 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:

Forced read-back on writes. Every write returns _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.
Feature gating. An app that doesn't have push configured doesn't expose push tools at all. Agents can't call what isn't there.

The open-source layer: 44 Claude Skills. On top of the server we publish 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.

A real session: an agent managing an e-commerce catalog

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.

What doesn't work (yet)

The honest list, because this is the part most write-ups skip:

No design tools, on purpose. The server covers operations: content, catalog, campaigns, orders, stats. Layout and design stay in the builder. We don't believe pushing visual design through text-shaped tools produces good apps.
Per-app tool subsets surprise agents. Feature gating means two apps expose different tool lists. Correct behavior, but an agent following a generic recipe can look for a tool that isn't there. The Skills handle this; raw prompting sometimes doesn't.
Writes are chatty by design. Forced read-back costs tokens and latency on every mutation. We accept the trade: verified writes beat fast fiction.

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, 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.

Try it

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 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.