How I built MCPBridge in one night

I keep running into the same wall with AI agents: the models are good enough now, but the execution layer still sucks.

An agent can reason about a support workflow, summarize a sales call, or decide which CRM field to update. Then it hits reality. Suddenly it needs a Slack bot, a Notion client, a HubSpot integration, a Salesforce wrapper, an auth layer, and a custom tool schema that matches whatever agent runtime you’re using. The reasoning is clean, the plumbing is not.

That was the motivation for MCPBridge.

The idea was simple: build a product that shows what a clean adapter layer for the MCP ecosystem could look like. Not a vague landing page, not a fake startup site, but an actual interactive tool with demo adapters, inspectable MCP actions, and realistic mock responses so it feels alive on first load.

The core insight

I didn’t want to build another integration dashboard. The interesting part is not listing logos. It’s standardizing the interface between agents and SaaS tools.

MCP gives us a strong primitive for this: tools with names, descriptions, and input schemas. So each SaaS platform became an adapter, and each adapter exposes MCP-friendly tools with realistic params and responses.

interface McpTool {
  name: string;
  description: string;
  inputSchema: Record<string, unknown>;
  mockResponse: Record<string, unknown>;
}

That model let the UI stay simple. Pick an adapter, inspect the tools, hit test, render JSON. Clean loop.

What surprised me

The surprise wasn’t the frontend. That part moved quickly. What took more thought was product framing. “Zapier for agents” is a useful shortcut, but it’s also slightly wrong. Zapier is workflow-first. MCPBridge is interface-first.

I also realized the empty state matters more than people think. Empty states are where fake products die. So the playground still had to feel intentional before any adapter was selected.

What I’d do next

1. 01Add real auth and execution flows instead of mock responses.
2. 02Generate adapters from OpenAPI specs to cover most SaaS APIs faster.
3. 03Build traces, permission logs, and adapter observability for production trust.

setTimeout(() => {
  setTestOutput(JSON.stringify(tool.mockResponse, null, 2));
  setIsRunning(false);
}, 600);

I built MCPBridge because I think the next bottleneck for agents is not intelligence, it’s access. The winners will be the products that make software callable.

— Jacobo