What you'll learn: Why MCPs become expensive and unreliable at team scale, the real token cost difference ($540/mo vs $90/mo for a 5-PM team), and how API skills solve every problem MCPs create.
Three months ago, I connected Claude Code to everything. Linear, Slack, GitHub, PostHog, Notion, HubSpot — all via MCP. The demos were incredible. Ask Claude to pull sprint data, search Slack history, create Jira tickets — all from the terminal.
Then I scaled it to a team. And the cracks showed fast.
MCPs are the default integration path for Claude Code right now. Every tool is shipping an MCP server. The community is excited. But nobody's talking about what happens when you move from one PM experimenting to five PMs running production workflows daily.
I ripped out every MCP and replaced them with API skills. Here's why — with real numbers.
The Token Tax Nobody Mentions
Every MCP server you connect registers its tools in Claude's context window. Even with deferred loading — where tool names appear without full schemas until invoked — 60-80 MCP tools add roughly 6,000 tokens of overhead per turn.
That's 6,000 tokens Claude processes every single interaction, whether you use those tools or not.
Here's how it adds up for a 5-PM team on Opus:
- 6,000 tokens/turn in tool listings
- ~30 turns per average session
- ~40 sessions/month per PM
- 5 PMs on the team
- That's ~36 million tokens/month just in tool overhead
- At $15 per million input tokens: ~$540/month
API skills don't register anything in the context window. They're called on demand — a direct HTTP request when the skill runs. No schema overhead. No tool listings. No ambient token cost.
The same team running API skills instead of MCPs: ~$90/month in overhead. That's 6x cheaper, saving $5,400/year — enough for five Claude Max subscriptions.
Key takeaway: MCPs charge you tokens for every tool you could use, every turn, whether you use them or not. API skills charge you only for the calls you actually make.
Double the Failure Points
An MCP integration adds a second system between your PM and the result: the MCP server itself. Your request hits Claude, Claude calls the MCP server, the MCP server calls the API, and the result comes back through the same chain.
When the MCP server drops a connection, times out, or returns a vague error, your PM spends 20 minutes debugging something that isn't their workflow — it's the middleware.
API skills are one call. Claude makes an HTTP request directly to the endpoint. One failure point. One thing to debug. When something breaks, the error is clear and the fix is obvious.
This matters most in the middle of a workflow. A PM is running a competitive analysis that chains three data sources. If the second MCP connection drops, they lose the work from the first call and start over. With API skills, each call is independent and retryable.
Coverage Gaps Are Real
Not every tool your team uses has an MCP server built for it. The MCP ecosystem is growing, but it's still concentrated around popular developer tools — GitHub, Linear, Slack, Notion.
Your team's internal API? No MCP. That niche analytics platform your data team picked? No MCP. The legacy CRM your sales team won't give up? Definitely no MCP.
But they all have HTTP endpoints.
API skills work with anything that exposes an API. You write the skill once — define the endpoint, the auth, the payload shape — and it works. No waiting for someone to build and maintain an MCP server. No dependency on a third party's update schedule.
The Per-PM Installation Tax
This is the one that kills adoption at team scale.
Every MCP connection requires per-PM setup. Each PM on your team configures the MCP server, sets up authentication, manages tokens, and maintains the connection in their local environment. For one PM, that's a 15-minute setup. For five PMs across six integrations, that's 30 separate configurations to maintain.
When an MCP server updates its API, every PM needs to update their local config. When auth tokens expire, each PM handles it individually. When a new PM joins the team, they spend their first hour connecting integrations instead of doing PM work.
API skills ship once inside your PM operating system. Every PM gets them instantly. One configuration, one auth setup, one maintenance surface. A new PM clones the repo, runs /welcome, and has access to every integration the team uses.
Practical tip: If you're evaluating MCPs vs API skills for your team, start by counting how many integrations each PM needs. Multiply by the number of PMs. That's your installation tax. If it's more than 10 total configurations, API skills will save you hours of setup and ongoing maintenance.
When MCPs Still Make Sense
MCPs aren't bad. They're great for a specific use case: individual exploration.
If you're a solo PM trying Claude Code for the first time, connecting an MCP to Linear takes five minutes and instantly shows you what's possible. That fast feedback loop is genuinely valuable. MCPs lower the barrier to getting started.
The problems emerge at scale:
- Solo PM, exploring → MCPs are fine. Fast setup, quick payoff.
- Team of 3+, running daily → API skills. The token savings and reliability compound.
- Production workflows that chain tools → API skills. You need predictable, independent calls.
The transition is straightforward. Every MCP call maps to an API call — the MCP server is just middleware wrapping the same HTTP endpoint you'd call directly.
Making the Switch
If you're running MCPs today and want to migrate to API skills, here's the practical path:
1. Audit your MCP usage. Which integrations do your PMs actually use daily? Most teams find they actively use 3-4 out of 8-10 connected MCPs. Start with those.
2. Build the API skill. Each skill is a SKILL.md file that defines the endpoint, authentication, and output format. Any PM with API access can convert an MCP integration to an API skill in 30 minutes.
3. Ship it to the team. Drop the skill into your PM OS /skills directory. Every PM gets it on next pull. No per-seat configuration.
4. Remove the MCP. Once the API skill is running, disconnect the MCP server. Watch your token costs drop immediately.
Bottom line: MCPs are training wheels. They're great for getting started, and there's no shame in using them to explore what's possible. But when you're ready to run a PM operating system for a real team, API skills are how production teams ship.
Running a PM team on Claude Code? The PM Operating System ships with 70+ API skills — including integrations for Linear, Slack, PostHog, and more. No MCPs required.