# The Integrations

**Track 11 of 11 · inward and outward — MCP, APIs, and building on the Kidunaverse · v5.0**

Integration runs in two directions, and this track holds both: **inward** — the MCP servers, APIs, and local agents we connect to, so allies can act in the world; and **outward** — our own API and MCP server, so anyone can build on us. The permission model for both directions already exists: the Tool node, grants, and the four access levels ([Foundation](foundation.html)), checked by the graph service on every call. Nothing in this track invents new access; it plugs new parties into the access that exists.

---

## 1. Inward — what we connect to

**MCP servers, attached in [Studio](surfaces.html), scoped to containers.** A member (or a Builder acting for an organization) connects an MCP server and attaches it to a specific relationship, guild, alliance, or organization — the container is the scope. A scheduling server attached to an alliance serves that alliance's work and nothing else; a payments tool attached to an organization acts only inside its treasury rules. The running list of interesting servers is maintained as wisdom (a living, curated inventory by category — payments and commerce, calendars and scheduling, docs and storage, social and messaging, web and search, creative tooling, dev tools) rather than frozen in this spec.

**Local agents on the member's own machine — the package protocol.** Studio interoperates with **Claude Cowork / Claude Code and OpenAI Codex** running locally over a defined **package-passing protocol**, modeled on the dispatch protocol we run between our own sessions: Studio hands out a self-describing package (context, the ask, constraints, where to return), the coding agent works it in its own environment, and the result returns as a package Studio unpacks into the graph — the exchange recorded like any other work. The member's machine stays theirs; the ally coordinates, it doesn't colonize.

**The first Institution integration: Lightbrush.** The working pattern for bringing an outside stack in ([Institutions](institutions.html)): Lightbrush LLC's creative agents and tooling (Dowbot, Zhowbot, Digital Dolly, RenderDeck, the audio system) integrate into The Ceremony Machine with Elias as forward-deployed engineer — Lightbrush's IP stays Lightbrush's, the integration work is ours, and usage-based distributions flow from the duna's treasury per its recorded configuration. Every future Institution integration should be recognizable from this shape.

**Channels are integrations too.** Telegram, Bluesky, email, the browser ([Express](surfaces.html)) — one system presence per channel ([Orchestration §3](orchestration.html)), thin adapters, identity and permission held in the middle tier.

## 2. Outward — building on the Kidunaverse

**Our own API and our own MCP server.** Every action the system can perform is already a registered graph command ([Actions](actions.html)); the outward surface exposes those commands as an API and as MCP tools — so Claude Code, Codex, and any MCP-capable client can operate the parts of the Kidunaverse a member grants them. New apps, new websites, new tools, or just more features: all of it builds against the same commands the first-party products use.

**No privileged path.** Outside callers are permission-checked by the graph service exactly like internal ones: the four levels, the grants, instructions-only-from-your-own-member, structural recusal, the receipt rule — all of it holds whether the caller is our Flutter app or someone's weekend project. The one account everything needs is [kidunaverse.com](surfaces.html): third-party apps authenticate against it, and their actions trace in the same audit trail the protocol browser walks.

**Creators and Builders open doors deliberately.** Opening part of the Kidunaverse to an outside tool is a grant like any other — scoped, stated, revocable in one sentence, and disclosed where it acts.

## 3. The rule that keeps it safe

One sentence, both directions: **an integration is a tool under grants, never a party with standing.** It cannot vote, cannot hold sovereignty, cannot receive instruction-weight from anyone but the member who granted it, and everything it does is traced. If a proposed integration can't live inside that sentence, it isn't an integration — it's a membership question, and those go through [Roles](roles.html) and [Protocol](protocol.html).

---

*Changes in v5.2: the Studio↔Claude Code/Codex package-passing protocol specified; Lightbrush recorded as the first Institution integration. v5.0: track created. Full history: [versions](versions/index.html).*
