Two weeks ago I wrote that MCP is the AI backend for frontend. Fine. Then half my timeline started shouting about "MCP apps" and "connector scaffolding", and a few SDKs started calling themselves the Next.js of MCP.
Cute. Also mostly unhelpful until someone maps it onto a real TypeScript team.
An MCP app is a shippable connector with a project shape, not a vibe and a JSON schema.
The scaffolding question
Frontend shops do not invent frameworks for fun. We invent them so the tenth feature does not invent a tenth way to register a route.
MCP connector DX in spring 2026 is finally doing the same thing. Instead of a lonely server.ts and a prayer, you get a folder that looks suspiciously like something you already know:
Tool filename becomes the verb. Types come from Zod (or equivalent). Auth lives in one place. You run a local inspector, then you publish something another agent can install without reading your Slack history.
That is the DX. Not the protocol whitepaper. The shape.
Why frontend teams should care
Because we are the ones who get asked to "just hook Claude up to Jira".
Without scaffolding, that request becomes a weekend of stdio transport trivia, half-documented OAuth, and a tool that returns unstructured blobs the model summarises into fiction.
With scaffolding:
You are not becoming an "AI platform team". You are applying package discipline to a new runtime consumer.
Typed tools beat clever prompts
Here is the bit that matters for a TS shop. If your connector inputs are Zod-validated, the agent gets a contract it can fail against before it invents a field name.
That is not ceremony. That is the difference between "agent occasionally works" and "agent is boringly reliable".
Prompts still help for rituals. Resources still help for docs and schemas. But the connector's job is to expose safe, typed verbs, not to cosplay as a second chatbot.
App-store energy, without the nonsense
Some of the April framing really did sound like an app store for agents. Ignore the launch bingo. Steal the useful part: connectors should be installable, versioned, and reviewable.
Ask the same questions you ask of a Next.js package:
If the answer is no, you do not have an MCP app. You have a demo that escaped the lab.
Same shop, two interfaces
Post one was the architecture claim: one protocol over many APIs.
This post is the team claim: treat connectors like frontend packages. Scaffold them. Type them. Version them. Put them in the monorepo next to the UI that will eventually call them through an agent.
Your React app stays the human interface. Your MCP apps become the agent interface. Same organisation, same TypeScript, two consumers.
Thoughts
If MCP is the backend for agents, then connector scaffolding is just create-next-app energy applied where it was overdue.
&w=3840&q=75)


