Skip to main content
Some clients need Pi wired into their own tools and data, through a per-org connector or an MCP server. This is how you set that up so the client’s credentials stay encrypted and scoped to their org.

​
The model

  • Connectors are per-organization. Each client’s external-service credentials live in a central encrypted keystore, never in plaintext and never shared across clients.
  • MCP servers let Pi reach a client’s tools and data through a standard protocol, per org.
  • The per-client integrations you already know (GSC, PostHog, Mixpanel) follow this model. This playbook is the general version for the other APIs and MCP servers a client brings.
Two real examples of clients who’ve needed this: Bluente, a document-translation API and MCP server, and Wonderchat, an AI-chatbot and search API. The pattern is the same each time. The client has a product API or MCP that Pi should be able to call on their behalf, and we connect it per-org.

​
Rough flow

  1. Identify the external service or tool the client needs Pi connected to.
  2. Add the connector for their org, entering the credentials (they’re encrypted at rest, scoped to the org).
  3. For an MCP server, register it for the org and verify Pi can reach it.
  4. Confirm Pi can read and act through the connection, and document what it’s for.
❓ [needs Raymond] The dedicated Notion SOP (“Playbook for API & MCP Servers”) is currently just a client-list stub (the Bluente/Wonderchat examples above) — the step-by-step isn’t written yet. So this page is the canonical starting point, not a port. Confirm the exact UI flow (where per-org MCP connectors are added, which connector types are supported today, how Pi is told to use them) so this becomes a runnable procedure. See the gap register.
Related: 2.1.4 Connect PostHog/Mixpanel · 2.1.3 Connect GSC