Claude MCP in Production: Honest Review After 90 Days of 12 Servers

I ran 12 MCP servers in production across two agents (Trinity and Hermes) on my homelab for 90 days. Four made it to the end. Six got ripped out. Two are on probation. Here’s the scorecard, with the failure modes named.

TL;DR — the 4 MCP servers I still run, the 6 I killed, and why

Still running (90 days, no manual intervention):

• Playwright (LAN-only) — the most useful MCP server I’ve installed. Browser automation that just works.
• Notion — read + write to my vault, stable OAuth refresh.
• Google Drive (read-only) — file content + metadata, the read-only scope is what makes it reliable.
• Vercel — deployment status + logs, 100% uptime.

Killed:

• Ahrefs (token bloat — 4k tokens of tool definitions per turn)
• Figma (OAuth refresh dies silently every ~14 days)
• Zoom (returns stale recording state)
• Gmail (sandbox escape concern — see security section)
• HubSpot (auth flow incomplete in the official MCP server)
• Spotify (fun but useless for a production agent)

On probation:

• Linear (works but rate-limits aggressively on team workspaces)
• Google Calendar (works for read; write path has lockout under heavy use)

What MCP actually delivers in production

Model Context Protocol is the protocol; the value isn’t in the protocol, it’s in what you wire up. The promise is “any tool, any LLM, any application.” The reality after 90 days: a typed tool boundary that’s strictly better than ad-hoc HTTP calls, plus a real ecosystem of pre-built servers — but a token cost surface most people don’t measure until it’s already burning their bill.

If you want the protocol explainer, read the glossary entry. The rest of this post is what the protocol actually feels like to operate.

The setup — 12 MCP servers Trinity and Hermes ran for 90 days

Server	Use case	Days run	Status today
Playwright	Browser automation for agents	90	Keep
Ahrefs	SEO data lookup	51	Kill
Figma	Design file read/write	32	Kill
Notion	Vault sync, doc writes	90	Keep
Vercel	Deploy status, logs	90	Keep
Zoom	Meeting recordings	28	Kill
Gmail	Search threads, send	19	Kill (security)
Google Drive	File content	90	Keep
Google Calendar	Schedule lookup	90	Watch
Linear	Issue read/write	90	Watch
HubSpot	CRM lookup	12	Kill (broken)
Spotify	Music control	41	Kill (no production use)

Two agents consumed this stack: Trinity (CT 200 on the homelab, runs daily personal automations) and Hermes (CT 201, CLI + Telegram interface). Both are Claude-based with custom orchestration on top.

Production scorecard — 4 dimensions per server

Server	Uptime % (90d)	Failure mode	Token overhead	Verdict
Playwright (LAN-only)	99.8%	Browser crash, auto-recovers	1,200	Keep
Notion	99.5%	OAuth refresh occasionally hangs	2,800	Keep
Google Drive (read)	100%	None observed	1,400	Keep
Vercel	100%	None observed	900	Keep
Ahrefs	96%	Rate-limit cascades	4,100	Kill
Figma	89%	OAuth refresh dies every ~14 days	2,300	Kill
Zoom	91%	Returns stale recording state	1,800	Kill
Gmail	97%	Sandbox escape via attachments	2,600	Kill
HubSpot	71%	Auth flow incomplete	3,200	Kill
Spotify	99%	Useful for nothing production	800	Kill
Linear	94%	Rate-limit on team workspace	1,900	Watch
Google Calendar	98%	Write path lockout under load	1,200	Watch

Want the homelab agent architecture diagram + the docker-compose snippets behind Trinity and Hermes? Pick up the AI Coding Stack Decision Guide ($49) — includes the MCP server scoring rubric I used to grade these and a wiring template for Claude Code + custom agents.

The 4 winners — what made them survive

Playwright (LAN-only)

The single most useful MCP server I’ve installed. Runs as a Docker container on CT 222, exposes MCP at 192.168.31.222:8931. The reason it’s stable: it’s stateless. Every browser session starts clean, no token refresh, no cross-call state. The LAN-only scope is what removes the entire auth-failure category.

Wins: screenshot capture, form fill, navigation, JS evaluation. Source: microsoft/playwright-mcp.

Notion

Survives because the official Notion MCP server handles OAuth refresh cleanly. The 0.5% failure is the rare case where the refresh hangs on a 504 from Notion’s API — a 30-second retry resolves it. I never had to manually re-auth in 90 days.

Wins: vault sync, doc creation, search. Source: Notion’s official MCP integration.

Google Drive (read-only)

100% uptime is unusual. Two reasons: (a) read-only scope means no write-path race conditions; (b) Google’s read APIs are the most stable surface in their ecosystem. The moment you add write scope, this number drops — that’s what happened to the Google Calendar write path.

Wins: file content, metadata, recent files. Source: official Google Drive MCP.

Vercel

100% uptime, 900-token overhead — the cheapest server to run. Pure read API, no auth complexity beyond the project-scoped token. If you ship to Vercel, wire this up before anything else.

Wins: deployment status, build logs, project listing.

The 6 we killed — what failed

Ahrefs

Killed for token bloat. The MCP server registers ~40 tools, each with a verbose JSON schema. That’s 4,100 tokens added to every system prompt — for an agent that calls Ahrefs maybe 3 times per session. Replaced with a slimmer custom wrapper that exposes only the 5 tools I actually use.

Figma

Killed for OAuth refresh dying silently every ~14 days. The agent would call Figma, get a 401, retry with the same expired token, fail again. No surfaced error path; just silent loops eating my Claude budget. The official Figma MCP server has improved since, but the burn-in cost was already paid.

Zoom

Killed for stale state. The MCP server returns cached recording metadata for ~30 minutes after a meeting ends. Agents would query “what was decided in the standup” and get yesterday’s data. The cache is in Zoom’s side, not the MCP server’s, so there’s no fix from the MCP layer.

Gmail

Killed for sandbox escape concerns. Gmail attachments are arbitrary file content; if an agent fetches attachments and the MCP server doesn’t strictly scope what it returns, you have a vector for injected instructions reaching the model context. I observed this happen in a controlled test. Until the official server adds attachment-content sandboxing, I’m out.

HubSpot

Killed because the auth flow is incomplete. The OAuth handshake works for the read scope but breaks on write. 71% uptime is a generous read because most of my calls to HubSpot were writes that silently failed.

Spotify

Killed because there’s no production use case for a personal Spotify agent. Fun for a demo. Useless for revenue.

Wiring MCP into Claude Code vs custom agents

Claude Code ships with first-class MCP support. The claude mcp add command + ~/.claude/settings.json config gets you running in 60 seconds for local LAN tools (Playwright, filesystem, git). For 90% of solo workflows, this is enough.

Custom agents (Trinity / Hermes) earn their complexity when you need:

• Cross-tenant credential isolation — one agent serving multiple “personalities” with different OAuth tokens
• Custom retry policies — exponential backoff that knows your specific MCP server’s rate-limit profile
• Sub-agent orchestration — Trinity dispatches to a research sub-agent that uses a different MCP stack from the orchestration agent

If you don’t need those, don’t build them. Claude Code’s MCP is the right starting point.

The security gotchas nobody is documenting

1. Token scopes leak via tool definitions. When you wire an OAuth-scoped MCP server, the scope itself appears in the tool description that ships in your system prompt. The model can see it. A prompt-injection attack can read it. Treat every MCP server’s scope list as semi-public.

2. OAuth refresh failure modes leak refresh tokens. Two of the six I killed (Figma, HubSpot) returned full error envelopes — including refresh tokens — when auth failed. The model saw these. Fix: sandbox MCP processes, scrub error envelopes before they reach the model.

3. Sandbox escape via file content. Gmail attachments, Google Drive file content, any read API that returns arbitrary text — these are vectors for instruction injection. The MCP server has no obligation to scrub; you have to do it at the agent layer.

4. Long-lived tokens never rotate. Most MCP servers store refresh tokens locally and never rotate them. If your MCP host is compromised, the attacker has persistent access to every connected service.

5. No tenant boundary by default. MCP servers don’t know which agent or which user called them. If you run multi-tenant on top of one MCP server, you have to enforce tenancy in your agent code, not the server’s.

The fix for all five: treat MCP servers as untrusted code running with your credentials. Sandbox them, audit their network egress, redact their error envelopes, and rotate their tokens.

Related reading

• MCP — glossary entry — the protocol explainer
• Claude Code in the tool catalog — Anthropic’s MCP-first CLI
• Trinity agent — the homelab orchestration agent referenced above
• Hermes agent — the CLI/Telegram personal agent
• Langfuse for LLM observability — what I use to watch MCP token burn in real time

90 days of MCP in production taught me one thing: the protocol is right; most of the public servers aren’t ready. Pick four, audit their failure modes, sandbox their auth, and stop wiring up servers because they exist. Every MCP server is a permanent line item in your token bill and a permanent attack surface in your agent.