A playbook for rolling out MCP to your whole company

Connecting one agent to one MCP server takes a minute. Connecting every team’s agents to the systems they need, safely, is a different job. This is the order we’d do it in, from what we learned rolling out MCP1 across Appwrite.

1. Start with the questions, not the servers#

Before installing anything, ask each team which questions take them longest to answer, and where the answers live. Support’s are usually about a customer: their account, their errors, their history. Engineering’s are about a change: what shipped, what broke, what it costs.

The systems behind those questions are your first servers. The questions themselves are how you’ll know the rollout worked.

2. Install servers once, for everyone#

Admins install workspace servers from the catalog or by URL. Servers with OAuth, like Linear, Notion and Sentry, authenticate in one click; the rest take a token, once. MCP1 keeps the tokens sealed and refreshes them, so nobody pastes a token into a config file again, and nobody ever sees a workspace server’s token.

Where a service allows it, add a read-only secret too: a second token with read scopes only. Humans on read-only access call with it, so the service itself refuses their writes, even if a rule in MCP1 were wrong.

3. Mirror your org chart with groups#

Make a group for each team that works with the same systems, make a shared gateway for it, and grant the gateway to the group. Joining the group becomes the whole setup: the servers, the tools and the access come with it.

• Engineering: code, errors, metrics and your clouds, with full access.
• Support: the help desk, product data and errors, read-only.
• Growth: analytics, email and ads, read-only.

Move someone to another team and their tools move with them.

4. Start read-only, and open writes on purpose#

Grant most gateways read-only at first. Read-only is where most of the value is: finding things, matching them across systems and explaining them. Then open writes one tool at a time, for the groups that need them, with a minimum role where it matters.

The Members are read-only guardrail holds members to read-only tools everywhere, whatever a gateway allows. It’s a good default while you learn what each team needs.

5. Put a human in front of anything destructive#

Rules by name cover whole families of tools, including ones a server adds later. Hold deletes to admins, and make anything that sends a message ask first: the human approves the call in their client before it runs.

rules:
  - pattern: "*__delete_*"
    minRole: admin
  - pattern: "*__send_*"
    confirm: true

Turn on Confirm destructive calls as well, so every destructive tool asks first, in clients that can ask.

6. Let people bring their own#

Not everything belongs to the company. Personal gateways let anyone add their own servers with their own tokens, next to the workspace servers their groups can use. Nobody else can use a personal server’s token, and a personal gateway never reaches a workspace server its owner’s groups can’t.

7. Connect every client in a minute#

Share the gateway’s URL. Each human adds it to their client and authenticates in the browser with their own account, picking the workspace on the consent screen.

claude mcp add --transport http mcp1 https://mcp1.com/mcp/<workspace>/<gateway>

The same URL works in Claude, Cursor, VS Code, ChatGPT, Codex and any client that speaks remote MCP. For CI and agents without a browser, make an API key: it acts as the human who made it, belongs to one gateway and can expire. The docs have the steps for each client.

8. Read the audit log, then tune#

For the first few weeks, read the audit log. Blocked calls show what people need and can’t reach yet. Failed calls show servers that need attention. Usage shows which tools carry the load. Open access where the blocks make sense, and tighten it where something is called more than it should be.

When someone asks why a tool is missing, their agent can answer: mcp1__check_access explains why a tool is or isn’t open to them.

9. Keep the policy in code#

Once it settles, export the policy as YAML from Settings → Policies and keep it in a repository. Changes go through review like code, a preview lists every change before it applies, and each import is one entry in the audit log.

10. Make offboarding one step#

Remove someone from the workspace and every client they approved and every key they made stops working. No token hunt, and no shared secrets to rotate.

The checklist#

• Each team’s slowest questions, written down
• Workspace servers installed once, with read-only secrets where possible
• A group and a shared gateway for each team
• Read-only grants first, writes opened tool by tool
• Deletes held to admins, and sends that ask first
• Every client on one URL, and keys for CI
• The audit log read weekly, and the policy in a repository