How I Built an MCP Adapter Layer for SaaS in One Night

I've been thinking about a problem for a while: AI agents are getting smarter every week, but they still can't do much.

Not because they lack reasoning ability — Claude and GPT-4 are genuinely impressive at understanding intent. The bottleneck is execution. They can plan a sequence of CRM updates, but they can't actually touch Salesforce. They can describe the perfect Notion page structure, but they can't create it. They live in a reasoning layer that floats above the tools people actually use.

Zapier solved this for humans ten years ago. You could hook Gmail to Slack, Salesforce to HubSpot, all through a no-code interface. But Zapier was designed for human-triggered workflows. It wasn't designed for an agent that needs to decide, at runtime, which tool to call and with what parameters.

That's the gap I wanted to close.

The Core Insight

MCP (Model Context Protocol) is Anthropic's open standard for giving AI agents access to tools. You define a tool with a name, a description, and an input schema — and the agent can call it. The problem is: someone has to write those tools.

Most teams end up with bespoke integrations for each SaaS they need. Notion gets its own tool file. Slack gets another. Salesforce requires OAuth dance, field mapping, and a lot of anycasts. It's boring, repetitive work that shouldn't exist.

The insight for MCPBridge was: what if the adapter pattern from backend engineering was applied to MCP tools?

The MCP Tool Schema Structure

Here's what a Notion adapter looks like under the hood:

export const notionAdapter = {
  id: "notion",
  name: "Notion",
  tools: [
    {
      name: "create_page",
      description: "Create a new Notion page in a specified parent page or database",
      inputSchema: {
        type: "object",
        properties: {
          parent_id: {
            type: "string",
            description: "The ID of the parent page or database"
          },
          title: {
            type: "string",
            description: "The title of the new page"
          },
          content: {
            type: "string",
            description: "Optional markdown content for the page body"
          }
        },
        required: ["parent_id", "title"]
      }
    }
  ]
};

That shape — name, description, inputSchema — is exactly what the MCP spec expects. The adapter just needs to implement an execute(toolName, params)method, and you're done.

For the playground demo, a test call against create_page returns something like:

{
  "id": "page_abc123",
  "url": "https://notion.so/My-New-Page-abc123",
  "created_time": "2025-01-15T03:22:00Z",
  "parent": { "type": "database_id", "database_id": "db_xyz789" }
}

What Surprised Me

I expected the hard part to be the API integrations. It wasn't — most modern SaaS APIs are actually pretty clean.

The hard part was schema design. Agents are sensitive to description quality. If you describe a tool vaguely, the agent either doesn't use it or uses it wrong. Writing tight, precise descriptions for each tool — descriptions that tell the agent when to use something, not just what it does — took longer than the actual code.

The second surprise: the playground was the most valuable part of the product. Being able to pick an adapter, see the exact tool schema the agent would receive, and run a mock call — that removes so much uncertainty. Developers don't have to guess what the agent is seeing. They can see it.

What I'd Do Next

1. 01Real execution — right now the playground runs mock calls. The next version would route real API calls through a server-side handler with OAuth token storage.
2. 02Schema validator — let developers paste an OpenAPI spec and auto-generate the MCP adapter from it. That alone would cover 80% of SaaS APIs.
3. 03Adapter registry — a community-maintained index of adapters, like npm for MCP tools. Publish once, install everywhere.

The agent economy is coming. The missing piece isn't better models — it's better connectors. MCPBridge is my attempt at that connector layer.

— Jacobo