Host Your Own MCP Server: Model Context Protocol Inside AACFlow Workflows

The transport is Server-Sent Events over a persistent HTTP connection. Why SSE and not WebSockets? Because MCP is request/response with optional server-pushed notifications, and SSE gives us that natively over plain HTTPS. No upgrade handshake, no extra ports, no proxy gymnastics. Every reverse proxy from nginx to Cloudflare to Traefik passes SSE without configuration. WebSockets would have added breakage for no semantic gain.

Underneath the SSE stream, we speak JSON-RPC 2.0. The MCP spec defines the methods — initialize, tools/list, tools/call, notifications/progress — and we implement the dispatch in app/api/mcp/serve/route.ts with a small registry that maps method name to handler. Capability negotiation happens once on initialize: the client tells us what notifications it can receive, we tell it which tools and resources we expose. Nothing else is exchanged out-of-band.

Authentication and Scoping

MCP does not standardise auth. That is correct — it is a wire protocol, not an identity system. AACFlow layers auth on top through workspace API keys passed as a bearer token on the initial SSE connection. Once authenticated, the server scopes every subsequent tools/list and tools/call to that workspace.

This matters more than it sounds. Most MCP server implementations in the wild are single-tenant — one server, one user, one set of tools. AACFlow is multi-tenant by design, so the same endpoint serves a different tool catalogue to every API key. The mcpServers table in packages/db/schema.ts is where workspace-level external servers are registered, but the inbound server is a virtual surface computed at request time from the workspace's deployed workflows. No per-tenant deployment, no per-tenant DNS — one endpoint, scoped by token.

Registering External MCP Servers

The other direction is just as important. Inside a workflow, an agent block can call a tool exposed by any external MCP server registered for the workspace. We store them in the mcpServers table — id, workspaceId, name, url, transport, plus credentials — and surface them in the block UI through three SubBlock types: mcp-server-selector picks the server, mcp-tool-selector lists the tools that server advertises via tools/list, and mcp-dynamic-args renders an input form generated from the selected tool's JSON schema.

That last one is the unlock. Because MCP tools carry their own argument schema, AACFlow can render a typed form for any tool from any server without us writing integration code. Register a new MCP server, refresh the tool list, the form fields appear automatically. The same loop a human follows manually — discover, select, fill, invoke — is what the LLM does at runtime when the block is configured in agent mode.

Why This Beats Hand-Rolled Integrations

We have over 300 first-party integrations in AACFlow today. Building each of them takes engineering time, a credential flow, a block schema, a tool schema, an icon. MCP changes the economics for the long tail. If a niche tool ships an MCP server, our users pull it in without us shipping anything. The standard does the integration work.

It also changes what "exposing a workflow" means. Before MCP, exposing a workflow as a tool meant building a custom GPT wrapper, or writing an OpenAPI spec, or hosting a webhook with bespoke auth. Now it means flipping a switch. Your sales-followup workflow becomes a Cursor command. Your incident-triage workflow becomes a Claude Desktop tool. Your data-cleanup workflow becomes a tools/call from any agent that speaks MCP.

A Few Things We Learned Implementing It

Three sharp edges worth flagging if you implement MCP yourself:

• SSE keep-alives matter. Without a heartbeat every 15–30 s, intermediate proxies will close the connection. We send a : keepalive comment line on a timer and survive Cloudflare, nginx, and Traefik defaults without tuning.
• tools/list must be cheap. Clients call it on every connection and often after every tool change. Compute it from a workspace-scoped Postgres query, cache it in Redis with workflow-deploy events as the invalidator, do not hit the executor.
• Progress notifications are optional but transformative. When a workflow takes 20 s, streaming notifications/progress events through the same SSE channel turns "is it hung?" into a real progress bar in the client UI. The spec is opt-in. Opt in.

Where MCP Is Headed (And Why You Should Bet on It)

Anthropic shipped MCP in late 2024. By mid-2026, the major IDEs, the major chat clients, and most agent frameworks speak it. There is no second protocol on the horizon. If you are building a platform that exposes tools to LLMs, you do not get to skip this — your users will demand it before you finish building your alternative.

AACFlow's bet is simple. Every workflow is a tool. Every external tool is a workflow input. The protocol that connects them is open, standard, and already in production at most of your users' desks.

Open /api/mcp/serve in your workspace API panel. Connect a client. Watch your workflows show up as tools.