Skills or MCP? A Two-Layer Rule That Settles It

If you’re building your own tooling around AI agents — writing skills, wiring up MCP servers, generally trying to make a model useful against your own stuff — you run into a question early and it doesn’t have an obvious answer:

Should this be a skill, or should this be an MCP server?

Both make the model more capable. Both feel like the right answer depending on which one you built most recently. And the wrong choice isn’t catastrophic, it’s just quietly expensive — you end up maintaining a live integration for something that never changes, or copy-pasting a static document that should have been a lookup.

Here’s a rule I picked up from The New Stack, and it has held up for me since:

If the knowledge is timeless, it goes into a markdown skill first. If it requires a live connection, it goes through MCP.

That’s it. Two layers, one test.

Working the test

Timeless → skill. How your team names branches. The steps in your deployment runbook. Your brand voice. The structure of a good spec. How to interpret your own log format. None of this changes between Tuesday and Wednesday. Writing it once as a markdown document the model can read is cheap, versionable, diffable, and works even when everything else is down.

Live → MCP. What’s in the database right now. Which tickets are open. What the current build status is. Today’s calendar. Anything where a stale answer is a wrong answer needs a connection to the thing that knows, not a snapshot of what it said last month.

The failure mode of getting this backwards is instructive in both directions. Static knowledge behind a live connection is fragile for no benefit — you’ve added an integration that can break, to serve content that would have been fine as a text file. Live data written into a static document is worse, because it doesn’t break loudly. It just gets quietly wrong, and the model states it with total confidence.

The “first” in “skill first”

There’s a word in the rule doing quiet work: first.

The default should be the simpler layer. Markdown skills have almost no operational surface — nothing to authenticate, nothing to keep running, nothing to version-negotiate. If you can express something as a document, express it as a document, and reach for a live connection only when you’ve established you genuinely need current data.

I say that as someone whose instinct runs the other way. The live integration is more fun to build. It’s also the one you’ll be maintaining in a year.

Where the layers meet

The good architecture usually has both, and the seam between them is where the design gets interesting.

An MCP server hands the model current facts. A skill tells the model what those facts mean and what to do about them. Query the pipeline for current state — that’s live. How to read that state, which conditions are alarming, what the escalation path is — that’s timeless, and it belongs in a document.

Get that split right and each layer stays simple. Get it wrong and you end up with business logic buried inside an integration, which is a bad place to keep business logic in any era of software.

Why a one-sentence rule is worth having

Not because it’s subtle. Because it’s fast.

Architectural decisions that require deliberation get deliberated every single time, by whoever happens to be making them, with whatever context they happen to have. A rule you can apply in four seconds gets applied consistently — and consistency is most of what makes a system comprehensible six months later.

I’ve been doing a lot of this already, in a less articulated way. Having the sentence made it repeatable.

The projects, experience and opinions here are mine. AI helped me turn my notes and build records into this piece and polished it for Cairoglyphics.ai.