Wiring file · Claude Code / MCP

MCP in Claude Code: what I wire, what I cut, what it costs.

Most MCP guides stop at "here's how to install a server." This page is what comes after: the wiring order, the real configs with their failure modes attached, the bill the tool schemas quietly add to every session, and the servers that got removed. Setup is ten minutes. The roster is the decision.

The full chapter is Ch 12 — Connectors and MCP. The security floor is Ch 9, the live rankings are Ch 24, and the ten-config deep-dive is the setup page.

Jump to section tap to open

The 30-second answer

To add an MCP server to Claude Code, declare it in a .mcp.json file at your repo root (committed, so the whole team gets the same tools), restart claude, and run /mcp to confirm it connected. Start read-only, scope each server to one resource, and audit third-party servers like npm dependencies.

— from Vlad Podoliako's Playbook, grounded in 23 MCP-wired services running three companies.

What does MCP actually do in Claude Code?

One paragraph, then we wire things. MCP — the Model Context Protocol — is the open standard Anthropic released in November 2024. Three roles: the host is the app you talk to (Claude Code, Cowork, Claude desktop), the client is the bridge inside the host that speaks the protocol, and the server is the tool — the thing that exposes Slack messages or Stripe charges or your filesystem. Same JSON-RPC contract everywhere. USB-C for AI tools: one port, every device. That's the whole definition — the dictionary entry lives in the glossary, the full taxonomy in Ch 12. This page is the Claude Code wiring.

Two naming traps before the config file. First: "connector" is the friendly UI label for an MCP server inside consumer products like Cowork and Claude.ai. When you click "Install Slack connector," you're authenticating against an MCP server someone hosts for you. Same protocol, two words, one object. Second: the transports. stdio runs the server as a local subprocess — filesystem, local databases, zero network exposure. Streamable HTTP is the modern transport for hosted SaaS servers. SSE is the legacy streaming variant — if you see it in old docs, mentally replace it; new servers should not ship SSE.

How do I add an MCP server to Claude Code?

The developer path from Ch 12, four steps. Configuration lives in a file you commit, so the whole team gets the same connector set — that's the point of the file.

1. Edit <repo>/.mcp.json at the root of your project. Commit it. A real example with two servers — local filesystem and GitHub:

{
  "mcpServers": {
    "filesystem": {
      "command": "npx",
      "args": ["-y", "@modelcontextprotocol/server-filesystem",
               "/Users/vlad/Vlad-Brain"]
    },
    "github": {
      "command": "npx",
      "args": ["-y", "@modelcontextprotocol/server-github"],
      "env": { "GITHUB_TOKEN": "github_pat_***" }
    }
  }
}

2. Restart claude in your repo. Server processes spawn on session start, not on file save.

3. Run /mcp. It lists active servers and their connection status. This is also the first stop when a connector misbehaves later — connection state before prompt archaeology (Ch 14).

4. Test in session with a low-stakes real query. List files in your vault. Open issue #42. If both return real data, you're wired. If the agent describes what it would do instead of doing it, the server isn't connected — back to /mcp.

The official docs also cover a claude mcp add CLI surface and per-scope installs. The path above is the one this book runs, because a committed file is a team contract and a CLI invocation is a local mutation.

Which MCP servers should you wire first?

If you're starting fresh, the order from the published setup: filesystem, slack, gmail, calendar — then hubspot, github, stripe — then notion, gong, ahrefs. The first four cover 80% of daily-driver use. The next three add operating context. The last three are situational — wire them only when a real workflow demands it.

The tier framing from Ch 24 says the same thing in ranking form: S tier — wire on day one — is filesystem ("your AI agent's hands"), GitHub, and Slack. A tier — week one — is your CRM, Stripe, Notion, Google Calendar, and your inbox, where read-only access is the highest-ROI connector after filesystem.

For scale: the roster that runs three companies, from Ch 12 — Belkins gets HubSpot, Slack, Google Calendar, Gmail, Gong, and Fireflies; Folderly gets Stripe and the deliverability warehouse; the Newsletter gets Notion; and Filesystem, GitHub, Vercel, Sentry, ElevenLabs, and Ahrefs run across everything. The published count: 23 wired services across 12 categories.

The rule underneath the list matters more than the list: one source of truth per category. One CRM, one inbox, one calendar, one knowledge store, one analytics suite per company. The minute you have two CRMs wired in, the agent gets confused about which is canonical — and so do you. Pick one, wire it tight, expand only when a real workflow demands it.

What do real configs look like?

Four of the ten published configs, each with the failure mode attached — because the config block is the easy half, and the gotcha is what you pay for not knowing. The full ten, with cron schedules and cross-links, live on the setup page.

filesystem

read-write

The agent's hands. Every vault read, every skill write, every plan file lands here — without it, none of the other servers compose.

{
  "mcpServers": {
    "filesystem": {
      "command": "npx",
      "args": [
        "-y",
        "@modelcontextprotocol/server-filesystem",
        "/Users/vlad/Vlad-Brain",
        "/Users/vlad/Desktop/AI Products"
      ]
    }
  }
}

The gotcha: Filesystem scope is the entire blast radius of the agent. Point it at / and an agent that goes wrong can rm-rf your laptop — point it at one vault and one project root and the worst case is a noisy git diff.

When not to wire it: Never not. But never at ~/ — always the narrowest folder the workflow actually needs.

github

read-write

Issues for triage context, commits and PR descriptions out — through scoped fine-grained tokens, never a classic PAT.

{
  "mcpServers": {
    "github": {
      "command": "npx",
      "args": ["-y", "@modelcontextprotocol/server-github"],
      "env": {
        "GITHUB_TOKEN": "github_pat_***",
        "GITHUB_ALLOWED_REPOS": "Belkins/linkagent,Belkins/folderly"
      }
    }
  }
}

The gotcha: A classic ghp_* token has org-wide blast radius — any repo you can see, the agent can touch. Fine-grained PAT, specific repos, specific permissions. Never admin:org, never delete_repo. Branch protection on main is non-negotiable.

When not to wire it: Repos with auto-deploy on push and no human review gate. Agent-writes plus auto-deploy is how production goes down on a Sunday.

stripe

read

"What was MRR last week" returns a real number, not a vibe. Read-only, full stop — billing is where a hallucinated tool call has direct cash-impact downside.

{
  "mcpServers": {
    "stripe": {
      "command": "npx",
      "args": ["-y", "@stripe/mcp-server"],
      "env": {
        "STRIPE_API_KEY": "rk_live_***",
        "STRIPE_MODE": "read-only"
      }
    }
  }
}

The gotcha: Use a restricted key (rk_live_*) with read-only scopes — never a secret key (sk_live_*). A full secret key gives the agent refund and payout authority; one bad call against sk_live_* is a real-money incident.

When not to wire it: Charges, refunds, payouts — keep them in a separate human-only surface. The agent reads; humans transact.

slack

read-write

Output channel for everything — briefings, alerts, wrap-ups. Reads channels and threads for context; writes go through a confirmation step.

{
  "mcpServers": {
    "slack": {
      "command": "npx",
      "args": ["-y", "@modelcontextprotocol/server-slack"],
      "env": {
        "SLACK_BOT_TOKEN": "xoxb-***",
        "SLACK_TEAM_ID": "T***",
        "SLACK_CHANNEL_IDS": "C0123,C0456"
      }
    }
  }
}

The gotcha: chat:write lets the agent post as the bot in any channel it's been invited to. Restrict channel membership at the Slack-admin layer, not the prompt layer — prompts are advisory, channel ACLs are enforced.

When not to wire it: Agencies and shared workspaces where one wrong message blows up client trust. Stay read-only; use a separate webhook for outbound.

How do you handle auth and secrets?

Three patterns cover the field (Ch 12). OAuth — most hosted SaaS servers: Slack, HubSpot, Google Calendar, Stripe. Consent screen, token, auto-refresh. The cleanest pattern; if a vendor offers it, take it. API key in an env var — self-hosted servers and developer tools: GitHub, ElevenLabs, Stripe in dev mode. The key lives in a local .env or the server's env block, never committed raw — if it must appear in .mcp.json, use environment-variable interpolation and keep the value in .env. No auth — local stdio servers like filesystem and sqlite, where the trust boundary is your laptop.

The mechanism that makes the env-var pattern work in Claude Code: MCP_SERVER_<NAME>_<KEY> variables get forwarded into the corresponding server process (Ch 14). That's how a secret reaches HubSpot or Stripe without ever touching the committed file.

And the floor, stated as the F tier it occupies in Ch 24: anything that asks for production credentials in plain text in .mcp.json — don't. Plain-text creds in a config file checked into git is a 2019 mistake. Rotate API keys on a ninety-day schedule, written down somewhere; OAuth refresh handles itself, keys do not.

What does running MCP servers cost?

Three meters, and only one of them is on the pricing page.

Context. Every wired server ships its tool schemas into the session — they ride your prompt prefix whether the agent calls them or not. The shape from Ch 29: a morning briefing that pulls in 40K tokens of portfolio context, MCP tool schemas, and the prior week's summary should pay full price for that prefix exactly once a week — every other morning it should be a cache hit at roughly a tenth of the input rate. The 10x gap between cache read and fresh input is the entire game, and a bloated server roster widens the prefix on every single session. That's a cost argument for the cut list below, not just a security one.

The metered backend. Some servers bill per call on the vendor's side. The published Ahrefs gotcha: a single keywords-explorer-overview call costs ~50 API units minimum, and an agent in a loop hits the monthly quota before you notice. The fix is deterministic, not behavioral — a preflight check on remaining units before any batch, as a skill, so the agent can't skip it.

The backstop. Caps catch what discipline misses. The published pattern is a daily cron reading the spend dashboard against a $380/day threshold — one Tuesday it caught a runaway swarm at $612 before lunch. The bill is a design output; the spend-side discipline lives in /the-bill and the best-practices page.

Which servers got cut — and why?

The roster above looks stable. It isn't — it's what survived. The removals are the part no vendor doc will print.

The connector that crossed a boundary. The worst receipt in Ch 28: a Gmail connector authorized against a production account inside a test workspace pulled a real customer email into the test session and surfaced it in a canvas a teammate could see. Mechanism: connectors authenticate per-account, not per-workspace — workspace boundaries are a UI fiction over a single underlying credential. The fix took 40 minutes (dedicated test account, synthetic inbox, production credentials never touch a test surface) and would have taken ten on day one. The rule it installed: the credential is the boundary, not the workspace label.

The duplicate pile. Standalone meeting transcribers got cut the day one MCP connector piped the same data into the normal AI surface — that's a line item in Ch 24's "stop paying for this" audit, and Ch 2 carries the receipt: picked Fathom, one transcript surface, MCP-wired, turned the rest off. Pick one transcriber, not three — three transcribers is one of the most common AI-bill bloats around, and the agent gets confused when the same call shows up in two systems with two summaries.

The lower tiers, so you don't relearn them. From the connector tier list in Ch 24: Salesforce's direct MCP sits at C — a heavier surface and a painful auth dance; most operators with a choice are better off on HubSpot. Discord write sits at D — it violates community ToS in most cases; read-only is fine. Community-built servers with no maintainer sit at E — supply-chain risk, read the source before installing. And plain-text production creds in .mcp.json is the F tier you already met above.

How do you not get owned?

The translation for your .mcp.json: treat third-party MCP servers like you'd treat an npm dependency in 2018 — assume nothing, audit something. The operator moves, from Ch 9:

Pin to git SHAs, not tags and not branches — tags get rewritten, branches drift, SHAs don't. Audit .mcp.json the way you audit package.json: who's the maintainer, when was the last commit, what does the server actually have access to. Don't npx a server from an author you wouldn't hire. And for teams, mirror the official registry internally — it was designed to be mirror-able for exactly this reason — and run an allow-list, not a hope.

The ledger shifted in April: MCP wiring is a supply-chain operation now, not a feature toggle. The care you take with package.json is the floor. The ceiling is treating every connector as a contractor holding your keys.

When should you write your own server?

Four triggers, from Ch 12: an internal tool has no public connector and never will; a legacy system — mainframe, ancient ERP, in-house CRM from 2009 — sits in your stack and the vendor isn't shipping MCP this decade; your warehouse has custom auth (quirky SSO, mTLS, signed JWTs) the off-the-shelf connector can't speak; or two existing connectors don't compose and a thin wrapper server gives you a cleaner tool surface.

The effort estimate operators get wrong: it's an evening. Ch 12 carries the working code — a 50-line TypeScript server exposing one tool over stdio, and the FastMCP Python version that's shorter still. Register it in .mcp.json, restart, /mcp, ask the question. After your first server, every subsequent one is twenty minutes of boilerplate plus whatever the underlying API actually requires. The tutorial stays in the chapter — no point duplicating working code that gets version-bumped there.

— the closing verdict of Ch 12 — Connectors and MCP, unchanged since it shipped.

FAQ

How do I add an MCP server to Claude Code?

Declare it in .mcp.json at the repo root, commit the file, restart claude, run /mcp to confirm it connected, then test with a low-stakes real query — "list files in my vault," "open issue #42." If both return real data, you are wired. The full walkthrough with a working two-server config is in Ch 12.

Should I commit .mcp.json?

Yes — it is the difference between "works on my machine" and every teammate getting the same tools. Secrets go in env vars via interpolation, never raw in the file; plain-text production credentials in a config checked into git is a 2019 mistake, and it sits in the F tier for a reason.

What are the best MCP servers for Claude Code?

Day one: filesystem, GitHub, Slack. Week one: your CRM, Stripe, calendar, inbox. One source of truth per category — the minute you have two CRMs wired in, the agent gets confused about which is canonical, and so do you. Read-only first; expand only when a real workflow needs write.

Are MCP servers safe to install?

Treat them like npm dependencies in 2018: assume nothing, audit something. CVE-2026-30623 put roughly 200,000 public MCP servers in scope, and nine of eleven public registries accepted a malicious test package without review. Pin installs to git SHAs, audit maintainers like you audit package.json, and run an allow-list, not a hope.

Is "claude-code-mcp" on GitHub the same thing?

No — those projects run Claude Code as an MCP server inside another agent, so a different host can call Claude Code as a tool. This page is the other direction: wiring external tools — your CRM, your filesystem, your billing — into Claude Code via .mcp.json.

Related: Ch 12 — Connectors and MCP · The full ten-config setup · MCP in the glossary · Ch 24 — the tier list · Ch 9 — don't get owned · Claude Code best practices · The cheat sheet · Start here if you're new

Stay close

The next edition lands when this list says it does.

No course. No paywall. Operator playbooks weekly. 10K+ subscribers.