I Built an MCP Server for a Job a Skill Could Do

After over-building all three, here’s the one question that tells you whether to reach for a skill, a subagent, or an MCP server.

I Built an MCP Server for a Job a Skill Could Do (AI-Generated Image)

Here’s a confession to start. I spent a weekend building a Model Context Protocol server. I wrote the schema, stood up the process, wired it into Claude Code, debugged the handshake. It worked. And then it slowly dawned on me that the whole thing could have been a twelve-line text file.

That’s the trap nobody warns you about. The Claude Code ecosystem now gives you three ways to extend it: Skills, subagents, and MCP servers. Almost every guide explains what each one is.

Very few tell you the thing that actually matters: which one to reach for, and which one you’re about to over-build. I picked the heaviest tool for a feather-weight job. It cost me a weekend.

So this isn’t another “skill = X, MCP = Y” glossary. It’s the rule I wish I’d had, with the honest version of where it bites. One idea runs through all of it: reach for the lightest mechanism that solves the problem. Most people, me included, reach for the heaviest by default.

The three tools, in one breath each

You don’t need a feature tour. You need to know what each one is for and roughly what it costs you to build. So, fast:

A Skill teaches Claude how to do something. It’s a folder with a SKILL.md file: plain instructions, plus any scripts or templates the task needs. Claude loads it only when the work matches.

Anthropic shipped Skills in October 2025 and made the format an open standard two months later. The build cost is almost nothing: you write a Markdown file.

A subagent gives a task its own clean room. It’s a separate Claude instance with its own context window, its own system prompt, and its own tool permissions.

You’d spin one up so a “code reviewer” can read your files but never write to them, and so its work doesn’t clog the main conversation’s memory. These landed in Claude Code in early 2026. The build cost is still low, another config file. But you’re now managing a second brain.

An MCP server connects Claude to the outside world. Model Context Protocol is an open standard. Anthropic handed it to the Linux Foundation’s new Agentic AI Foundation in December 2025, and there are now more than 10,000 public MCP servers.

A server is how Claude reaches a live database, a SaaS API, your ticketing system. The build cost is real: it’s actual software you run, deploy, secure, and keep alive.

Notice the ladder. A skill is a note. A subagent is a coworker. A server is infrastructure. They climb in power and in what they cost to own.

The weight ladder: each step costs more to own

How I ended up on the top rung for nothing

My task was boring. I wanted Claude Code to follow our team’s release process — the exact order of steps, the changelog format, the tag naming, the little checks we always forget. Internal knowledge. A procedure.

But I’d just read three breathless posts about MCP, so MCP was the word in my head. I told myself the release process “talks to GitHub,” so surely it needed a server. I built one. A whole afternoon went to the protocol handshake alone.

The next morning I got it talking to Claude, felt clever for about an hour, then realized the ugly truth: Claude Code already reaches GitHub through the plain git and gh commands it can run. My server wasn't connecting anything new. It was just holding instructions, instructions that belonged in a SKILL.md file I could've written before lunch.

I deleted the server. I wrote the skill. It worked better, because skills load only when they’re relevant, so I wasn’t paying for that context on every unrelated request.

The lesson stuck harder than any tutorial: I’d confused “my task mentions an external tool” with “my task needs a new connection to an external tool.” They are not the same, and the gap between them is where weekends go to die.

The one question that picks the tool

Here’s the rule I use now. It’s one question, asked first, and it removes two of the three options immediately.

Does the job need Claude to reach a live external system it can’t already touch — fresh data, or an action in another app?

If yes, you need an MCP server. That’s the only one of the three that opens a new connection to the outside world. A live Postgres query, posting to a Jira board Claude has no CLI for, pulling today’s numbers from an internal API. That’s server territory, and nothing lighter will do it.

If no, you’re choosing between the two light tools, and a second question splits them:

Does the job need its own isolated context or its own tool permissions?

If yes (you want it walled off so it can’t touch certain files, or kept separate so it doesn’t flood the main chat’s memory), use a subagent. The classic case is a reviewer that may read but never write.

If no, and you’re just teaching Claude a procedure, a format, a body of know-how, use a Skill. This is the answer far more often than people expect. Most “how do I make Claude do X our way” problems are skills wearing a more complicated costume.

That’s it. Outside connection? Server. Isolation? Subagent. Otherwise? Skill. The order matters, because asking about the external connection first kills the most expensive mistake before you make it.

Two questions, in order — the first one saves you the most

The three side by side

Same idea as a table, with the build cost made honest. The “cost to own” column is the one I ignored and shouldn’t have.

One thing the table can’t show: skills, subagents, and servers aren’t rivals. A serious setup uses all three together — a skill holds the procedure, a subagent runs it in isolation, an MCP server feeds it live data. The skill is choosing wrongly between them for a single job, not picking one for your whole stack.

Where each one genuinely earns its weight

The rule tells you the default. Here’s where each tool is honestly the right call, from using all three on real work.

Skills win the routine, knowledge-shaped jobs. Your house style. A release checklist. The way your team writes commit messages. A format Claude keeps getting slightly wrong. Anything that’s “do it this way” is a skill, and because it loads only when relevant, ten skills don’t slow down unrelated work.

Subagents win when you need a wall. Two real reasons: permissions and context. A reviewer that can read but not write is safer as a subagent. A big research detour that would otherwise bury your main thread in noise is cleaner in its own context. If you’ve ever watched a long side-quest eat your conversation’s memory, that’s the pain a subagent removes.

MCP servers win when the data or action lives somewhere Claude can’t reach. This is the real thing, not a strawman. If Claude genuinely needs to read your production database, hit an internal API, or drive an app that has no command-line path, a server is correct and worth every line. The 10,000-plus public servers exist because that need is real. My mistake wasn’t using MCP. It was using it for a job that never left home.

Where my own rule gets blurry

I don’t want to sell this cleaner than it is. The rule has soft edges, and pretending it doesn’t would be the exact hype I’m trying to avoid.

The honest gray zone is the word “reach.” Claude Code can already run shell commands, so a lot of “external” work (git, file system, anything with a CLI) needs no server at all.

But if your team wants a governed, audited, reusable connection to that same system, an MCP server can still be the right call even when a raw command would technically work. The deciding factor stops being “is it possible” and becomes “do we need this to be safe and repeatable for everyone.” That’s a judgment call, not a flowchart.

And there’s a newer wrinkle worth naming: in June 2026 Anthropic added Routines to Claude Code: scheduled, cloud-run agents that fire on a trigger without your machine on.

That’s a fourth thing now, and it’s about when an agent runs, not how it’s extended. Don’t fold it into this decision. It sits on top of whatever skill, subagent, or server you already chose.

So treat the rule as a strong default that’s right most of the time, not a law. It would’ve saved me that weekend. It won’t make every call for you.

The honest takeaway

If you remember one line, make it this: the cheapest tool that solves the problem is almost always the right one, and for Claude Code that means you’re reaching for a skill far more often than the hype suggests.

Climb the ladder only when the job genuinely makes you — when you need isolation, or a connection to something Claude truly can’t touch.

I learned that backwards, by building the heavy thing first. You don’t have to.

What’s the most over-engineered setup you’ve built for something that turned out to be a one-file fix? I’ll go first — mine’s that MCP server. Tell me yours.