The MCP Installation Order: Starting Safely, Expanding Deliberately

There is a mistake every non-technical founder makes in the first week of taking Model Context Protocol seriously, and it is the same mistake. Someone sends them a list of thirty MCP servers, they spend a Saturday pasting entries into Claude Desktop's config file, and by Monday they have a slower, more fragile, and less trustworthy assistant than the one they started with. The catalogue instinct is wrong. MCPs are not browser extensions to install all at once and forget about. They are permissions and tools and context tax layered on top of a model, and the order you turn them on matters more than which ones you eventually land on.

The good news is that the right order is not a matter of taste or religious debate. Every founder we have walked through a rollout ends up at roughly the same four-tier sequence, and the reasons it works are the same reasons every other staged rollout in software works. You start small, on yourself, with the least destructive powers. You expand to the team only after you have seen the tool behave for a week. You grant write access last, and you build or commission custom servers only when the public ones have shown their limits. Below is the plan, what each tier is actually for, and the two economic realities that make the sequence non-optional.

Why The Order Matters More Than The List

There is a temptation to treat MCP selection as a shopping problem. You look at the awesome-mcp list, you note which of your tools have servers, you turn them all on. The problem is that every MCP you install does three things the catalogue instinct ignores. It injects a list of tools into the system prompt at session start, which costs context-window budget before the user has typed anything. It claims permissions on a system outside Claude, which means the blast radius of a bad tool call is now your actual calendar or your actual Gmail. And it introduces a maintenance surface, because MCP servers are software that breaks, gets deprecated, and changes its schema without warning you.

None of these costs matter when you have one MCP installed. All of them compound when you have fifteen. A founder who has staged the rollout has a short, well-used list and a clear sense of which tools the team relies on. A founder who has not has a noisy system prompt, a vague sense that Claude has been slower lately, and no idea which of the ten servers they added in March is the one whose provider just stopped shipping updates. The order is what keeps the list small, vetted, and owned.

Tier One: Personal Read-Only On Your Own Machine

The first MCP you install is a read-only server on your own laptop, not the team's. For most founders the right choice is Google Workspace in read-only scopes, because inbox, calendar, and Drive are where the day actually happens. For founders who live in Notion the first tier is the Notion MCP with read access only. The rule is that the scopes you consent to in the OAuth screen must not include the words send, create, modify, or delete. Claude gets to see everything on the account it is connected to, and it gets to change nothing.

The week you spend in this tier has one job, which is to teach you what Claude does well and poorly with passive access to your data. You will notice that it is extraordinary at fishing a specific message out of a month of inbox noise and summarizing a calendar week. You will also notice that it occasionally hallucinates a meeting that did not happen or misattributes a quote to the wrong thread. Both discoveries matter, because the first tells you what the tool is for and the second tells you why you do not want it writing emails yet. By Friday of week one you should have a mental list of three or four tasks you now delegate to Claude without thinking, and a shorter list of tasks where the answer is close enough to right to be dangerous.

The reason this tier is personal and not team-wide is political as much as technical. The founder is the person with the highest tolerance for an assistant that occasionally gets something wrong, and the person with the authority to revoke an OAuth token without filing a ticket. Running the first week on your own account means you are the first person paged when something breaks, which is the correct dynamic for a policy that will eventually affect everyone.

Tier Two: Company-Wide Read-Only

Week two rolls the same server out to the team with the same read-only scopes. Nothing about the server changes. What changes is that five or twenty other people now install the MCP in their own Claude Desktop or Claude Code, consent to their own read-only scopes on their own Google or Notion accounts, and start asking Claude questions about the documents and meetings they actually own. You write a one-page internal doc that walks through the install, you pin it in the team channel, and you hold a thirty-minute office hours session on Wednesday for anyone stuck on the OAuth screen.

The point of the second tier is not to gain capability. The model does not get smarter because more people installed the same server. The point is to distribute the trust-building work across the team, so that by the end of week two there are twenty people who have seen Claude answer a real question about their real data, and twenty people who have a felt sense of what the tool is and is not for. The political work of the rollout is mostly done in this week, because the write-access decision coming in week three is much easier to make when the team has already spent five business days using read-only and has specific, unprompted opinions about what they would want Claude to do next.

Company-wide read-only is also where you start to notice the context-window tax. Not badly yet, because you are still at one server, but enough that attentive team members will ask why the first response in a session takes a beat longer than they remember. That question is useful. It is the question that keeps the list short in tier three.

Tier Three: Write Access, Starting With The Cheapest To Reverse

Week three is where Claude stops being a reader and becomes an agent. You revoke the read-only OAuth token, re-run the consent flow, and this time you check the scopes that let Claude do things. The rule for the order of write scopes is the same rule the rest of the rollout follows, which is cheapest to reverse first. Drafting a Gmail reply is cheaper to reverse than sending one, because a draft sits in the drafts folder until you click send. Creating a calendar event you can see before it notifies the attendees is cheaper to reverse than modifying a recurring series. Adding a row to a Drive spreadsheet is cheaper than deleting a column.

The practical version of this rule is that the first write scope you enable is the draft scope for email and the create scope for calendar events on your own calendar. You do not enable send, modify, or delete in the first pass. You spend three or four days watching Claude produce drafts that you approve one at a time in the Gmail interface you already know, and you keep a running note of the drafts that needed significant edits. Somewhere around day five, if the edit rate has dropped into the tolerable range for your level of risk, you enable send on replies-only and leave cold-start send disabled for another week. The read-only rule in week one was about learning what the tool sees. The cheapest-to-reverse rule in week three is about learning what the tool does with its hands.

Team rollout of write scopes lags the founder by a few days. The pattern that works is that the founder runs write scopes on their own account for half of week three, writes a one-paragraph update in the team channel about what broke and what did not, and then the team rolls forward on Thursday or Friday with the same scope list. The lag exists because write bugs are where you most want the founder to be the first person surprised.

Tier Four: Custom Servers For Internal Tools

The fourth tier is the one every founder underestimates the timeline for, which is the custom MCP server for the internal tool that has no public connector. This is the homegrown orders database, the custom admin dashboard, the Airtable that the ops team has bent into a CRM. No public MCP will ever exist for these, because the schema is yours alone. A custom server is the only way Claude ever reaches into them, and the reason this tier is last is that the blast radius is entirely your problem. A bug in the Google Workspace MCP is eventually fixed by the Google Workspace MCP maintainers. A bug in the internal orders MCP is fixed by you, at the time it breaks, which is usually Friday afternoon.

The sequencing reason for putting custom last is that by the time you reach tier four you know which internal system is actually worth the build. Three weeks of using tiered public MCPs will surface one or two pieces of internal data that you keep wishing Claude could reach, and the same three weeks will silently retire the five or six pieces of internal data that you thought you wanted connected but have not missed. Building a custom MCP on week one is building a connector for the wrong system most of the time. Building it on week four is building the one you actually use.

The Two Economies That Make The Order Non-Negotiable

Everything above can be justified on governance grounds, but there are two quieter reasons the sequence is not optional, and both of them are economic. The first is the context window. Every MCP server you install injects a tool manifest into the system prompt of every session on that machine, and tool manifests are not small. A typical server exposes between ten and thirty tools, each tool definition carries its name, description, and JSON schema, and the median tool definition lands somewhere between two hundred and six hundred tokens. Ten servers installed means twenty to forty thousand tokens of system prompt before the user asks a single question. That tax shows up as slower first responses, earlier compaction, and higher cost per turn, and as of the current generation of Claude clients there is no lazy loading that hides idle servers from the prompt. A short, well-used list beats a full shelf on pure economics before governance even enters the picture.

The second economy is the offboarding cost. Third-party MCP servers are maintained by third parties, and third parties disappear, pivot, or ship breaking changes on their own schedule. The day a server's provider shuts down, every session on every team machine that depended on that server silently loses a capability, and you inherit the fire drill of documenting which workflows broke, which entries in the config need to come out, and whether a replacement exists. The tiered rollout defends you against this precisely because the company-wide tier has been vetted the longest, which means by the time a provider vanishes you already know which of your workflows depend on the missing server and which do not. Founders who installed thirty MCPs in a weekend do not have that map, and the Friday the provider goes away is the Friday they find out.

What To Do On Monday

If you are reading this before week one of your own rollout, the action is small. Pick the single read-only server that covers the surface where you already spend most of your day, which for almost every founder means Google Workspace in read-only scopes. Install it on your own machine, give yourself five business days of using it without the team, and resist the urge to add a second MCP until the following Monday. The tiered plan works because each week is complete in itself, not because the tiers eventually stack into a catalogue. If you want a walkthrough of the rollout applied to your specific tool graph, that is the conversation our team has every week, and the arrow below is the way to start it.