10 steps for rolling out MCP across your company

Connecting one agent to one MCP server takes a minute, but connecting every team in a company, with the right access for each person, takes some planning. These are the steps we’d follow again after rolling out MCP1 across Appwrite, in order. Most of them take minutes, except the first, which is also the one teams skip.

1. Start with the questions#

Before you install anything, ask each team which questions take them the longest to answer, and where the answers live today. Write them down, they’re the test suite for your rollout. A few of ours:

• Success: which errors did this customer hit this week, and did a deploy cause them?
• Engineering: what changed in this region in the last hour?
• DevRel: which campaigns brought the projects that are still active a month later?
• Mine: what did infrastructure cost last month, by provider?

The systems behind those questions are your first servers. Every one of them crosses at least two systems, which is where one gateway helps most. When the rollout is done, people should be able to ask them in a chat and get an answer with its sources.

2. Install servers once, for everyone#

Admins install workspace servers from the catalog or by URL. Servers that support MCP’s own OAuth, like Linear, Notion and Sentry, connect in one click: MCP1 finds their authorization server, registers itself as a client and keeps the tokens fresh. The others take a token, once, from an admin. Either way the credential is sealed in MCP1 and nobody else ever sees it, which also means nobody pastes a token into a config file again.

For servers that take a token, add a read-only secret as well. It’s a second token with read scopes only, for example a GitHub fine-grained token with read permissions. People on read-only access call with it, so the service itself refuses their writes, even if a rule in MCP1 were wrong. OAuth servers act as the account that connected them, so for those, connect with an account whose access fits. Almost every token behind our own gateway is read-only, and that’s the first thing I’d copy.

3. Mirror the way you work 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 with full or read-only access. Ours are engineering, success and devrel, plus the built-in everyone group, which every member is in and which suits the servers the whole company uses.

Once that’s in place, joining a group is the whole setup for a new person: the gateway, its servers and its tools come with it. When someone moves teams, move them between groups and their tools follow. When someone leaves, remove them from the workspace, and every client they approved and every key they made stops working.

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

Grant most gateways read-only at first. Most of the value is in reading anyway: 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.

MCP1 decides what’s read-only from the readOnlyHint annotation each server gives its tools, and a tool without one counts as a write, so a read-only grant hides it. After you install a server, open its page and check which tools are marked read-only. Some servers annotate carefully and some don’t annotate at all, and for the second kind a read-only secret is the safer way to give people access.

The Members are read-only guardrail keeps everyone with the member role on read-only tools, whatever a gateway allows. It’s a good default while you learn what each team needs.

5. Ask a human before anything destructive#

Rules by name cover whole families of tools, including tools a server adds later. Limit deletes to admins and make anything that sends a message ask first. You can set these up under Policies, or write them in the policy file:

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

An Ask first rule asks the human in their client before the call runs, through MCP elicitation, and the call waits up to 24 seconds for an answer. Clients that can’t ask are refused for these rules, which is the safe way to fail. Turn on Confirm destructive calls too, so tools marked destructive ask as well, in the clients that can.

6. Let people bring their own servers#

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. An admin can restrict a workspace server to some groups, so a personal gateway never reaches a workspace server its owner couldn’t reach anyway.

7. Connect every client to one URL#

Share the gateway’s URL. In Claude Code it’s one command:

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

The same URL works in Claude, Cursor, VS Code, ChatGPT, Codex, Windsurf and Gemini. The client’s first call gets a 401 that points it at the authorization server, the human authenticates in the browser with their own account and picks the workspace, and the client is connected. Tokens last eight hours and refresh on their own. Accounts need a verified email address to use a gateway. The docs have the steps for each client.

For CI and agents without a browser, use API keys. A key acts as the person who made it, belongs to one gateway, can be limited to some of its servers and can expire. MCP1 stores only its hash, so copy it when you create it.

Authorization: Bearer mcp1_live_…

8. Read the audit log for a few weeks#

Every call is recorded with who made it, from which client and gateway, which tool, how long it took and whether it was allowed. For the first few weeks, read the Blocked calls: they show what people need and can’t reach yet. Failed calls show servers that need attention. Usage shows which tools carry the load and who hasn’t connected at all.

When someone asks why a tool is missing, they don’t need to ask you. Their agent can call mcp1__check_access, which explains why a tool is or isn’t open to them.

9. Tune the limits#

Two settings matter once usage grows. The rate limit is 120 calls per person per minute by default, plenty for a person and their agent, and low enough to stop an agent stuck in a loop. The answer size limit trims tool answers over 1 MB and asks the model for a narrower query. We found that a smaller limit usually gives better answers, because the model isn’t reading pages of logs to find one line.

10. Keep the policy in code#

Once things settle, export the policy as YAML from Policies and keep it in a repository, next to the rest of your infrastructure. The file names things the way people do: groups by name, people by email, servers by their short name and tools as server__tool, so a diff reads like a sentence.

The import is strict. A typo fails with its place in the file, like this, and nothing is applied:

gateways.engineering.servers[1]: no server "linaer"

Preview lists every change before it applies, and each import is one entry in the audit log. Sections you leave out aren’t touched. With prune: true at the top, groups and shared gateways missing from the file are deleted, so read the preview before you apply that one.

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, and the read-only flags checked on each server
• Deletes limited to admins, and sends that ask first
• Personal gateways for the servers people bring themselves
• Every client on one URL, and keys for CI
• The audit log read weekly for the first few weeks
• The rate limit and answer size set for how your teams work
• The policy exported to a repository and reviewed like code

What’s next#

Create a workspace and start with step one. The launch post has the story of our own gateway, and How we built MCP1 on Appwrite explains what happens on each call. For every setting mentioned here, see the docs.