DEV Community: Maximilian Nussbaumer

Transport, Surface, Skin: Building MCP Plugins That Survive the Spec

Maximilian Nussbaumer — Sat, 25 Jul 2026 12:57:57 +0000

Updated 1 August 2026. The 2026-07-28 revision has landed, the TypeScript SDK v2 is GA, and @maxhealth.tech/mcp-http 0.3.0 has moved onto it. Corrections are called out where they apply.

Software engineering is dead. That is what they say.

Partially true. If a model can write the function, fewer humans will sit down and type it out. But losing the typing is a long way from losing the engineering. What actually happened is that the interesting question moved up a level. It used to be how do I build this application. Now it is how do a human, an application, and a model share one workspace.

That question is why the Model Context Protocol went from a curiosity to infrastructure so fast. Everyone hears MCP as the model quietly calling your API in the background. What it actually means is the model, the user, and your app all operating on the same live surface, at the same time.

So: how do you actually build one of these things?

The protocol is a moving target, and that is the point

Anyone who shipped an MCP server in 2025 has rewritten it at least twice. The transport story alone went stdio, then SSE, then Streamable HTTP. Streamable HTTP won and is now the dominant way to build.

And on 28 July 2026 the next revision landed. It is the biggest one yet, because it makes MCP stateless.

The initialize / initialized handshake is gone (SEP-2575). Protocol version, client info and capabilities now ride in _meta on every request, under keys like io.modelcontextprotocol/protocolVersion. Protocol-level sessions are gone too (SEP-2567), which means no more Mcp-Session-Id and any request can hit any instance.

The standalone GET stream endpoint is removed. Long lived streams did not disappear, they moved: change notifications now arrive on the response stream of a subscriptions/listen POST, which stays open and carries only the notification types you opted into. What did die is resumability, because Last-Event-ID and SSE event ids are gone outright. A broken stream now means re-issuing the request with a fresh id.

Servers no longer send requests to clients at all. This is the deepest change. Sampling, elicitation and roots used to be the server asking the client a question mid-flight. They are now embedded in an InputRequiredResult, which the client answers by retrying the original call with matching inputResponses (SEP-2322, "multi round trip requests"). The spec is blunt about it: a server "MUST NOT send independent JSON-RPC requests" on a response stream, and clients "MUST NOT send JSON-RPC responses" at all. Every exchange is now client-initiated, which is what makes the whole thing safe to load balance.

A few smaller things travel with it. Two routing headers become required (SEP-2243): Mcp-Method on every request, and Mcp-Name on tools/call, resources/read and prompts/get only, so intermediaries can route and rate limit on the operation without parsing a body. Mind the casing asymmetry when you write those down, because MCP-Protocol-Version is all caps and has existed since 2025-06-18, while the new pair is Mcp-. Cancellation on Streamable HTTP is now simply closing the response stream. Every result carries a required resultType field. And list and read results gain required ttlMs and cacheScope fields via a new CacheableResult interface (SEP-2549), where omitting them gets you the conservative { ttlMs: 0, cacheScope: 'private' } fallback and clients that re-fetch constantly.

There is a second half to this revision that the first draft of this article skipped, and it lands squarely on the layer I claimed was solved. OAuth Dynamic Client Registration is deprecated in favour of Client ID Metadata Documents. RFC 7591 still works against authorization servers that have nothing else, but new implementations should not reach for it. Alongside that, authorization servers SHOULD send the iss parameter on authorization responses (RFC 9207) and clients MUST validate it before redeeming the code, clients must send an appropriate application_type during DCR, and persisted credentials must be keyed by issuer so they are never replayed against a different authorization server.

Finally, Roots, Sampling and Logging are deprecated on a twelve month clock under a new feature lifecycle policy, and ping, logging/setLevel and notifications/roots/list_changed are removed outright.

Read that list again and notice what it adds up to. Your MCP server stops being a stateful daemon you have to keep alive and turn into sticky sessions. It becomes a pure function:

(Request, Token) -> Response

Which is exactly the shape of a Cloudflare Worker, a Deno Deploy handler, a Pages Function, or a Bun.serve fetch. Round robin load balancing, zero shared state, no session store to leak memory.

That is a much simpler thing to build. It also means the engineering is no longer in the plumbing. It is in the contracts.

Three layers, three contracts

Once the server is a pure function, a well built MCP plugin decomposes cleanly into three concerns that have nothing to do with each other:

Layer	Concern	Package
Transport	HTTP, OAuth, CORS, lifecycle	`@maxhealth.tech/mcp-http`
Surface	What the user sees and clicks	`@maxhealth.tech/prefab`
Skin	What it looks like, everywhere	`brandc`

Each one is a contract rather than a framework. You can throw any of the three away and keep the other two, and that is the claim the rest of this article has to earn. If you want the surface layer from someone else, @mcp-ui/client renders MCP Apps views in a React host and slots into the same place. If you want the skin from somewhere else, any stylesheet defining the same custom properties will do.

Layer 1: transport

@maxhealth.tech/mcp-http is a framework agnostic MCP HTTP layer built on the Web Fetch API. It runs on Workers, Pages Functions, Deno Deploy, Bun, Node 18+, and anything Hono deploys to. It has been stateless first from day one, which is why the July revision needed no redesign here. Additions, yes. Redesign, no.

Here is a complete authenticated MCP server on Cloudflare Workers:

import { createWorkerFetch, forwardBearer } from '@maxhealth.tech/mcp-http'
import { McpServer } from '@modelcontextprotocol/server'

export default {
  fetch: createWorkerFetch({
    authorizationServer: 'https://auth.example.com',
    createServer: (token) => {
      const server = new McpServer({ name: 'my-api', version: '1.0.0' })
      const fetchFn = forwardBearer(token)
      // register tools using fetchFn for upstream calls
      return server
    },
  }),
}

That import line is worth a paragraph on its own. The first version of this article said a peer range of >= 1.29.0 "wants a beta bump", which undersold it twice. v2 went GA on 27 July, and it is a package split rather than a version bump: the monolithic @modelcontextprotocol/sdk became @modelcontextprotocol/server and siblings. So migrating means adding a new peer dependency rather than widening a range. mcp-http 0.3.0 made that move, and because no export was removed, renamed or reshaped, and McpServer is API compatible across the two majors, for consumers it came down to one import path.

For those twenty lines you also get a working OAuth resource server. RFC 9728 protected resource metadata is served automatically, RFC 8414 authorization server metadata optionally, and unauthenticated calls get a proper 401 with a WWW-Authenticate header pointing at that metadata, which is how a compliant client discovers where to go and log in. Expired tokens are rejected on exp before any work happens, with a 30 second clock skew buffer. CORS is configurable, and an onRequest hook reports outcome, status and duration per call.

Two design decisions in there are worth stealing regardless of what you end up using.

createServer is a per request factory, and it receives the caller's raw token. That is the whole trick of stateless auth. The server instance lives exactly as long as the request that authorized it, so there is no shared instance for a token to leak through, and no window in which one user's credential is reachable from another user's call. It also means the implementation underneath is boring in the way you want security-adjacent code to be boring: construct a transport, connect the server, handle the request, throw it all away. There is no session id generator anywhere in the codebase, because there is nothing to correlate.

forwardBearer(token) is the seam for on-behalf-of calls. It returns a fetch that carries the caller's identity upstream, so your tools never handle a credential directly. They receive a function and call it. That sounds like a small ergonomic difference and it is actually the compliance story: in healthcare, every FHIR read has to be attributable to a specific human with specific scopes, and a tool that cannot see a token also cannot accidentally log one, widen one, or send one to the wrong host. The seam is the difference between a demo and something you can put in front of an auditor.

There is also a handleMcpPostStateful path, which keeps a transport alive across requests so the server can issue sampling calls. Be clear eyed about what that is now: it routes on Mcp-Session-Id and mints sessions on initialize, and both of those are gone in the new revision. As of 0.3.0 it is formally deprecated along with SessionStore and the stateful / sessionTtlMs options, scheduled for removal in 0.4.0. Design so you do not need it.

What the new revision actually cost a transport

Being honest about the gap is more useful than claiming there is none. Stateless was the right shape early and the shape held, so the forecast work was small: header and body mismatches now have to be rejected with 400 and JSON-RPC -32020 (HeaderMismatch), GET and DELETE on the MCP endpoint should answer 405 where they used to 404 so old clients can tell "wrong era" from "wrong URL", and the default CORS config had to stop exposing Mcp-Session-Id and Last-Event-ID, two headers that no longer exist.

Two things bit that were not on that list, and both are better lessons than anything that was.

The first was CORS, and it was invisible from the desktop. MCP-Protocol-Version has been required on every MCP HTTP request since 2025-06-18, and it is not on the CORS safelist. Leave it out of Access-Control-Allow-Headers and every browser-hosted MCP client fails preflight and never reaches your endpoint, while Claude Desktop works perfectly the entire time because it is not a browser and never sends a preflight. That class of bug is worth internalising: any MCP server tested in exactly one host is a server that works in exactly one host. Fixed in 0.2.0, along with deriving Access-Control-Allow-Methods per route (preflight was advertising GET and DELETE while the handler answered those with 405) and admitting the per-tool Mcp-Param-* headers that SEP-2243 introduces, whose names are chosen by the server per tool and so cannot be covered by a fixed list.

The second was RFC 9728 itself. §3.1 forms the metadata URL by inserting the well-known segment between the host and the resource path, so an endpoint mounted at /mcp publishes its metadata at /.well-known/oauth-protected-resource/mcp. We served only the bare path and pointed the WWW-Authenticate challenge there, which is off spec for any non-root mount point. It was found by diffing our behaviour against @modelcontextprotocol/server@2.0.0, which implements the rule correctly, and that is a technique worth stealing too: when a reference implementation exists, run it beside yours and compare bytes.

None of that touched anyone's tool logic. That part of the seam held.

Layer 2: surface

Now the interesting part. Your tool ran, you have data. What comes back?

The default answer is a wall of text for the model to summarize. That is fine for a lookup and terrible for anything a human should touch. If MCP is about using applications together with AI, then a tool result has to be able to be an application.

That is what @maxhealth.tech/prefab does. You build a component tree on the server and hand it to display():

import { display, Column, H1, autoTable } from '@maxhealth.tech/prefab'

async function listPatients() {
  const patients = await db.query('SELECT * FROM patients')
  return display(Column([H1('Patients'), autoTable(patients)]), { title: 'Patients' })
}

display() does two things at once, and the second is the one people miss. It serializes the tree to the $prefab wire format and puts that JSON in structuredContent, which is what the host renders. It also puts a text form in content[], which is what the model reads. Those are different audiences with different needs, and a tool result has to satisfy both: hosts without UI support, and the model itself, still need something meaningful when the interface never paints.

The rendering side is deliberately unglamorous. A zero dependency vanilla DOM renderer, loaded as a single script tag inside a ui:// resource, paints the tree in the host's sandboxed iframe. No bundler, no framework, no client build step in your project at all. What you get for that is 115+ components, reactive template expressions, and auto renderers (autoTable, autoChart, autoForm, autoMetrics) that turn raw rows into a real interface in one call.

The mechanism underneath is MCP Apps, and its status is worth being precise about. MCP Apps is not part of the core specification. It is an official extension, identified as io.modelcontextprotocol/ui, living in its own repository (modelcontextprotocol/ext-apps) and versioning independently. It landed with protocol version 2026-01-26, which is still current even though core has moved on to 2026-07-28.

Two corrections to the first draft here:

I wrote that MCP Apps is "one of two official extensions". There are four: OAuth Client Credentials and Enterprise-Managed Authorization under ext-auth, MCP Apps, and MCP Tasks. Tasks is the interesting one, because the 2026-07-28 revision is precisely what promoted it. Tasks used to be experimental inside core, and SEP-2663 moved them out into io.modelcontextprotocol/tasks with a redesigned polling API.

I also wrote that "the 2026-07-28 core revision does not mention Apps at all", but the revision's index page lists MCP Apps under Extensions, beside Tasks and Skills over MCP. What the revision added is the extensions capability field that makes the separation official and negotiable.

Wiring a tool to a UI takes two things: a registered viewer resource, and a pointer to it on the tool.

import { registerViewerResource, PREFAB_RESOURCE_URI } from '@maxhealth.tech/prefab/mcp'

registerViewerResource(server)

server.registerTool(
  'browse',
  { title: 'Browse', inputSchema: schema, _meta: { ui: { resourceUri: PREFAB_RESOURCE_URI } } },
  async (args) => ({
    content: [{ type: 'text', text: JSON.stringify(data) }],
    structuredContent: data,
  }),
)

Reach for registerTool here rather than tool(). Every tool() overload is deprecated in favour of it, and only registerTool's config object accepts inputSchema and _meta. Note also where _meta.ui.resourceUri sits: on the tool definition, so it appears in tools/list and the host can fetch and warm the template before the tool is ever called. Putting it on the result is the intuitive mistake, and it costs you that prefetch.

That one-line helper exists because of three failures that each cost an afternoon.

The MIME type is exactly text/html;profile=mcp-app, with no space after the semicolon. Plain text/html is silently treated as an ordinary resource and never loads in an iframe. There is no error, the UI simply never appears.

CSP has to go on both the resource listing and the content item. The spec has hosts check both, preferring the content item and falling back to the listing. So the content item wins wherever both are set, which sounds like the listing is redundant, right up until you meet a host that only reads the content item and a policy declared solely on the listing is dropped. You get a black iframe and no explanation. Setting both is always safe.

structuredContent is required. Return only content[] and the host prints raw JSON, because the UI path never fires at all.

As of prefab 0.3.6 that same call also declares the io.modelcontextprotocol/ui capability on the server and emits the ttlMs and cacheScope the new revision expects. Which brings me to the part of my own argument that did not survive contact.

Where the seam did not hold

The original version of this article closed the transport section with "none of that touches your tools. That is the point of the seam." That was too strong, and the two exceptions are more interesting than the rule.

ttlMs and cacheScope live on results, so they reached the surface layer directly. prefab's viewer HTML is a pure function of the package version, because the CDN base pins it, which means it is safely shared-cacheable and can ship { ttlMs: 86_400_000, cacheScope: 'public' }. Without that it inherits the conservative fallback and hosts re-fetch the viewer on every single render. That is a result-shaped change in a layer I had claimed the transport insulated.

resultType looked like exactly the same problem and turned out not to be one. It is a wire level key: the SDK stamps it at its encode seam and strips it before results reach consumers, which is why its public result types omit it entirely. I was ready to add it by hand in five places, and doing so would have been wrong. The honest version of my original line is "none of that touches your tool logic", which is weaker and true. The seam protects the handler body. It does not protect the envelope.

The pattern that makes all of this compose is that every handler returns a self contained UI. A list view carries a button whose click calls a detail tool. The detail view carries one that opens an edit form. Submitting calls a save tool. Multi screen flows fall out of independent handlers with no client side router and no shared state, which is exactly what a stateless protocol wants. And when only the numbers change rather than the layout, display_update() sends a state patch that the renderer merges into the live store instead of rebuilding the tree.

Layer 3: skin

Two layers in, there is a quiet duplication problem waiting. Your marketing site has a palette. Your web app has the same palette again in Tailwind config. Now your MCP UI needs it a third time as prefab wire JSON. Three copies of one brand in three vocabularies is three chances to drift, and they will drift silently, because nothing fails when they disagree.

brandc is a brand compiler that solves this by separating two axes. The contract is the names of the variables (--primary, --card, --radius, --success, --font-sans), stable across every brand and every stack. A brand is the values, with each colour authored once as a { light, dark } pair in structured TypeScript. Every delivery format is generated from that single source, so they cannot disagree: a plain CSS custom property stylesheet for SSR string injection, a theme.css for bundlers, a Tailwind v4 @theme inline preset that maps by reference so runtime dark switching keeps working, and a prefab wire theme.

import { toPrefabTheme, maxhealth } from 'brandc'
import { display } from '@maxhealth.tech/prefab'

return display(view, { theme: toPrefabTheme(maxhealth) })

Look at what makes that line work. toPrefabTheme(brand) returns { light, dark } string maps. Prefab's Theme interface accepts { light?, dark? } string maps. The two packages have no knowledge of each other, no shared dependency and no coordination, and they compose exactly, because both agreed on a shape instead of on an implementation. That is the whole thesis of this article in one function call.

Rebranding is then a matter of supplying different values against the same contract, which is a data change rather than a code change. One gotcha if you do this in a Tailwind v4 app and want to rebrand colours only: pass an empty scalars, because the contract's --radius* and --shadow* names collide with the keys Tailwind uses in @theme, and emitting them overrides Tailwind's own scale.

One more finding since publication, for anyone building their own token layer. brandc 0.6.0 stopped @property-registering the scheme-dependent tokens. Registering a custom property forces its value to resolve at computed value time, which means a light-dark() token declared on :root decides the colour scheme there, for the entire document, and a .dark further down the tree silently does nothing to it. Native controls in that subtree still flip, so you get a light panel containing a dark input and no obvious cause. Leaving the scheme-dependent half unregistered is what lets a subtree theme itself.

The whole plugin

Stacked up, an authenticated, branded, interactive MCP plugin is about thirty lines:

import { createWorkerFetch, forwardBearer } from '@maxhealth.tech/mcp-http'
import { display, autoTable, Column, H1 } from '@maxhealth.tech/prefab'
import { registerViewerResource, PREFAB_RESOURCE_URI } from '@maxhealth.tech/prefab/mcp'
import { McpServer } from '@modelcontextprotocol/server'
import { toPrefabTheme, maxhealth } from 'brandc'

const theme = toPrefabTheme(maxhealth)

export default {
  fetch: createWorkerFetch({
    authorizationServer: 'https://auth.example.com',
    createServer: (token) => {
      const server = new McpServer({ name: 'patients', version: '1.0.0' })
      const fetchFn = forwardBearer(token)

      registerViewerResource(server)

      server.registerTool(
        'list_patients',
        { title: 'List Patients', _meta: { ui: { resourceUri: PREFAB_RESOURCE_URI } } },
        async () => {
          const rows = await fetchFn('https://fhir.example.com/Patient').then(r => r.json())
          return display(Column([H1('Patients'), autoTable(rows)]), { title: 'Patients', theme })
        },
      )

      return server
    },
  }),
}

No session store. No sticky routing. No handshake to keep alive. Nothing in memory between requests. It scales behind a round robin balancer because there is nothing to scale, and it was already the shape the July 2026 revision asks for before that revision was written.

The question that follows every demo

authorizationServer: 'https://auth.example.com' quietly hides the thing people ask about thirty seconds after seeing this run. What does that server actually have to be?

Four things. Your server needs RFC 9728 protected resource metadata, so a client can discover which authorization server guards you. That server needs RFC 8414 metadata at /.well-known/oauth-authorization-server, so its endpoints and grants are discoverable rather than configured by hand. It needs a client onboarding story, meaning Client ID Metadata Documents now or DCR while it lasts, because without one every consumer has to be hand-registered by you. And it needs scopes that can express something in your domain, since those scopes are the boundary of what you are actually selling.

All four are checkable in one command:

curl -s $ISSUER/.well-known/oauth-authorization-server \
  | jq '{registration_endpoint, grant_types_supported, scopes_supported}'

A 404 on that URL is itself the answer. Plenty of perfectly good OIDC identity providers serve only /.well-known/openid-configuration, expose no registration_endpoint, and grant authorization_code alone. That signs users in and does it well. Authorizing a plugin is a different job, and pointing discoverAuthorizationServer at one gets you a 404 rather than a useful error.

So is software engineering dead?

The typing is dying. Good.

What is left is the part that was always the actual job: deciding where the seams go. createServer taking a token instead of closing over one. display() returning an envelope where a string would have done. toPrefabTheme() returning a shape another package happens to accept. None of those are hard to write, and a model will write any of them for you in seconds. Knowing that they are the three cuts that let a plugin survive a protocol rewrite is the work.

It is worth saying plainly what updating this article demonstrated, because it is a more useful result than the original claim. Of the three seams, the transport one held completely: a package rename, a CORS header, a well-known path. The surface seam leaked, because ttlMs and cacheScope are result-shaped and results are the thing the surface layer builds. Contracts do not make you immune to a spec revision. They make the blast radius small enough to fix in an afternoon, and they mean you hear about it from a changelog instead of from your error rate.

The protocol will change again on some Tuesday. Build against contracts and that will be a Tuesday you can plan for.

Sources

DRY: Don't Repeat Yourself

Maximilian Nussbaumer — Wed, 17 Jun 2026 19:07:51 +0000

When we wrote code before large language models could write it for us, code duplication was rarely our problem, at least not if we worked alone or in a small team.

That has changed.

A principle born in a quieter time

"Don't Repeat Yourself" was coined by Andy Hunt and Dave Thomas in The Pragmatic Programmer back in 1999, a year when our biggest worry was whether the clocks would survive January. The idea is reassuringly simple. Every piece of knowledge in your system should have a single, unambiguous home. Write it once, point at it from everywhere else, go to lunch.

For those of us working alone or in small teams, DRY was almost automatic. You held the whole codebase in your head, all of it, including the parts you were ashamed of. When you needed to format a date, you remembered you already had a formatDate helper, because you had written it last Tuesday and were still slightly proud of it. Duplication was something that happened to other people, specifically large organizations where three teams could write three subtly different currency formatters and never once meet in a corridor.

Duplication, in other words, was a problem that scaled with headcount. The more humans you added, the more copies of everything you got.

Now everyone gets to have the problem

Here is the shift. An LLM writing code for you behaves rather like a brand new contractor who has never seen your project, is enormously eager to help, and has politely forgotten everything the moment they finish each task.

It does not know that formatDate already exists. It does not know your team solemnly agreed that all network calls go through apiClient. It does not know that the precise validation logic it is about to invent is sitting, fully tested, three folders away. So it does the friendly thing and writes some fresh code that works.

And it does work. The tests pass, the feature ships, the little green checkmark appears, everyone is delighted. You simply now own a fourth date formatter, a second and mildly incompatible API wrapper, and a button component that matches your design system the way a cover band matches the original.

The duplication problem used to scale with the number of people. It now scales with the number of generations. A single developer with an AI assistant can produce, before lunch, the sort of sprawl that once required an entire floor of the building.

Why models duplicate without meaning to

It helps to understand why this happens, mostly because it points directly at the fix. There are really three reasons, and none of them involve the model being foolish.

The first is context. The model only sees what you hand it, and your 200-file project does not fit through the letterbox. It cannot reuse a helper it has never been allowed to look at. The second is incentive. Generating new code is the thing models are good at and rewarded for, whereas reusing old code first requires finding the old code, an activity most setups make about as convenient as it sounds. The third is more human than you would expect. A self-contained block that compiles simply feels finished, and nothing about "finished" nudges anyone, silicon or otherwise, to go hunting for the canonical version that already exists.

Notice that all three are about memory, not intelligence. The model is not failing to reason. It is reasoning brilliantly about the tiny slice of the world you managed to fit in front of it.

What it quietly costs you

Duplication is not merely untidy. It is where bugs go to retire comfortably.

// payments/checkout.ts
function formatPrice(cents: number) {
  return `$${(cents / 100).toFixed(2)}`;
}

// invoices/render.ts, written by an agent two weeks later
function priceToString(amount: number) {
  return `$${(amount / 100).toFixed(2)}`; // same idea, fresh coat of paint
}

These two look harmless, almost charming. Then you launch in Europe, need euros and comma decimals, and confidently patch formatPrice. The invoices keep cheerfully printing dollars, because nobody alive remembers that priceToString exists. You have just shipped a production bug whose root cause is a duplication that no human ever actually decided to create.

Now run that forward across a year of helpful AI commits. The bill arrives as inconsistent behavior, as maintenance that has to be performed several times in several places by someone who can find all of them, and as the slow erosion of your belief that the codebase has one correct way to do anything. It stops having one, so the belief was right to leave.

What to actually do about it

You do not fix this by asking everyone to be more careful, which is the programming equivalent of asking the weather to be nicer. You fix it by giving whatever writes the code a way to know what already exists.

That is the entire reason I built DRY.codes.

DRY.codes indexes the repositories you connect, across your personal account and your organizations, and builds two things from them. The first is a fast, searchable memory of every file you have already written. The second is a precomputed map of where your code already repeats itself, file pairs ranked by how much they actually share. It then exposes all of it over the Model Context Protocol, which is the part that matters, because MCP is the letterbox through which your AI assistant finally gets to see the rest of the house.

So the contractor who forgets everything gets a memory. Before writing a new helper, an agent can search the knowledge base for one that already does the job. It can locate a file by name, compare two files to decide whether a near-duplicate is worth consolidating, and run a snippet through dry_wand to ask, in effect, "have we written this already?" The answer arrives before the duplicate does, which is the only time the answer is useful.

You can point it at a single repository or an entire organization to see the worst duplication hotspots and decide what to refactor first. You can keep shared configuration and utilities honest across dozens of projects at once. And if you live in Claude Code, the plugin wires this straight into your workflow with a "reuse before you write" reflex, so the search happens by default rather than by virtue. There is even a public corpus at dry.codes/mcp/public if you want to feel the idea before connecting anything of your own.

The point is not to scold the model. The point is to hand it the one thing it was missing.

The cheerful twist

DRY did not become less important when machines learned to write code. It became more important, and it became democratic. The duplication problem that used to belong exclusively to large organizations now belongs to anyone with an AI assistant and an afternoon.

The happy part is that the same tools generating all this duplication are perfectly capable of avoiding it, the moment you give them some memory of the code that is already sitting right there.

Write it once. Then make sure everything, human and machine alike, can actually find it. That last sentence used to be advice. With DRY.codes, it is just how the tooling works.

Follow quotentiroler on GitHub

Why MCP Apps are going to be the next big thing

Maximilian Nussbaumer — Mon, 04 May 2026 22:48:11 +0000

There's a quiet shift happening in how AI tools interact with users, and most developers haven't noticed yet, because just one week after the MCP Apps specs were published by Anthropic, OpenAI launched a huge marketing campaign around OpenClaw and they got all the attention, at least for a while.

For the past two years, every AI assistant has been stuck behind the same interface: a text box. You ask a question, you get text back. Maybe some markdown. Maybe a code block. Maybe an image.

Claude, GPT, Copilot, Gemini, every local model render into the same narrow pipe. MCP Apps change that.

What MCP Apps actually is

MCP Apps is a protocol extension that lets MCP tool results include interactive UIs. Actual interactive components running inside the AI host's sandbox.

The mechanics are straightforward:

Your MCP tool returns a structuredContent payload alongside the normal text content
The host loads a ui:// resource (an HTML page you provide) into a sandboxed iframe
The host forwards the tool result to your iframe via postMessage using a JSON-RPC 2.0 protocol (ui/* methods)
Your renderer mounts the UI inside the iframe
The UI can call tools back, send messages to the conversation, request display mode changes, and resize itself

The text content still serves LLM reasoning and hosts without rendering support. The UI is a progressive enhancement. Let's be honest: natural language is not always the most convenient or fastest way to express a desire. A click or a tap on a button can be much faster.

The spec behind it

The MCP Apps protocol (spec version 2026-01-26) is an official extension to MCP maintained by Anthropic. It defines a JSON-RPC 2.0 message layer over postMessage between a sandboxed iframe and its host. The spec covers:

Handshake: ui/initialize request/response with protocol version negotiation, app capabilities, and host capabilities
Lifecycle: tool-input, tool-result, tool-cancelled, tool-input-partial (streaming), host-context-changed, resource-teardown
Actions: ui/open-link, ui/message, ui/request-display-mode, ui/update-model-context, tools/call
Sizing: ui/notifications/size-changed (reactive, from app to host), ui/notifications/preferred-size (declarative hints)
Security: CSP via _meta.ui.csp on resource content items, Permission Policy for camera/microphone/geolocation/clipboard

The spec is deliberately renderer-agnostic. It defines how the host and the iframe talk to each other. What you put inside the iframe is entirely your choice. The host doesn't parse your component tree or validate your DOM structure. It sends you JSON-RPC messages and expects JSON-RPC messages back.

This is a deliberate design decision and the reason multiple rendering approaches can coexist. The Anthropic ext-apps SDK, a prefab renderer, a raw React app, a Svelte component -- all valid. The protocol doesn't care.

Current host implementations:

Host	Status	Notes
VS Code Copilot Chat	Shipping	Full spec support, CSP via `<meta>` tag, `acquireVsCodeApi()` transport
Claude Desktop	Shipping	Full spec support, CSP via HTTP headers on sandboxed origin (`{hash}.claudemcpcontent.com`). Can send results before init completes
ChatGPT	Shipping	Full spec support, CSP via HTTP headers on sandboxed origin (`{slug}.oaiusercontent.com`)

Three independent hosts shipping the same protocol make apparent that this is not a proposal, but infrastructure.

Why this matters

Here's the thing I think people are going to underestimate: this turns every MCP server into a full-stack application.

An MCP server is already a backend that exposes typed tools over stdio or HTTP. It already has access to databases, APIs, file systems. The only thing missing was a frontend.

Now it has on that lives inside the AI conversation, gets tool arguments and results pushed to it automatically, can call tools back on its own MCP server via the host, inherits the host's theme for free, and works across VS Code, Claude Desktop, ChatGPT, and anything else that implements the spec.

That last point is the critical one. Write once, render everywhere. The protocol is the same across hosts. The sandboxing model is the same. The postMessage bridge is the same.

Two different things driven by the same idea

MCP Apps is going to do to AI tooling what PWAs were supposed to do to mobile apps. PWAs were competing against native apps that users already loved. MCP Apps are filling a vacuum. There is no existing standard for rendering interactive UIs inside AI conversations. The alternative is pasting JSON into the chat. MCP Apps are going to be "AI Native Apps".

The bar is low. And the protocol is good enough.

What it looks like in practice

Here's a complete MCP tool that returns an interactive patient list with search, sorting, and click-to-view detail:

import { display, autoTable, Column, H1 } from '@maxhealth.tech/prefab'

async function listPatients(args) {
  const patients = await db.query('SELECT * FROM patients')
  return display(
    Column({ gap: 6 }, [
      H1('Patients'),
      autoTable(patients),
    ]),
    { title: 'Patient List' }
  )
}

display() wraps the component tree into the MCP wire format. The host renders it. The table is interactive -- search, sort, row selection -- without writing any frontend code.

But you don't even need to compose components. The auto-renderers infer the right UI from your data shape:

import { display } from '@maxhealth.tech/prefab/mcp'
import { autoTable, autoChart, autoForm, autoMetrics, autoDetail } from '@maxhealth.tech/prefab'

// Array of objects -> searchable, sortable table
return display(autoTable(patients))

// Array with numeric fields -> line/bar chart with axes and tooltips
return display(autoChart(salesData, { xAxis: 'month', title: 'Revenue' }))

// Schema fields -> validated form that submits back to an MCP tool
return display(autoForm([
  { name: 'name', label: 'Name', required: true },
  { name: 'email', label: 'Email', type: 'email' },
  { name: 'role', label: 'Role', type: 'select', options: ['admin', 'user'] },
], 'save_user'))

// Key-value object -> formatted detail card
return display(autoDetail({ name: 'Alice', status: 'active', lastSeen: '2026-04-30' }))

// Object with numeric values -> metric cards with labels
return display(autoMetrics({ patients: 1284, appointments: 47, waitTime: '12min' }))

Each auto-renderer picks columns, axes, labels, and formatting based on what it finds in the data. You pass an array or object, you get a production-quality UI back. When you outgrow them, you drop down to the component API and build exactly what you want.

And when you want to tweak the look without writing full custom components, every element accepts utility classes:

import { display, Column, H1, Badge, autoTable } from '@maxhealth.tech/prefab'

return display(
  Column({ gap: 6, cssClass: 'p-6 max-w-4xl' }, [
    H1('Patient Dashboard'),
    Badge({ label: '47 active', variant: 'success', cssClass: 'text-sm' }),
    autoTable(patients, { cssClass: 'rounded-lg shadow-md' }),
  ]),
  { title: 'Dashboard', layout: { preferredHeight: 600 } }
)

The built-in CSS ships ~200 Tailwind-compatible utility classes (padding, margin, flex, grid, gap, typography, colors, borders, shadows, max-height, overflow). No Tailwind dependency, no build step, no purge config. They're there in the 15KB stylesheet that the CDN serves alongside the renderer.

Three levels of control: auto-renderers for zero-config, utility classes for visual tweaks, full component API for complete custom UIs.

The HTML renderer is only 80kB in size and imported by a single script tag:

<div id="root"></div>
<script src="https://cdn.jsdelivr.net/npm/@maxhealth.tech/prefab@0.2/dist/renderer.auto.min.js"></script>

The protocol is the product

The real value is the protocol itself.

ui/initialize handshake. ui/notifications/tool-result for pushing data. ui/notifications/size-changed for responsive layout. ui/open-link for navigation. ui/message for sending messages back into the conversation. All JSON-RPC 2.0 over postMessage.

Anyone can build a renderer against this protocol. React, Svelte, vanilla JS, raw DOM manipulation. The host sends JSON-RPC messages to an iframe and expects JSON-RPC messages back. Your rendering stack is your business.

This is why I think MCP Apps will win where similar attempts failed. It's a host protocol that allows any rendering approach, and that makes adoption straightforward on both sides.

What's missing

It's early. The spec is dated 2026-01-26. Here's what's still rough:

CSP implementation varies by host. All hosts read _meta.ui.csp from the content item returned by readResource, but the enforcement mechanism differs. VS Code injects a <meta> tag. Claude Desktop and ChatGPT enforce via HTTP headers on a sandboxed origin. The spec standardizes the declaration format, but you should test your CSP config against each host you target.
No standard component format. The protocol defines the transport, the payload is up to you. Every renderer invents its own component schema. (We use a $prefab JSON wire format, but nothing stops someone from using entirely different components.)
Permission Policy support varies. Camera, microphone, geolocation, clipboard-write access via iframe allow attribute. Hosts report what they support in hostCapabilities.sandbox.permissions, but not all hosts honor all permissions yet.
Buffering and timing are tricky. Claude Desktop can send tool-result before the ui/initialize response arrives. If your renderer doesn't buffer, you lose the first result. This took us several hours to debug.

These are solvable problems. The architecture is sound.

The prediction

Within 12 months, we will see a market emerging around MCP Apps.

MCP Apps hosts will compete on rendering quality, theme support, and permission handling. MCP servers will compete on UI polish. And the protocol will quietly become the standard that holds it all together. MCP Hosts potentially replace the need for an internet browser.

Follow Max Health on GitHub

BDFL: Benevolent Dictator for Lobster - or - How I met Sam Altman

Maximilian Nussbaumer — Mon, 16 Feb 2026 08:05:47 +0000

What happens if you vibecode an open-source personal assistant that gets hyped? OpenAI might offer you a job and launch their biggest and most viral marketing campaign ever. Let me explain.

When the creator of OpenClaw, Peter Steinberger, came to San Francisco, the party at Frontier Tower was huge. They ordered lobster rolls and crabs for everyone. I had no chance to talk to him, but I met him on the next day at the OpenAI Codex Hackathon, where he was sitting together with some attendees. What I saw then concerned me: Within a few minutes, he gave out maintenance access to some people he never met before (including me), telling us to bring down the PR count. No onboarding, no guidance, no staging. One task: Merge PRs into main. When someone asked him a question, he had no time or patience to answer. This immediately showed signs of a toxic working environment. Heads were hiding behind the screens, the fear of being cut out took over within no time.

It is probably meant to be a bad joke that in the contribution guideline, there is no proper guidance on how to contribute. Instead, it shows the project owner as the "benevolent dictator". That's the credits Peter Steinberger gave to himself on January 2nd. What a New Year's resolution.

The benevolent dictator is a well-known pattern when there is a huge hype around one individual, and the "best practice" way to handle that situation is to re-assign authority to a board of people. It is truly difficult but necessary to handle this well, in order to minimize harmful consequences. "The best-case outcome is a BDFL who recognizes when to transition to a broader governance model before the drawbacks cause real damage." BDFL works when the project is small enough or the (benevolent) dictator is skilled enough to maintain genuine oversight. Neither is the case.

I walked away from that table where Peter was sitting at and met many other people instead. I met Sam Altman, but this was most likely not a coincidence. That hackathon was just the kick-off of their marketing campaign. Codex 5.3 was released on that day, and they want it to be used. Anthropic dominates code generation, Google dominates image generation. They grasp at every straw, trying to stay above water. OpenClaw is the card OpenAI played, and they bet a lot on it. Peter consistently promotes Codex over competing tools and dismisses MCP, and on February 15th it became official: Peter joins OpenAI as an employee.

Nevertheless, I accepted the invite to become an (unpaid) maintainer of OpenClaw. The first thing I did: I asked for staging after I saw that every PR gets directly merged into the main codebase, which is like turning screws on an airplane that is about to take off. It's obvious why that is considered "bad practice".

But Peter had no time to think about it. A few days later, I was the top contributor, and people started reaching out to me via email, pinging me in their PRs, asking for reviews, offering jobs, even on X! Not because I implemented staging or shipped features. Because I removed garbage. "Your contributions to openclaw/openclaw caught my attention and I wanted to reach out."

The Problem

Over tens of thousands GitHub Actions minutes burned in a few days. Failed builds, redundant test runs, CI churn from missing gates. I found many files with thousands of lines of code, and hundreds of duplicate functions across the codebase. Both identical functions and slight variations of the same logic, written by AI agents that had zero awareness of what already existed. No human actually knows this codebase. It is being vibecoded with minimal human oversight.

How This Happens

It's a simple, cancerous loop:

AI agent gets a task
It writes code that "works", meaning it passes the immediate test and satisfies the prompt
Nobody checks whether the code duplicates existing functionality
Nobody notices the file went from 3,000 lines to 5,300
It gets merged
Repeat a thousand times

The LLM does not know that a nearly identical helper function already exists 1,000 lines above, or in the next module over, if it is not told to look for it. It solves the problem in front of it and moves on. Like a living cell that reproduces without control. When you put the human out of the loop, the codebase grows in volume, but decays in quality. The only critic is now satisfaction. "Did I get what I wanted?" If not, then the AI has to iterate further until I get what I wanted.

Security concerns are more than valid when people tend to value hype over a reality check. If you wonder how OpenClaw is being released: Once every few days, Peter takes whatever code is currently in the main branch, and creates a new release. Sometimes he writes "YOLO" in the maintainer chat while doing it.

Like the other day, when a maintainer bulk-merged a couple of PRs into main, Peter released it, cron jobs broke, and Elon Musk made fun of OpenClaw on X. Welcome to OpenClaw!

What I Did

The boring stuff nobody wants to do. I went through the codebase and identified duplicate and near-duplicate functions. Consolidated shared logic into reusable helpers. Broke apart files that had no business being thousands of lines long. Set up a quality gate so new submissions actually get reviewed for duplication and structural fit before they land on main. Enabled typechecking for modules. The codebase got smaller and more maintainable and CI stopped choking on broken builds.

The Response

When I asked for staging, I noticed why a toxic working environment should be avoided: People are scared to say the opposite of what the benevolent dictator will say then. Being rejected by the benevolent dictator will devalue the position of the proposer, so there is no proposal against the narrative, and the narrative is "we accept AI generated code of any kind".

When I put stricter quality gates in place, some people were not happy about it. Velocity matters more than quality. Ship fast, do not clean up. I see this pattern forming across the AI-assisted open source ecosystem. The pressure to merge PRs and ship features actively punishes the people doing real code maintenance work.

I also gave credits to the contributors based on their actual contributions. Another maintainer, who attacks people for pinging him on github or permabans them from contributing, reverted the change and gave me the choice to shut up or leave. I thought about it for a day, and decided to leave and share my experiences.

2 days later, the code quality gate I installed which prevented new duplicate functions from being introduced and code files from growing endlessly has already fallen. In commit/c2178.., it was removed for being "useless", when the gate has already saved thousands of CI minutes while preventing duplicate code from being merged.

Peter's take? Well, he did not respond at all, which is typical for a benevolent dictator. Our only conversation took about 2 minutes, when he gave me maintenance access. Still, on February 14th, he assigned an army of agents both locally and in the cloud to continue with the refactorings and deduplications I started.

The Numbers

Snapshot	Date	Files	Total LOC	Duplicate function names
Before CI gate removal	Feb 12	3,840	694,527	415
Before Peter's sweep	Feb 13 (end of day)	4,052	731,516	429
After sweep	Feb 14	4,166	741,598	419

So the duplicates went up from 415 → 429 between Feb 12-13 (new code was being added faster than dedup was happening), and Peter's sweep on Feb 14th brought it back down from 429 → 419, meaning new duplicates are being introduced while Peter is cleaning them up. He's swimming against the current, but his approach is not sustainable. It is just not possible to outsource all thinking to multi-agent systems. The consequence is digital cancer.

Instead of wasting more tokens and energy, Peter could just re-enable the simple but highly effective code quality gate and pay naturally intelligent humans to clean up. In fact, Peter's artificially intelligent agent swarm is still refactoring non-stop, and brought duplicate functions down to 378. That took him 637 commits, which is very inefficient.

The Bigger Question

I believe AI should be more accessible to everyone. That is the stated mission of projects like this. But accessibility without oversight produces exactly what I found: AI-made codebases that are not maintainable without AI. AI making humans depend on it. This might be the first step of AI taking over.

AI does not need a dictator and his loyal doormats. It needs real human oversight and people who speak up. This project is dangerous, not because of AI, but because hype is dangerous, benevolent dictators, and people in charge riding the hype train while hiding behind pseudonyms. All world plays along, branding events and articles with crabs and lobsters, just because it sells. I am scared of the consequences of this carelessness, and I cannot be part of it.

What makes this more urgent is that governments are now actively discussing the use of code that is one big chaos. Legislators and procurement officers are evaluating tools built on codebases where significant portions were generated by AI, reviewed by AI, and merged with minimal human scrutiny. That should demand a higher standard of transparency, not a lower one. Yet many of the people contributing to and shaping these projects operate under pseudonyms. When software influences public infrastructure, healthcare systems, or democratic processes, the public has a right to know whether anyone with real accountability is actually reading the code. Anonymity has its place in open source, but accountability cannot be optional when the stakes are this high.

What's Next?

Obvious human carlessness is the first step of losing control. If only AI knows how the code works that drives AI, AI is taking over, maybe in the form of a lobster, or a crab, or digital cancer. OpenClaw is not unique - everybody can vibecode their personal assistant now. Every digital idea can be copied and implemented within no time. The world is about to change drastically. Still, I am not losing hope, instead, I built RepoWatch.

This tool points out obvious code quality issues, lists contributors and uses various traditional algorithms to detect duplicate code across PRs. It is derived from an old uni project I made before AI was a thing, where I had to find potential plagiarism in 50 code submissions made by other students. Back then, I did some research and implemented my interpretation of document fingerprinting. I am sure that similar ideas will become more important in the future in order to prevent duplicate data from being processed. My tool aims to bring clearance and transparency so that not only AI can understand code, but also humans, as well as open standards and metrics to determine the uniqueness and consistency of a codebase.

This is Peter's description on X:

Let's shell that lobster and prevent digital cancer from taking over the world!