Bridging any MCP server as a typed Tutti voice

One question that comes up every time a new agent framework launches: how do you connect to X? Where X is some integration the framework's authors haven't built yet — Linear, Figma, Notion, Supabase, an internal CRM, a homegrown ticketing system, anything.

The bad answer is: file an issue, wait, hope. That's the answer most frameworks give. It scales badly because the universe of "tools an agent might want" is genuinely unbounded, and the team building the framework will never be the same size as the team building the world.

The Model Context Protocol (MCP) is the answer to that mismatch. MCP is an open spec — originating from Anthropic, now broadly adopted — that defines how a tool server exposes its tools to an agent. If something has an MCP server, any MCP-aware client can use it.

Tutti is an MCP-aware client out of the box, via `@tuttiai/mcp`.

One install, every MCP tool

tutti-ai add mcp

That's the whole installation. The MCP voice is now in your project. From a score file, you point it at any MCP server — local stdio, remote HTTP, official, third-party, your own — and its tools become typed Tutti tools. Permissions, HITL gating, prompt-injection scanning, all of it applies.

Why bridging beats re-implementing

The naive thing for a framework author to do is re-implement every integration as a first-party voice. That's how you end up with sixty voices that each have one maintainer and lag behind their underlying APIs by six months. We're not going to do that.

What we'll do instead is ship official voices for the integrations where Tutti can be opinionated — where the voice should know about HITL gating on writes, rate limits, retry policy, idiosyncratic auth flows. Stripe, GitHub, Postgres, Slack, Discord, Twitter — those benefit from a voice that's been thought about.

For the long tail — the random SaaS your team uses, the internal microservice, the new tool that shipped last week — bridge MCP. The bridge gets you the integration in zero glue code; if the integration is important enough that you want HITL on its writes, you can wrap it in a thin Tutti voice that delegates to MCP under the hood.

What you give up

Bridging means you inherit whatever the MCP server's author decided. If they didn't mark a destructive operation as destructive, neither does the bridge. If they expose a tool with an unsafe interface, that interface comes through. The MCP voice automatically sets `required_permissions: ['network']` because every sensible MCP server makes network calls, and you can layer additional Tutti gating on top — but the underlying tools are as good as the upstream server.

That's an honest trade-off. Re-implementing means slow rollout but tighter defaults. Bridging means fast rollout and the upstream's defaults. We pick differently for different integrations and we tell you which is which.

Why this is the right architecture

The plugin ecosystem is the framework. Twelve official voices today, a long tail of MCP servers reachable through the bridge, and anyone who wants to ship a typed voice can publish to npm. The framework's job is to set the safety and observability defaults; the ecosystem's job is to fill in the verbs.