Wiring the Studio with MCP

Eighteen months ago, connecting an AI assistant to a real system meant writing a bespoke integration that broke monthly. Then Anthropic released the Model Context Protocol in late 2024, and something unusual happened: the industry actually agreed on it. By this spring, MCP support has landed across the major AI platforms and tools, and what was a spec has become plumbing. We have spent the last quarter wiring the studio with it. Field report follows.

What MCP actually is, minus the hype

MCP is a standard way for AI applications to discover and use external capabilities: tools they can call, resources they can read, prompts they can reuse. The useful analogy is USB. Before it, every device needed its own port and driver; after it, things just plugged in. An MCP server wraps a system, our project database, a client's CMS, a design token pipeline, and any MCP-capable assistant can use it without custom glue.

The configuration side is deliberately boring:

{
  "mcpServers": {
    "studio-projects": {
      "command": "node",
      "args": ["./servers/projects/index.js"],
      "env": { "PROJECTS_DB_URL": "..." }
    }
  }
}

Boring is the achievement. The last decade of integration work taught everyone what happens without a standard: N tools times M systems equals N times M custom integrations, forever.

What we have wired up

Three servers are in daily use, and each earned its place by killing a real annoyance:

• The project context server. Exposes briefs, tech decisions, and design tokens per project. An engineer's assistant can answer "what is the spacing scale on this project and why" from the actual source instead of hallucinating a plausible one. This single server did more for generated-code quality than any prompt engineering we tried, which echoes what I wrote in March: machines behave when they can see the system.
• The design token bridge. Reads the token pipeline, so assistants generating components pull real values and flag drift between Figma and code. Boring, transformative.
• A read-only analytics server for our growth team, letting Leo's crew interrogate campaign data conversationally instead of exporting CSVs into oblivion.

Note the pattern: read-heavy, narrow, per-project scoped. That is deliberate.

Where we draw the lines

MCP's power is exactly its risk: it makes granting capabilities to AI systems frictionless, and friction was doing more security work than anyone admitted. Our rules, learned partly the easy way and partly not:

• Read-only by default. Write access is granted per tool, per project, with a human approval step for anything destructive. An assistant that can query the CMS is an asset. One that can delete from it is an incident report waiting for a timestamp.
• Credentials are scoped and boring. Servers get the narrowest token that works, and never a shared admin anything.
• Third-party MCP servers get reviewed like dependencies, because that is what they are. The ecosystem is exploding, and an MCP server is arbitrary code with, potentially, your credentials. Enthusiasm is not a security posture.
• Log everything the assistant does. Not for surveillance, for debugging. "Why did it think that" is answerable when you can see what it read.

Why a design studio should care

The strategic point for clients: MCP is quietly turning "AI integration" from a special project into a checkbox, and that changes procurement math. When a client asks us to make their systems AI-ready, increasingly the honest answer is not a six-month platform build. It is a set of well-scoped MCP servers over the systems they already own, plus governance. Standards eat platforms. It is one of the few reliable patterns in this industry, and it is happening again, faster than usual.