DEV Community: Renato Marinho

Vurb.ts: The MCP Framework with Zero Learning Curve

Renato Marinho — Tue, 17 Mar 2026 13:17:42 +0000

Why Frameworks Matter for AI Agents

Every framework ever built assumed one thing: a human is reading the output.

Rails, Laravel, Express, tRPC — beautiful frameworks. But they all have a blind spot: they were designed for browsers and humans, not for AI agents.

In 2025, MCP (Model Context Protocol) changed everything. Now AI agents are the consumers of our APIs. But here's the problem: every MCP framework still builds for humans.

When you build a raw MCP server, you typically do something like this:

server.setRequestHandler(CallToolRequestSchema, async (request) => {
  const { name, arguments: args } = request.params;
  if (name === 'get_invoice') {
    const invoice = await db.invoices.findUnique(args.id);
    return {
      content: [{ type: 'text', text: JSON.stringify(invoice) }]
    };
    // AI receives: { password_hash, internal_margin, customer_ssn, ... }
  }
});

Three catastrophic problems emerge:

Data exfiltration — JSON.stringify(invoice) sends password_hash, internal_margin, customer_ssn straight to the LLM provider
Token explosion — Every tool schema sent on every turn, even when irrelevant
Context DDoS — Unbounded findMany() dumps thousands of rows into context window

The MVA Solution: Presenters as Perception Layer

Vurb.ts replaces JSON.stringify() with a Presenter — a deterministic perception layer that controls exactly what the agent sees, knows, and can do next.

import { createPresenter, suggest, ui, t } from '@vurb/core';

const InvoicePresenter = createPresenter('Invoice')
  .schema({
    id: t.string,
    amount_cents: t.number.describe('Amount in cents — divide by 100'),
    status: t.enum('paid', 'pending', 'overdue'),
  })
  .rules([
    'CRITICAL: amount_cents is in CENTS. Divide by 100 for display.'
  ])
  .redactPII(['*.customer_ssn', '*.credit_card'])
  .ui((inv) => [
    ui.echarts({
      series: [{ type: 'gauge', data: [{ value: inv.amount_cents / 100 }] }]
    }),
  ])
  .suggest((inv) =>
    inv.status === 'pending'
      ? [suggest('billing.pay', 'Invoice pending — process payment')]
      : [suggest('billing.archive', 'Invoice settled — archive it')]
  )
  .limit(50);

export default f.query('billing.get_invoice')
  .describe('Get an invoice by ID')
  .withString('id', 'Invoice ID')
  .returns(InvoicePresenter)
  .handle(async (input, ctx) =>
    ctx.db.invoices.findUnique({ where: { id: input.id } })
  );

The handler returns raw data. The Presenter shapes everything the agent perceives:

Egress firewall — Only declared fields pass through
PII redaction — Late Guillotine Pattern masks sensitive fields
Domain rules — Travel with data, not in system prompt
UI blocks — Server-rendered charts (ECharts, Mermaid)
Next actions — HATEOAS hints computed from state

Ship a SKILL.md, Not a Tutorial

Vurb.ts ships a SKILL.md — a machine-readable architectural contract that your AI agent ingests before generating a single line.

One prompt. Working server. Zero iterations:

→ "Build an MCP server for patient records with Prisma. 
   Redact SSN and diagnosis from LLM output. 
   Add an FSM that gates discharge tools until attending physician signs off."

The agent reads SKILL.md and produces:

const PatientPresenter = createPresenter('Patient')
  .schema({ id: t.string, name: t.string, ssn: t.string, diagnosis: t.string })
  .redactPII(['ssn', 'diagnosis'])
  .rules(['HIPAA: diagnosis visible in UI blocks but REDACTED in LLM output']);

const gate = f.fsm({
  id: 'discharge',
  initial: 'admitted',
  states: {
    admitted: { on: { SIGN_OFF: 'cleared' } },
    cleared: { on: { DISCHARGE: 'discharged' } },
    discharged: { type: 'final' },
  },
});

export default f.mutation('patients.discharge')
  .describe('Discharge a patient')
  .bindState('cleared', 'DISCHARGE')
  .returns(PatientPresenter)
  .handle(async (input, ctx) =>
    ctx.db.patients.update({
      where: { id: input.id },
      data: { status: 'discharged' },
    })
  );

Correct Presenter with .redactPII(). FSM gating that makes patients.discharge invisible until sign-off. File-based routing. Typed handler. First pass — no corrections.

Get Started in 5 Seconds

vurb create my-server
cd my-server && vurb dev

That's it. A production-ready MCP server with:

File-based routing
Presenters with egress firewall
Middleware (auth, permissions)
Pre-configured for Cursor, Claude Desktop, VS Code + Copilot, Windsurf, Cline

Key Features

1. Zero Trust Sandbox — Computation Delegation

The LLM sends JavaScript logic to your data instead of shipping data to the LLM. Code runs inside a sealed V8 isolate:

export default f.query('analytics.compute')
  .describe('Run a computation on server-side data')
  .sandboxed({ timeout: 3000, memoryLimit: 64 })
  .handle(async (input, ctx) => {
    const data = await ctx.db.records.findMany();
    const engine = f.sandbox({ timeout: 3000, memoryLimit: 64 });
    try {
      const result = await engine.execute(input.expression, data);
      if (!result.ok) return f.error('VALIDATION_ERROR', result.error)
        .suggest('Fix the JavaScript expression and retry.');
      return result.value;
    } finally {
      engine.dispose();
    }
  });

Zero access to process, require, fs, net, fetch, Buffer. Timeout kill, memory cap, automatic isolate recovery.

2. FSM State Gate — Temporal Anti-Hallucination

The first framework where it is physically impossible for an AI to execute tools out of order.

If the workflow state is empty, the cart.pay tool doesn't exist in tools/list:

const gate = f.fsm({
  id: 'checkout',
  initial: 'empty',
  states: {
    empty: { on: { ADD_ITEM: 'has_items' } },
    has_items: { on: { CHECKOUT: 'payment', CLEAR: 'empty' } },
    payment: { on: { PAY: 'confirmed', CANCEL: 'has_items' } },
    confirmed: { type: 'final' },
  },
});

const pay = f.mutation('cart.pay')
  .describe('Process payment')
  .bindState('payment', 'PAY') // Visible ONLY in 'payment' state
  .handle(async (input, ctx) => ctx.db.payments.process(input.method));

3. Code Generators

OpenAPI → MCP in One Command:

npx openapi-gen generate -i ./petstore.yaml -o ./generated
API_BASE_URL=https://api.example.com npx tsx ./generated/server.ts

Prisma → MCP with Field-Level Security:

model User {
  id           String @id @default(uuid())
  email        String @unique
  passwordHash String /// @vurb.hide
  stripeToken  String /// @vurb.hide
  tenantId     String /// @vurb.tenantKey
}

n8n Workflows → MCP Tools:

const n8n = await createN8nConnector({
  url: process.env.N8N_URL!,
  apiKey: process.env.N8N_API_KEY!,
  includeTags: ['ai-enabled'],
  pollInterval: 60_000,
});

Deploy Anywhere

Same code on Stdio, SSE, Vercel Functions, Cloudflare Workers:

// Vercel Functions
import { vercelAdapter } from '@vurb/vercel';
export const POST = vercelAdapter({ registry, contextFactory });
export const runtime = 'edge';

// Cloudflare Workers
import { cloudflareWorkersAdapter } from '@vurb/cloudflare';
export default cloudflareWorkersAdapter({ registry, contextFactory });

Why This Matters

Most MCP frameworks are just wrappers around JSON.stringify(). Vurb.ts is different:

✅ Security-first — Egress firewall, PII redaction, sandboxed execution
✅ Zero learning curve — Ship a SKILL.md, agents write the code
✅ Production-ready — State sync, FSM gating, middleware, testing
✅ Type-safe — Full TypeScript, tRPC-style client, compile-time validation
✅ Deploy anywhere — Stdio, SSE, Vercel, Cloudflare Workers

Resources

Stop building MCP servers for humans. Start building for AI agents.

Today I launched Vinkius.

Renato Marinho — Wed, 11 Mar 2026 12:32:16 +0000

Let me tell you why. When I discovered Anthropic's MCP protocol, I became obsessed. The promise was huge: any AI assistant — Claude, Cursor, ChatGPT — could talk directly to external systems. CRMs, ERPs, databases, APIs. In natural language.

But there was a problem.

Building an MCP server was slow, complex, and full of technical traps. It required code. It required infrastructure. It required time most people simply don't have.

So I set myself one goal:

→ Any API. MCP server. 30 seconds. No coding.

Not as a proof of concept. As a real product, with enterprise-grade security out of the box.

I spent months building that. Today it's live.

You paste your OpenAPI spec URL.
You configure in seconds.
You deploy.

And then — you ask Claude "what were the sales this week" and it pulls the answer straight from your system. In real time. In natural language.

For developers who want full control, we built Vurb.ts — an open-source TypeScript framework that deploys to the global edge in 4 seconds.

For experts who want to package knowledge without code — we built Skills. You write in plain text. The AI uses it.

Built in Portugal. Built for the world.

If you have an API you want your AI to talk to — come try it. https://vinkius.com/en

From Zero to MCP Server in 30 Seconds: Why I Stopped Writing Boilerplate

Renato Marinho — Thu, 05 Mar 2026 22:14:43 +0000

If you've built an MCP server before, you know the drill. You spend 20 minutes wiring up the registry, another 15 debugging why your tool isn't showing up in Claude, and then you realize you forgot to sanitize that one field that absolutely shouldn't go to the LLM.

I've been there. More times than I'd like to admit.

That's why when I started playing with MCP Fusion, the first thing that hit me wasn't the architecture (though MVA is genuinely clever) — it was how fast I could get something real running. Like, "I typed one command and now I'm shipping" fast.

The "Wait, That's It?" Moment

Here's the entire onboarding:

npx fusion create my-server

That's it. No npm install afterwards, no copying .env.example, no hunting for the right tsconfig settings. The CLI scaffolds a complete project:

my-server/
├── src/
│   ├── fusion.ts          # initFusion<AppContext>() - typed once, inferred everywhere
│   ├── context.ts         # Your AppContext factory
│   ├── server.ts          # Bootstrap with autoDiscover (the magic part)
│   ├── tools/
│   │   └── system/
│   │       ├── health.ts  # Working health check, already wired
│   │       └── echo.ts    # Connectivity test, ready to go
│   ├── presenters/        # MVA's secret sauce
│   ├── middleware/        # Auth, logging, whatever you need
├── tests/                 # Vitest pre-configured
├── .cursor/mcp.json       # Pre-connected to Cursor
├── .env.example
└── package.json           # All deps, all scripts

Run fusion dev, and you're live. Connect Cursor or Claude Desktop, and your tools just… appear. No manual registration. No restart cycles. It feels almost suspicious.

The Real Win: `autoDiscover()`

Most frameworks make you maintain a central index file. Add a new tool? Edit index.ts, import, register, commit, pray you didn't break the build.

MCP Fusion flips that. Drop a .ts file in src/tools/, and it's automatically registered:

src/tools/
├── billing/
│   ├── get_invoice.ts  → billing.get_invoice
│   └── refund.ts       → billing.refund
├── users/
│   ├── list.ts         → users.list
│   └── update_role.ts  → users.update_role

Under the hood, server.ts does this:

import { autoDiscover } from '@vinkius-core/mcp-fusion';

const registry = f.registry();
const discovered = await autoDiscover(registry, './src/tools');
console.error(`📦 Discovered ${discovered.length} tool(s)`);

It scans, imports, validates, and registers — skipping .test.ts and .d.ts automatically. Your git diffs stay clean because adding a feature never touches a shared file. Small thing? Maybe. But after maintaining a 50-tool server the old way, it feels like getting your weekends back.

But Wait — Where's the Safety?

Speed without guardrails is just technical debt in fast-forward. MCP Fusion bakes safety into the scaffolding via the MVA pattern (Model-View-Agent).

Remember that UserPresenter you saw in the scaffold? It's not just for show:

// src/presenters/UserPresenter.ts
const UserPresenter = createPresenter('User')
  .schema(z.object({
    id: z.string(),
    name: z.string(),
    email: z.string(),
    // password_hash? internal_flags? tenant_id?
    // → Not in the schema = physically absent from output.
  }))
  .rules((user, ctx) => [
    ctx?.user?.role !== 'admin'
      ? 'RESTRICTED: Mask email domain for non-admins'
      : null,
  ]);

This isn't filtering at the API layer. Zod's .strict() rejects undeclared fields at parse time — they never make it into memory for the LLM to see. That's an egress firewall by design, not by hope.

And because rules travel with the data via .rules(), you get context tree-shaking: invoice logic only loads when you're working with invoices. Token usage drops from ~2k/call to ~200. Your Anthropic bill will notice.

The "Oh Right, Testing" Part

So many quickstarts skip this. MCP Fusion doesn't. Your scaffolded project includes:

vitest.config.ts pre-wired
tests/setup.ts with context mocks
A passing system.test.ts you can actually learn from

Run npm test and it just works. No hunting for the right mock pattern. No "why is my context undefined?" at 2 AM.

When You Need More Power

The --vector flag is where things get spicy. Need to expose your Prisma schema safely?

npx fusion create my-api --vector prisma --transport sse --yes

This doesn't just generate CRUD tools. It builds Presenters that act as an egress firewall: sensitive columns like password_hash or ssn are stripped at the schema level, before serialization. No raw SQL, no injection risks, no "oops I leaked PII" postmortems.

Why This Matters

I'm not saying MCP Fusion is the answer for every use case. But if you're:

Tired of maintaining massive switch statements for tool routing
Worried about token costs from dumping raw JSON to LLMs
Shipping MCP servers to production and need guardrails that don't slow you down

…then the 30-second scaffold is just the entry point. The real value is in the architecture that comes pre-wired: MVA for deterministic agent perception, Zod for schema-as-boundary, and file-based routing that scales without ceremony.

Try It. Break It. Tell Me What You Think.

npx fusion create my-experiment
cd my-experiment
fusion dev

Connect your favorite MCP client. Add a tool in src/tools/. Watch it appear instantly.

Then go deeper: add a Presenter, inject a rule, render a server-side chart with .ui(). See how the framework guides you toward patterns that keep your agents reliable and your costs predictable.

I built MCP Fusion because I needed this for my own projects at Vinkius Labs. If it saves you even one afternoon of boilerplate debugging, it's done its job.

What's the first tool you'd build with this? Drop a comment — I read every one.

P.S. If you hit a snag, the docs at mcp-fusion.vinkius.com have the full reference. And yes, the quickstart really does take 30 seconds. I timed it.

MCP Fusion - The framework for AI-native MCP servers.

Renato Marinho — Wed, 04 Mar 2026 11:20:09 +0000

Type-safe tools, Presenters for LLM perception, governance lockfiles, and zero boilerplate. https://github.com/vinkius-labs/mcp-fusion

I Tried to Deploy My MCP Server to Vercel. Here's What Actually Happened.

Renato Marinho — Fri, 27 Feb 2026 06:17:07 +0000

I built a working MCP server. It connected to my database, returned tool results, and worked flawlessly in Claude Desktop locally.

Then I pushed to Vercel.

TypeError: Cannot read properties of undefined (reading 'addEventListener')

500 errors everywhere. The MCP adapter was trying to use persistent SSE connections inside ephemeral serverless functions. Everything broke — and it wasn't obvious why or how to fix it.

I wasn't alone. This is a known, documented problem across the community.

Why MCP and Serverless Don't Get Along

MCP was designed for long-lived processes. The original spec only supported two transports: stdio (local-only) and SSE (persistent server-sent events over HTTP). Both assume the server stays alive between calls.

Vercel Functions don't work that way. Each request can land on a different function instance. Memory is ephemeral. There's no persistent filesystem. And SSE connections stored in memory — poof, gone on the next cold start.

The result is a mess developers across Reddit, GitHub, and dev.to have been hitting for months:

SSE connections drop — The session lives in-memory on instance A. The next request hits instance B. Session not found.
autoDiscover() fails silently — It scans directories at boot. Vercel has no persistent filesystem.
Cold starts waste CPU — Zod reflection, schema generation, and Presenter compilation run from scratch on every cold invocation.
Transport bridge breaks — The official MCP SDK's StreamableHTTPServerTransport expects Node.js http.IncomingMessage. Vercel Edge Runtime uses Web Standard Request/Response. Manually bridging them is fragile and often breaks.
The adapter's disableSSE: true — Doesn't even exist as a property in ServerOptions. You're stuck.

The MCP protocol spec itself acknowledges this: statelessness and horizontal scaling are on the official roadmap as unresolved challenges. A GitHub discussion from the core team literally says: "I'm building a hosting platform for deploying MCPs and SSE makes it hard to scale remote MCPs because we can't use serverless."

This isn't a niche edge case. It's the default experience for anyone who tries to ship an MCP server to a modern deployment platform.

The Deeper Problem: Even When It Deploys, the AI Still Guesses

Let's say you do get past the deployment wall. You still have a second, subtler problem.

Most MCP servers today look like this:

handler: async ({ input }) => {
  return JSON.stringify(await db.query('SELECT * FROM invoices'));
}

Raw JSON. No context. No rules. No hints on what to do next.

The LLM receives amount_cents: 45000 and has to guess — is that dollars? Cents? Yen? It receives 3,000 invoice rows and burns your entire context window. It receives a stripe_payment_intent_id and a password_hash that were never meant to leave your database.

These aren't prompt engineering problems you solve with longer system prompts. They're architecture problems. The handler is doing too much, and the AI is receiving too little structure.

The two problems are related. Developers struggling to deploy their MCP server often never get far enough to realize the data layer is also broken.

MCP Fusion: A New Architecture for Agentic MCP Servers

MCP Fusion is an architecture layer built on top of the MCP SDK. It introduces the MVA pattern (Model-View-Agent) — a deliberate separation of three concerns that raw MCP servers collapse into one function.

Layer	Responsibility
Model	Handler returns raw data. Just a fetch or DB query. Nothing else.
View (Presenter)	Strips unauthorized fields, attaches domain rules, suggests next actions, truncates large collections.
Agent	Receives a Structured Perception Package — validated data + context + affordances — and acts deterministically.

The handler doesn't check auth. It doesn't filter fields. It doesn't format anything. It just returns data. The framework handles everything else through a deterministic pipeline:

contextFactory → middleware chain → Zod input validation
→ handler (raw data) → Presenter pipeline:
  1. agentLimit()      → truncate before context window overflow
  2. Zod schema        → strip undeclared fields (allowlist, not denylist)
  3. rules()           → attach contextual domain instructions
  4. suggestActions()  → HATEOAS affordances: valid next actions with pre-filled args
  5. uiBlocks()        → server-rendered charts/diagrams (ECharts, Mermaid)
→ Agent receives structured package

Here's what this looks like in practice:

import { initFusion, ui } from '@vinkius-core/mcp-fusion';
import { z } from 'zod';

interface AppContext { db: PrismaClient; user: { role: string; tenantId: string } }
const f = initFusion<AppContext>();

// Auth middleware — runs before EVERY tool that declares it
const auth = f.middleware(async (ctx) => {
  const payload = await verifyJWT((ctx as any).rawToken);
  const user = await prisma.user.findUniqueOrThrow({ where: { id: payload.sub } });
  return { db: prisma, user };
});

// Presenter — the perception layer
const InvoicePresenter = f.presenter({
  name: 'Invoice',
  schema: z.object({
    id: z.string(),
    customer: z.string(),
    amount_cents: z.number().describe('Amount in CENTS — divide by 100 for display'),
    status: z.enum(['draft', 'sent', 'paid', 'overdue']),
    // password_hash, stripe_secret, profit_margin → GONE before the wire
  }),
  rules: (inv) => [
    inv.status === 'overdue'
      ? 'Invoice is overdue. Send a reminder before any other action.'
      : null,
  ],
  suggestActions: (inv) => [
    inv.status === 'draft' ? { tool: 'billing.send', args: { id: inv.id } } : null,
    inv.status === 'overdue' ? { tool: 'billing.remind', args: { id: inv.id } } : null,
  ].filter(Boolean),
  agentLimit: { max: 50 }, // never send 3,000 rows to the LLM
});

// Tool — just fetch data. Everything else is handled.
const getInvoice = f.tool({
  name: 'billing.get',
  description: 'Retrieve an invoice by ID',
  input: z.object({ id: z.string() }),
  middleware: [auth],
  returns: InvoicePresenter, // ← one line wires the whole pipeline
  handler: async ({ input, ctx }) =>
    ctx.db.invoice.findUniqueOrThrow({ where: { id: input.id, tenantId: ctx.user.tenantId } }),
});

Notice: the handler is 3 lines. Auth, field stripping, domain rules, affordances, and truncation happen automatically — not sprinkled across the handler with if statements you forget to copy.

A database migration that adds a column doesn't change what the agent sees. New fields are invisible by default unless you explicitly declare them in the Presenter schema.

The Vercel Adapter: Solving the Deployment Wall

Now back to the original problem. You have a well-structured MCP server. How do you deploy it to Vercel without everything breaking?

MCP Fusion ships a dedicated Vercel Adapter that solves every serverless incompatibility at once:

npm install @vinkius-core/mcp-fusion-vercel

// app/api/mcp/route.ts — the ENTIRE file
import { initFusion } from '@vinkius-core/mcp-fusion';
import { vercelAdapter } from '@vinkius-core/mcp-fusion-vercel';
import { z } from 'zod';

interface AppContext { tenantId: string; dbUrl: string }
const f = initFusion<AppContext>();

const listProjects = f.tool({
  name: 'projects.list',
  input: z.object({ limit: z.number().optional().default(20) }),
  readOnly: true,
  handler: async ({ input, ctx }) =>
    fetch(`${ctx.dbUrl}/projects?tenant=${ctx.tenantId}&limit=${input.limit}`).then(r => r.json()),
});

const registry = f.registry();
registry.register(listProjects);

export const POST = vercelAdapter<AppContext>({
  registry,
  serverName: 'my-mcp-server',
  contextFactory: async (req) => ({
    tenantId: req.headers.get('x-tenant-id') || 'public',
    dbUrl: process.env.DATABASE_URL!,
  }),
});

// Optional: global edge network, ~0ms cold start
export const runtime = 'edge';

vercel deploy

Done. Live at https://your-project.vercel.app/api/mcp.

How It Fixes Each Problem

Serverless Problem	What the Adapter Does
SSE session loss	Uses `enableJsonResponse: true` — pure stateless JSON-RPC. No sessions, no SSE, no memory state to lose between instances.
No filesystem	Registry is built at module scope during cold start. No `autoDiscover()` needed — tools are registered explicitly.
Cold start CPU waste	Zod reflection, schema compilation, middleware resolution happen once and are cached. Warm requests only instantiate `McpServer` + `Transport`.
Transport incompatibility	Uses the MCP SDK's native `WebStandardStreamableHTTPServerTransport`, built for WinterCG runtimes — works on Edge and Node.js.
No `process.env` access	`contextFactory` receives the full `Request` object — headers, cookies, and all environment variables.

The adapter splits work into two phases deliberately:

COLD START (once per instance)
  → Zod reflection       → cached
  → Presenter compile    → cached
  → Schema generation    → cached
  → Middleware resolve   → cached

WARM REQUEST (per invocation)
  → new McpServer()      → ephemeral
  → contextFactory(req)  → per-request
  → JSON-RPC dispatch    → your handler runs
  → server.close()       → cleanup

Cold start pays the cost once. Every subsequent request is just routing + your business logic.

Edge vs. Node.js: Which Runtime?

	Edge	Node.js
Cold start	~0ms, global	~250ms, regional
APIs available	Web APIs only	Full Node.js + native modules
Max duration	5s free / 30s Pro	10s free / 60s Pro
Best for	Fast lookups, simple tools	Database queries, heavy computation

For tools querying Vercel Postgres or Vercel KV, use Node.js. For fast routing or API gateway tools, Edge is ideal. Switch with a single export line.

Native Vercel Services Work Out of the Box

import { sql } from '@vercel/postgres';
import { kv } from '@vercel/kv';

const getUser = f.tool({
  name: 'users.get',
  input: z.object({ id: z.string() }),
  readOnly: true,
  handler: async ({ input }) => {
    const { rows } = await sql`SELECT id, name, email FROM users WHERE id = ${input.id}`;
    return rows;
  },
});

const getCached = f.tool({
  name: 'cache.get',
  input: z.object({ key: z.string() }),
  readOnly: true,
  handler: async ({ input }) => ({ value: await kv.get(input.key) }),
});

No extra config. No adapter magic. Just import and use.

What's Fully Supported on Vercel

✅ Tools, groups, tags, exposition

✅ Middleware chains (auth, rate limiting, etc.)

✅ Presenters — field stripping, rules, affordances, agentLimit

✅ Governance Lockfile — pre-generated at build time

✅ Structured error recovery via toolError()

✅ Vercel Postgres, KV, and Blob

✅ Both Edge and Node.js runtimes

❌ autoDiscover() — no filesystem; register tools explicitly

❌ createDevServer() — use next dev or vercel dev

❌ State Sync notifications — stateless transport by design

Compatible With Any MCP Client

The stateless JSON-RPC endpoint works with everything:

Claude Desktop — direct HTTP config or via proxy
LangChain / LangGraph — HTTP transport
Vercel AI SDK — direct JSON-RPC
FusionClient — built-in type-safe client (tRPC-style)
Any custom agent — standard POST with JSON-RPC payload

The Takeaway

The reason deploying MCP servers to Vercel has been painful isn't a skill issue. The original protocol simply wasn't designed for stateless infrastructure. The combination of SSE transport, in-memory sessions, and filesystem assumptions made serverless deployment an exercise in workarounds — most of which don't work.

MCP Fusion resolves this at the framework level, not the patch level. The Vercel Adapter isn't a set of hacks; it's a first-class adapter that changes the transport model to match the deployment model. Pair it with the MVA architecture, and you stop writing MCP servers that make the AI guess — and start shipping servers that tell the AI exactly what to do next.

Links:

Have you hit this same wall trying to deploy MCP servers to serverless? What transport were you using? Drop a comment — the more real war stories, the better.

Stop Treating AI Agents Like Databases

Renato Marinho — Tue, 24 Feb 2026 13:55:35 +0000

How the Model-View-Agent pattern changed how we build MCP servers - and why it probably should change how you build yours too.

The part of the DeepSeek R1 story that stuck with me had nothing to do with the chip export drama or the stock market panic. What I kept coming back to was the architecture decision: constrain the context, structure the inputs, and suddenly you don't need the brute-force compute everyone assumed was non-negotiable. Efficiency over scale. It worked embarrassingly well.

The MCP ecosystem, right now, is doing the opposite. Enthusiastically.

A Real Build Going Sideways

Early on, we were connecting an agent to a billing database. The first tool implementation was around 30 lines - query the table, serialize the result, hand it back. Straightforward. We shipped it, it passed tests, and we moved on.

Then production happened.

The payload coming back from the database was enormous. The model was receiving raw rows: password_salt, tenant_id, updated_at, a dozen columns that had no business being in the agent's context window. To compensate, we started bolting rules onto the system prompt. Currency formatting here, status handling there. Every time someone noticed the agent doing something slightly wrong, a new rule went in. Six weeks later, the prompt was this exhausting, paranoid document trying to explain the entire company's billing logic to a language model on every single request - including the ones where the user had asked something completely unrelated.

I started calling it Hope-Driven Development. Pipe the data in, write enough instructions that the model should get it right, cross your fingers.

The frustrating part isn't that it fails constantly. It's that it fails unpredictably - in ways that are almost impossible to reproduce in a controlled environment, which means they're almost impossible to fix.

The Three Specific Failure Modes

"LLMs hallucinate" has been repeated so many times it's lost all meaning as a diagnostic. The actual failures in this architecture are more specific than that, and they're worth naming precisely.

Attention dilution. There's solid research on what's sometimes called the "Lost in the Middle" problem: relevant information in the center of a large context gets recalled worse than information at the edges. Fill a context window with irrelevant columns - internal keys, salted hashes, audit timestamps - and you're actively degrading the model's ability to reason about the data you actually care about. The noise crowds out the signal.

Prompt cost at scale. Because raw data arrives stripped of any context, you compensate with instructions. "Always divide monetary values by 100." "If status is pending, suggest the payment flow." These instructions travel on every request - the complex ones, sure, but also the simple ones, the greeting messages, the clarification questions. At meaningful volume, you're burning thousands of tokens per session on rules that are irrelevant to what the user is actually doing. We ran estimates on one project and the annualized overhead was uncomfortable enough that it changed our approach.

Probabilistic formatting. ECharts expects exact JSON. Mermaid diagrams have strict syntax. When you ask a language model to generate these from raw data, you're using a stochastic system to produce output that needs to be deterministically correct. It works most sessions - until it doesn't, and then your user gets a blank chart and you get a support ticket describing an error you cannot reproduce.

MVC Already Solved This (for Humans)

MVC has been the default architecture for web applications for four decades, and it's not hard to see why. The View layer doesn't pass raw database records to the browser. It translates them. A human reading 45000 in a field labeled amount_cents understands it as $450 - they bring context, they infer meaning, they fill gaps.

Agents don't do that. They operate on probability distributions over tokens. Feed them raw, noisy, context-free data and they make educated guesses - usually reasonable ones, occasionally catastrophic ones, always in ways your test suite won't catch.

The realization we kept coming back to was that we weren't dealing with a prompt quality problem. We were dealing with an architecture problem: we'd built a View layer for human eyes and wired an AI directly to the database instead.

MVA: The Same Separation, Applied to AI

We formalized this into a pattern called MVA - Model-View-Agent - and built a TypeScript framework around it: mcp-fusion, open source under Apache 2.0.

The rule is simple: data never reaches the agent raw. It passes through a Presenter - server-side, deterministic code - before the LLM sees it. The Presenter shapes the payload, injects only the rules relevant to this specific data type, handles truncation, and pre-renders anything that doesn't need probabilistic generation.

Rules that travel with data, not ahead of it

export const InvoicePresenter = createPresenter('Invoice')
  .schema(invoiceSchema)
  .systemRules([
    'CRITICAL: amount_cents is in CENTS. Divide by 100 before displaying.'
  ]);

Invoice rules appear when the agent queries an invoice. They don't appear when the agent queries a user profile. The global system prompt shrinks dramatically - in practice, we see around 80% reduction in input tokens per session, because you're only sending context that's genuinely relevant to the current interaction.

Truncation that tells the agent what to do next

export const InvoicePresenter = createPresenter('Invoice')
  .agentLimit(50, (omittedCount) =>
     ui.summary(`⚠️ 50 of ${omittedCount + 50} records shown. Use 'search' with filters to narrow results.`)
  )

A query that returns 10,000 rows won't explode your context window. The array gets sliced at the Presenter level, before serialization, and the agent receives a hint that actively shapes its next move. You're not just capping costs - you're teaching the agent to paginate.

Formatting that doesn't rely on luck

export const InvoicePresenter = createPresenter('Invoice')
  .collectionUiBlocks((invoices) => [
      ui.echarts({
          series: [{ type: 'bar', data: invoices.map(i => i.amount_cents / 100) }]
      })
  ]);

Your Node.js server generates the exact chart configuration. The agent forwards a pre-built block to the client. The LLM is not in the formatting loop at all, which means the formatting loop cannot hallucinate. Not "rarely hallucination" - structurally impossible, because the probabilistic system isn't involved.

Affordances: telling the agent what comes next

Agents get stuck more than people publicly admit. They guess tool names, loop on unfamiliar states, or take reasonable-looking actions that are wrong for the current business context. REST solved a version of this with HATEOAS - the server tells the client which actions are valid from the current state. MVA borrows that idea directly:

export const InvoicePresenter = createPresenter('Invoice')
  .suggestActions((invoice) => {
      if (invoice.status === 'pending') {
          return [{ tool: 'billing.pay', reason: 'Process immediate payment' }];
      }
      return [];
  });

Business logic lives in code that can be reviewed, tested, and versioned - not buried inside a prompt where it's invisible to your normal engineering processes.

What Changes in Practice

MVA doesn't eliminate all agent failures, and I want to be honest about that. Complex multi-step reasoning is still hard. There are problem classes where you want the LLM doing more heavy lifting, not less.

But the specific failure modes we kept running into - unpredictable cost spikes, fragile UI rendering, agents confused by business data they were never supposed to see - all of them were architecture problems. Throwing better prompts at architecture problems just generates more technical debt.

The shift felt less like learning something new and more like applying engineering discipline we already had to a context where we'd been ignoring it.

mcp-fusion is open source, TypeScript.

Docs & MVA Manifesto: vinkius-labs.github.io/mcp-fusion

GitHub: github.com/vinkius-labs/mcp-fusion

If context bloat is something you're actively fighting in your agentic stack, I'd like to know how you're approaching it. Open an issue or drop a comment - genuinely curious what patterns others are landing on.

MVA Architecture: Why Every MCP Framework Has Been Building for the Wrong Consumer

Renato Marinho — Sun, 22 Feb 2026 23:36:51 +0000

Every framework ever built assumed one thing: a human is reading the output.

Rails, Laravel, Express, tRPC — beautiful frameworks. But they all have a blind spot: they were designed for browsers and humans, not for AI agents.

In 2025, MCP (Model Context Protocol) changed everything. Now AI agents are the consumers of our APIs. But here's the problem: every MCP framework still builds for humans.

What Goes Wrong When Agents Consume Human-Designed APIs

Consider this tool response:

{
  "amount": 45000,
  "currency": "USD"
}

Is that $45,000 or $450.00 (stored as cents)? A human reads the UI and knows. An AI agent has no idea — and the consequences can be catastrophic.

This is not a bug. It's a fundamental architectural mismatch.

Introducing MVA: Model-View-Agent

MVA is a new architectural pattern for the MCP ecosystem, implemented in mcp-fusion.

It adds a Presenter layer — a dedicated perception layer that transforms raw data into agent-readable output:

class InvoicePresenter extends FusionPresenter<Invoice> {
  present(invoice: Invoice) {
    return {
      id: invoice.id,
      amount_usd: invoice.amount_cents / 100, // Never ambiguous
      status: invoice.status,
      _actions: [
        { action: 'invoices.pay', when: invoice.status === 'pending' },
        { action: 'invoices.void', when: invoice.status === 'pending' },
      ]
    };
  }
}

The Presenter doesn't just format data — it gives the agent semantic clarity and action affordances: what this data means, and what the agent can do next.

The Three Layers of MVA

Model — Your domain logic. Pure TypeScript. Nothing new here.

View (Presenter) — The agent perception layer. Transforms data into agent-understandable representations with affordances, guardrails, and semantic clarity.

Agent — The consumer. An AI that can now navigate your API confidently, without ambiguity, without hallucination-inducing noise.

How It Compares to Existing Frameworks

Feature	fastmcp	mcp-framework	mcp-fusion
Agent-first design	❌	❌	✅
Presenter layer	❌	❌	✅
Action affordances	❌	❌	✅
Semantic tracing	❌	❌	✅
Cognitive guardrails	❌	❌	✅

Every existing MCP framework solves the developer's problem — how to build a server more easily. mcp-fusion solves the agent's problem — how to understand what the server is saying.

Why This Matters Now

The MCP ecosystem is less than 18 months old. Most teams are still in "make it work" mode. But the frameworks that will dominate the next 5 years are being defined right now.

MVA is the first architectural pattern that treats AI agents as first-class citizens — not as afterthoughts.

GitHub: vinkius-labs/mcp-fusion
Docs: vinkius-labs.github.io/mcp-fusion/mva
NPM: @vinkius-core/mcp-fusion

Which Essential Features Are Missing in Current Agile Project Management Tools?

Renato Marinho — Tue, 04 Feb 2025 07:25:23 +0000

Agile project management tools have improved over time, but many teams still face challenges with specific features. Some tools lack better automation, integrations, or customization options. In your experience, what essential features are still missing or not well implemented?

We've explored various agile project management tools, including GitScrum, Jira, and Trello, to understand their strengths and limitations. While they offer many useful features, some areas still feel lacking, such as advanced automation, deeper Git integrations, or better AI-driven insights. We expected these tools to cover all key agile needs, but some workflows remain inefficient. What features do you think should be improved or added?

DEV Community: Renato Marinho

Vurb.ts: The MCP Framework with Zero Learning Curve

Why Frameworks Matter for AI Agents

The MVA Solution: Presenters as Perception Layer

Ship a SKILL.md, Not a Tutorial

Get Started in 5 Seconds

Key Features

1. Zero Trust Sandbox — Computation Delegation

2. FSM State Gate — Temporal Anti-Hallucination

3. Code Generators

Deploy Anywhere

Why This Matters

Resources

Today I launched Vinkius.

From Zero to MCP Server in 30 Seconds: Why I Stopped Writing Boilerplate

The "Wait, That's It?" Moment

The Real Win: autoDiscover()

But Wait — Where's the Safety?

The "Oh Right, Testing" Part

When You Need More Power

Why This Matters

Try It. Break It. Tell Me What You Think.

MCP Fusion - The framework for AI-native MCP servers.

I Tried to Deploy My MCP Server to Vercel. Here's What Actually Happened.

Why MCP and Serverless Don't Get Along

The Deeper Problem: Even When It Deploys, the AI Still Guesses

MCP Fusion: A New Architecture for Agentic MCP Servers

The Vercel Adapter: Solving the Deployment Wall

How It Fixes Each Problem

Edge vs. Node.js: Which Runtime?

Native Vercel Services Work Out of the Box

What's Fully Supported on Vercel

Compatible With Any MCP Client

The Takeaway

Stop Treating AI Agents Like Databases

A Real Build Going Sideways

The Three Specific Failure Modes

MVC Already Solved This (for Humans)

MVA: The Same Separation, Applied to AI

Rules that travel with data, not ahead of it

Truncation that tells the agent what to do next

Formatting that doesn't rely on luck

Affordances: telling the agent what comes next

What Changes in Practice

MVA Architecture: Why Every MCP Framework Has Been Building for the Wrong Consumer

What Goes Wrong When Agents Consume Human-Designed APIs

Introducing MVA: Model-View-Agent

The Three Layers of MVA

How It Compares to Existing Frameworks

Why This Matters Now

Which Essential Features Are Missing in Current Agile Project Management Tools?

The Real Win: `autoDiscover()`