The connectors worth wiring first
You don't need 15 connectors. You need the few you'd query weekly, that are safe to connect, and that earn their place in the model's context.
You don't need 15 connectors. You need the few you'd query weekly, that are safe to connect, and that earn their place in the model's context. Here's the test we use to decide, the connectors that pass it for a B2B team, and the ones that are overhyped. We wired about 30. We'd start with far fewer.
- 01What MCP changesRead part 1
- 02Which connectors to wire firstThis piece
- 03Wiring write access safelyRead part 3
The listicles all push the same direction: here are 15 servers, here are 25, connect them all. We did something close to that. We wired around 30 connectors into our own stack, and that's the cautionary tale, not the model.
More connectors didn't make the assistant better. Past a point, they made it slower and more expensive, for reasons worth understanding before you wire your first one. This piece is the short list we'd start with if we began again, and the test we'd use to decide.
How many MCP connectors should you actually wire?
Fewer than the listicles say. Every connector loads its tool definitions into the model's context, so 10 servers can mean roughly 50 tool definitions competing for the model's attention. That slows answers and raises cost. Gartner expects more than 40% of agentic AI projects to be scrapped by 2027, often from exactly this kind of sprawl. Start with a handful.
Here's the mechanism the "connect everything" advice ignores. When you wire a connector, its tools don't sit quietly until called. Their definitions get loaded into the model's working context so it knows they exist. Ten servers averaging five tools each is around 50 definitions the model carries on every single question, even one that needs none of them. The context fills with options, answers slow down, and every query costs more to run.
There are mitigations. Anthropic's tool-search approach loads tool definitions on demand rather than all at once, which takes some of the sting out of a large stack. But the cleaner fix is upstream: wire fewer connectors to begin with. The sprawl Gartner is warning about, the projects that get cancelled, often starts as enthusiasm. Someone wires every connector in the directory, the system gets slow and unpredictable, nobody can say which connector earns its place, and the whole thing gets pulled.
Starting small isn't timidity. It's how the project survives to year two.
The wire-first test: four questions before you connect anything
Before you wire a tool, ask four things. Would you query it at least weekly? Is read-only enough, or is writing to it genuinely safe? Is there an official or actively maintained server? And does the value beat the context cost of loading it? Fail any one and the connector waits. Most do.
Walk the four with a real example. Take HubSpot. Would you query it weekly? Yes, most B2B teams check pipeline and contacts constantly. Is read-only enough? For asking questions, yes, and that removes most of the risk. Official or maintained? HubSpot ships an official server. Does the value beat the context cost? Easily, because it answers questions you ask all the time. HubSpot passes all four. Wire it.
Now take a niche social scheduler you touch once a month. Weekly? No. So it fails the first question, and the rest don't matter. It waits. That's the test working as intended: it's designed to keep tools out, not let them in. Most connectors you could wire, you shouldn't, and the four questions tell you which in about a minute. Call it the wire-first test.
Which connectors pass for a B2B marketing team?
For most B2B teams the same short list passes: HubSpot for CRM, GA4 plus your web analytics, Ahrefs or Semrush for search, Apollo for outbound, Notion or Drive for content, Slack and Gmail for comms, and Zapier as the catch-all. That's the core. Almost everything else can wait until it earns a place.
Group them by what they do for you:
CRM, the spine.
HubSpot was the first major CRM with a native MCP server, and for a B2B team it's the highest-value connector you'll wire. Reading is enough for most of it: pipeline questions, contact lookups, deal summaries. You don't need write access to get most of the value.
Analytics, the read layer.
GA4 ships an official, read-only server, as does Ahrefs for search. Read-only is the right posture here anyway; you query these to understand, not to change. Pair your web analytics with your search tool and most "how are we doing" questions get answered in one pass.
Outbound and content.
Apollo covers prospect search and enrichment, and unlike the analytics tools it can write, adding contacts and updating records, so it's where you start thinking carefully about access. Notion or Drive give the assistant your content and docs to read. Slack and Gmail were among the original reference servers when MCP launched, and they're how the assistant reaches into where your team actually talks.
The catch-all.
Zapier's MCP offering reaches across its roughly 8,000-app catalogue. You won't wire a dedicated connector for every tool, and you shouldn't. Zapier is how you reach the long tail without loading 40 servers into context.
Of the roughly 30 we wired, that's close to the set we'd keep if we started over. The rest were wired because we could, not because we'd query them weekly. We're describing the choices and the reasoning here, not the full permission-model setup behind each one; that config is the part we keep for client work.
Which connectors are overhyped or premature?
The loudest disappointments are the ad platforms. Google's official Ads and Analytics servers are read-only in their current releases, so "let AI run your ads" usually means a community server with no measurement context behind it, guessing at changes. Also premature: anything you'd touch monthly not weekly, and community write-servers nobody maintains.
This is where the read/write line from the first piece does real work. Someone reads "AI runs your ad campaigns," wires Google's official Ads server expecting exactly that, and finds it can only read. To get write access they reach for a community server, and now they've got an AI that can change bids but has no measurement context to decide whether it should. As SegmentStream puts it, write capability without measurement context means the AI is guessing at which changes to make.
Guessing, with your budget.
The other overhyped category is quieter: tools you'd genuinely only touch monthly. A connector for your annual-planning spreadsheet or a quarterly reporting tool fails the weekly test, so it sits in context all year for a handful of uses. And community write-servers that nobody actively maintains are a standing risk, not a feature, which the next piece gets into. The pattern across all three: impressive in a demo, a liability in a stack.
Official, community, or via Zapier: how do you choose the source?
Prefer official servers, because someone is paid to keep them working and secure. Use a maintained community server when there's no official one and the need is real. Use Zapier for the long tail you'd never wire directly. And when client data can't leave your control, host your own, which is the next piece.
The source matters as much as the tool. An official server, from HubSpot or Google or Ahrefs, has a vendor behind it with a security team, a maintenance schedule and a reason to keep it current. That's worth a lot for something holding your credentials. A community server can be excellent, Mark Harnett's LinkedIn Ads server came out of managing 65-plus real campaigns, but you're trusting a maintainer, so check it's actively kept up before you wire it to anything that matters.
Then there's the layer between. Managed platforms like Zapier and Composio sit in front of many tools and handle the auth and rate limits for you, which is how you reach the long tail without a dedicated server each. The one source we haven't covered is the one that matters most when you handle other people's data: hosting the server yourself, so credentials and data never leave your infrastructure. That's the whole of the next piece.
What does wiring these first get you in week one?
Where to start
Don't start with a list of 15. Start with the wire-first test and your own week. Which tools do you actually query weekly, is reading enough, is there a server worth trusting, and does each earn its context cost? For most B2B teams that's six or seven connectors, not 30. Wire those, prove the value, then expand only when a new tool passes the same test.
Book a call