Nick Perkins

Software Engineer. Volunteer Motorsport Official. ADHD Brain. Bit of a nerd.

I Was Wrong About MCPs

In June I wrote about replacing MCPs with skills and scripts, and about a skill file beating an MCP server almost everywhere except where there’s no CLI. I still work that way. The conclusion I drew from it, that MCP servers are on the way out, was wrong.

The context tax turned out to be fixable

My complaint was concrete. Load an MCP server and every tool definition goes into the context window, whether the agent uses it or not. The Atlassian MCP alone put dozens of schemas in front of the model before I’d asked it for anything. That part is still true.

What I missed is that the fix landed in the client. Tool search, also called progressive discovery, keeps a lightweight index of tool names and descriptions and loads the full schema only when the agent decides it wants one. Anthropic’s numbers from shipping it: a five server setup came to 58 tools and about 55,000 tokens of definitions before the model read the request. With tool search on, tool-definition tokens dropped around 85 per cent.

The part I didn’t expect is that tool selection got more accurate, not less. On Anthropic’s internal MCP evals, Opus 4 went from 49 per cent to 74 per cent. Hand a model 58 tools at once and it chooses worse than when it searches and loads three. In Claude Code it’s on by default now, switching over once tool descriptions pass roughly 10 per cent of the context window.

Atlassian stopped handing me the whole catalogue

Server design caught up too. The Rovo MCP server doesn’t pass the full tool list to the client any more. It advertises a small set of primary tools, and the rest of the catalogue is found at runtime by describing what you’re trying to do to the discover tool. Execution runs through executeRead, executeWrite or executeDestructive by risk tier, and new tools show up without reconnecting.

My Jira and Confluence skills are hand-written lists of API calls: which endpoint does what, what a valid JQL filter looks like. Every time Atlassian adds a capability I have to notice and update the skill. Now the agent asks the server what it can do. I was doing tool discovery manually and calling it workflow design.

My advice only worked if you have a shell

This is the bit I’m annoyed at myself about. Everything in that post quietly assumed a developer with a terminal, a script, and an API token sitting in an environment variable. Skill file, script, done.

Most people using AI tools at work can’t write that script, and shouldn’t have to. Someone in marketing who wants a summary of what shipped in Jira this sprint isn’t going to build a Python wrapper around the REST API. They add a connector, sign in with OAuth, toggle it on for the conversation, and ask. They only see what they already had access to, because connectors inherit the user’s permissions instead of running as a service account.

That’s citizen AI, and it’s the use case that settled this for me. Telling a non-developer to call the API themselves isn’t advice, it’s a wall.

A personal access token pasted into a script by every person who wants AI help in Jira is a mess at any scale. Per-user OAuth and admin-controlled permission groups are how you ship this across an organisation without handing out credentials. MCP got that right before it got the context problem right.

Skills still own the workflow

I stand by the useful half of the original post. An MCP server can give you a create-page tool. It can’t tell the agent to check which epics closed this week, look for risk discussions in the comments, and draft the update in your format. That’s sequence and judgement, and it belongs in a skill.

So it isn’t skills against MCPs. MCP is access, skills are process. If you’re a developer with a CLI, a script is often still the lighter way to call something. That hasn’t changed either.

The bottom line

MCPs weren’t dying. They were missing the half that makes them usable at scale. It arrived faster than I expected: schemas deferred in the client, discovery moved to the server, per-user auth instead of one shared token.

It isn’t finished. Tool search adds a round trip, and it gets shakier once you’re dealing with thousands of tools rather than dozens. Third-party testing shows accuracy dropping off again out there. The range most people work in is where it’s strongest now.

The June post describes my desk accurately. It doesn’t describe how most people will connect an AI to their work, and I wrote that gap into it as if it wasn’t there. Next time I’ll ask whether the advice only works for someone who already has a shell.

Thanks for reading. I'm Nick, and this is my personal blog. If you got something out of this, there's more where it came from.

Browse the archive →