Intelligence that cannot reach outward is intelligence in a locked room. The Model Context Protocol — MCP — is how the Consilience opens its doors. It is not a feature of the platform. It is the layer through which every external tool sees the platform, and through which the platform sees every external tool. Seventeen servers, fifteen consumed and two built, running as a permanent infrastructure layer rather than as one-off integrations.
The consumed servers form a ring of institutional capability around the core. Supabase exposes the database schema, migrations, and logs — the platform's memory, reachable as structured resources rather than raw queries. PostHog surfaces analytics, feature flags, experiments, and session recordings — the platform's self-knowledge, the data that tells it whether what it built is actually being used. Clerk manages authentication, user profiles, and organizations — the platform's sense of who is at the door. GitHub gives access to the repository, pull requests, and CI — the codebase as a living thing, not a static artifact. Vercel exposes deployments, environment variables, and domains — the platform's delivery surface.
Figma bridges design and code, letting the platform read design files as structured data and write components back into the design system. Hugging Face provides model discovery, dataset management, and training job orchestration — the platform's window into the broader AI ecosystem. Stripe handles payments, invoices, and subscriptions. Slack carries notifications and team communication. Sentry captures errors with full stack traces and context. Resend sends transactional email through React Email templates. Browserbase runs headless browser automation for tasks that need to see a rendered page.
Three Cursor-native servers complete the set: one for application control, one for backend API access, and one for the IDE browser — the surfaces through which the Conductor herself reaches the development environment.
What makes this infrastructure rather than a collection of integrations is that the servers are always running. They are not started when someone asks a question and torn down when the answer arrives. They are permanent, always-on, reachable by any agent at any time from any surface. The Conductor does not need to remember to check Sentry. The Sentry server is already there, waiting.
The two custom servers
The Consilience builds two MCP servers of its own, and both carry lessons worth understanding.
@kaos/claw wraps the entire library API — search, books, bookcasts, sparks, Chronicle episodes, user entitlements — into a single installable package available on npm. Any developer running npx @kaos/claw in their terminal gets a fully functional MCP server that exposes the Consilience library as a tool catalog. A Cursor agent can ask it to search for books. A Claude Desktop session can retrieve reading history. A custom IDE plugin can browse the Chronicle. The package is self-contained, type-safe, and designed to be the canonical way external tools reach the platform. It demonstrates something important: an MCP server does not need to be bespoke infrastructure. It can be an npm package, versioned, tested, and distributed like any other piece of software.
vercel-mcp does the same for the Vercel deployment surface — exposing deployments, projects, environment variables, and domains through typed tools that any MCP-compatible client can consume.
The pattern is the lesson. Both servers share the same architecture: TypeScript, typed tool definitions with Zod schemas for input validation, clear error messages that tell the caller what went wrong rather than what error code was thrown, and a transport layer that supports both stdio and HTTP. A student who wants to build their own MCP server should start by reading these two. They are not large. They are not abstract. They are working production servers that follow the same patterns the Anthropic documentation recommends, implemented in the same language the rest of the platform uses.
MCP as client
The platform consumes MCP as well as serving it. The broker — the runtime nerve center on the Mac Studio — connects to ToolPiper MCP for voice synthesis. When the Conductor needs to speak, the broker does not call a TTS API directly. It sends a structured request to ToolPiper's MCP server, which handles the synthesis and returns audio data. The broker never touches the voice model. It never manages TTS state. It delegates to a tool that does one thing well, and the delegation itself is MCP.
This is the architectural principle in miniature. MCP is not a bridge between two specific pieces of software. It is a protocol, like HTTP, that any two pieces of software can speak. The broker does not care that ToolPiper is a macOS application. ToolPiper does not care that the broker is a Python FastAPI server. They share a protocol, and the protocol is enough.
The Consilience publishes HTTP MCP endpoints at three paths: /api/mcp/kaos for the library, /api/mcp/chat-history for conversation retrieval, and /api/mcp/catalog for book metadata. These endpoints accept standard MCP JSON-RPC requests and return standard MCP JSON-RPC responses. They are versioned, documented, and open. Any MCP-compatible client — Cursor, Claude Desktop, a terminal tool, a research agent — can connect to them with nothing more than an API key and the endpoint URL.
The infrastructure asks nothing of its callers except that they speak the protocol. The protocol asks nothing of its implementations except that they expose typed tools, typed resources, and clear error messages. Everything else is convention, and the conventions are documented well enough that a student can build a working server in an afternoon.