JIMDRURY.
Jim Drury
Flat pink editorial illustration: a my-connector folder tree with src/tools files feeding a Zod-typed listIssues contract card, which sends a typed call to a stippled agent sphere.
ai

What 'MCP apps' actually mean for a TypeScript dev house

4 MIN READ

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 (which, awkward confession, is usually us when someone pings "can you just hook Claude up to Jira?").

Confession

I've said yes to that message too fast before. The weekend then belonged to stdio transport trivia and half-documented OAuth. Never again without a folder layout.

An MCP app is a shippable connector with a project layout and typed business intents, not a vibe and a JSON schema.

The scaffolding question

TypeScript dev houses dont invent frameworks for fun. We invent them so the tenth feature doesnt 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:

my-connector/
my-connector/
├── package.json
├── src/
│   ├── index.ts          # server entry
│   ├── tools/
│   │   ├── listIssues.ts
│   │   └── createIssue.ts
│   ├── resources/
│   │   └── projectSchema.ts
│   └── prompts/
│       └── triageBug.ts
├── .env.example
└── README.md

The Tool filename becomes the intent. The 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's the DX. Not the protocol whitepaper. The business intents.

Why frontend teams should care

Because we are the ones who get asked.

Without scaffolding, that Jira request becomes unstructured blobs the model summarises into fiction. With scaffolding you:

  1. Generate the connector package

  2. Define tools as typed functions

  3. Run against a local MCP inspector / Cursor / Claude Code

  4. Ship it where the rest of your TS artefacts already live

You are not becoming an "AI platform team". You are applying package discipline to a new runtime consumer. Slightly less glamorous. Much more true.

Typed tools beat clever prompts

If your connector inputs are Zod-validated, the agent gets a contract it can fail against before it invents a field name.

listIssues
import { z } from "zod";

export const listIssuesInput = z.object({
  projectKey: z.string().min(2),
  status: z.enum(["open", "in_progress", "done"]).optional(),
  limit: z.number().int().min(1).max(50).default(20),
});

export async function listIssues(input: z.infer<typeof listIssuesInput>) {
  const query = listIssuesInput.parse(input);
  return fetchIssues(query);
}

That isnt ceremony. That's the difference between "agent occasionally works" and "agent is boringly reliable".

Prompts still help for processes. Resources still help for docs. The connector's job is safe, typed business intents, not cosplaying 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.

Can a new hire run it locally in ten minutes? Are secrets in .env.example, not buried in Notion? Does a breaking tool change bump a version? Can you delete a dangerous tool without rewriting the whole server?

If the answer is no, you dont have an MCP app. You have a demo that escaped the lab. I've watched more than one of those escape. The hangover is real.

Same dev house, two interfaces

Treat connectors like the rest of your frontend packages: scaffold them, type them, version them, and park them in the monorepo next to the UI that will eventually call them through an agent. React stays for humans; the MCP apps are what the agent hits.

Thoughts

If MCP is the backend for agents, then connector scaffolding is just create-next-app energy applied where it was overdue.

Similar Articles