The short answer
If your AI workflow mainly needs instructions and context that the model should follow, a reusable agent skill will usually carry the load. If your AI workflow mainly needs to talk to an external system — pulling data, writing back, or acting under your account — you almost always need an MCP server. The trick is that the two overlap, and the overlap is where solo builders waste the most time.
This guide gives you a one-page mental model, a simple decision tree, and a few rules of thumb so you stop building infrastructure you don’t need.
Why the confusion exists in the first place
Anthropic released the Model Context Protocol in late 2024, then introduced Agent Skills about a year later. Because the same company shipped both, and because both can “connect” your AI to something external, developers assume they’re competing standards. They aren’t. They solve different problems that happen to look similar from the outside.
One way to keep them straight, borrowed from the developer community:
MCP gives your agent capabilities. Skills teach your agent workflows. Tools are the actual things it calls.
That sentence does most of the work. Everything below is just unpacking it.
What an MCP server actually does
An MCP server is a small program that exposes a set of tools — actions like “list my files,” “create an issue,” “query the database” — through a standardized protocol. Your AI host (Claude Code, ChatGPT, VS Code, Goose, and others) speaks that protocol, so any MCP server can plug into any host.
Why this matters for a solo founder:
- You get OAuth done for you. MCP has authentication baked in. The server can ask the user to log into their own account on the external service (GitHub, Notion, a CRM, your cloud account), and the user’s own credentials are used. No “paste a global API key” problem.
- One server works across many hosts. Build it once, and the same server works in Cursor today and Claude Code tomorrow. That’s the part the MCP community calls “USB-C for AI.”
- It’s the right abstraction when actions need real I/O. Reading a file from cloud storage, creating a ticket, running a query, sending a webhook — anything that touches another system with side effects.
The catch, and it’s a real one: today, many MCP servers eagerly dump the full schema of every tool they expose into the model’s context. If you connect a dozen servers, your context window fills with tool descriptions you may never use. This is the well-known “MCP context bloat” problem. It’s not inherent to the protocol — it’s how most current implementations behave — but it’s what you’ll feel.
What an agent skill actually does
An agent skill is essentially a folder of well-written instructions the model loads on demand. A skill file has a short description in a YAML frontmatter (the structured metadata block at the top of the file) that tells the model what the skill is for, and the rest of the skill is the actual playbook: a step-by-step workflow, references to other files the model can pull in if needed, and sometimes small scripts the model is allowed to run.
The clever bit is called progressive disclosure: the model only sees the skill’s name and a one-line description by default. It opens the full instructions only when it decides the skill is relevant. That keeps the context window clean.
Skills are the right abstraction when:
- The knowledge is mostly procedural. “Here’s how I want you to triage a support email.” “Here’s the house style for our changelog.” “Here’s the schema of our internal API.”
- The data lives in files you control. Style guides, runbooks, schema docs, decision logs — anything that’s “read this, then act.”
- You iterate fast. Skills are just markdown. You edit one, run the agent again, and see if it improved. The feedback loop is minutes, not weeks.
This is the reason skills feel like a bigger deal to so many developers than MCP. Writing good documentation used to be thankless work. Writing a skill that makes your own AI agent actually useful to you has an immediate payoff.
Where they genuinely overlap
Here’s where the confusion bites. A skill can include a script that calls an API. An MCP server can include prompts and resources that read like instructions. So technically, you can solve many of the same problems with either abstraction.
That overlap is real, and it has fueled the “MCP is dead” hot takes. It isn’t. What changed is that skills handle the workflow layer much better than people expected, while MCP still owns the connection layer.
A useful way to think about the boundary: if your agent needs to act as a specific user inside a third-party service, MCP is doing work skills can’t do safely. That includes anything where per-user OAuth matters — a customer using their own GitHub account, their own Notion workspace, their own cloud project.
The decision tree
Run through these questions in order. Stop at the first “yes.”
1. Does the agent need to take an action in an external system?
That action can be read-only (query a database, list issues, fetch a doc) or write-side (create, update, delete, send). If yes, you almost certainly want an MCP server. Skip to the next layer below.
If no — the work is purely “read these files and follow these instructions” — keep going.
2. Is the external system something only one developer (you) uses, and is the auth story simple?
For example, a local script that reads from your own Postgres database using a single connection string. In that case, a skill that wraps a small CLI may be enough. You don’t need the full MCP protocol, the registry, the transport options, or the OAuth dance.
If the system is shared, multi-tenant, or needs the end user’s own credentials — keep going.
3. Will you want the same capability in more than one AI host?
If the answer is “maybe later, but not now,” a skill is still fine. Skills travel well across Claude, ChatGPT, and other hosts that adopt the standard. If the answer is “definitely, and I want it to feel native everywhere,” that’s a strong signal toward MCP, because MCP’s interoperability story is its whole point.
4. Will you need to share this with non-developer teammates or customers?
This is the question that quietly forces most teams toward MCP. If your support lead or a customer needs to log into their own account on a third-party service and have the AI act on it, OAuth and the MCP transport handle that cleanly. Skills don’t have a built-in way to do per-user auth — they tend to rely on a shared API token, which doesn’t work in multi-user scenarios.
If you answered “yes” here, MCP is probably the right pick even if a skill could technically do the job.
The “don’t build both” rule
Most of the pain indie founders describe comes from building both and maintaining them in parallel. The pattern looks like this: you write a skill that documents the workflow, then you wrap the same workflow in an MCP server because you want OAuth, then the skill and the server drift apart, and nobody knows which one is the source of truth.
A simple rule prevents it:
- Pick one abstraction per capability. If the workflow is “teach the agent how to do X,” it’s a skill. If the capability is “let the agent act on X under the user’s own credentials,” it’s an MCP server.
- Don’t duplicate the same logic in both. If you find yourself maintaining a markdown file and a server endpoint that say the same thing, collapse one.
- Let skills reference MCP tools, not replace them. A skill can teach the agent when and why to use a particular MCP server. The skill is the playbook; the MCP server is the toolbox. This is the cleanest architecture and the one most current guides recommend.
A realistic founder scenario
Imagine you run a two-person SaaS. You want your AI coding assistant to do three things:
- Pull the latest customer feedback from your support inbox before drafting a release note. This is read access to an external service. If you and your co-founder both need it to use your own logins, MCP is the cleaner choice.
- Follow your house style for changelogs. This is pure instruction. It’s a skill — one markdown file with examples.
- Open a Linear ticket when the changelog mentions a bug. This is a write action in an external system, ideally tied to your team’s Linear accounts. MCP again, with the skill telling the agent when to trigger it.
That’s two MCP touchpoints and one skill, not three of either. The architecture matches the actual job.
Trade-offs to keep in mind
Context cost. MCP servers can inflate your context window if you connect too many at once. Some hosts lazy-load tools now, but don’t assume it. Skills only consume context when they’re triggered, which is gentler by default.
Maintenance. An MCP server is a service. It has a deploy story, a version story, and an auth story. A skill is a folder of markdown. Skills are dramatically cheaper to maintain — and to rewrite when the underlying workflow changes.
Discovery. The MCP registry gives you a centralized place to find servers other people have already built. For skills, discovery is still fragmented; you’ll mostly find them inside the apps that support them or in project repos.
Vendor support. MCP has wide industry backing — OpenAI, Google, Microsoft, AWS, and others have shipped support. Skills are newer and the support footprint is narrower, though growing. If your toolchain spans multiple vendors, weigh that.
Tool description quality. A well-known problem with MCP today is that tool descriptions in many public servers are vague, redundant, or missing key fields. Bad descriptions mislead the model into picking the wrong tool or passing bad arguments. This is a real friction point; it’s one of the reasons skills feel more predictable for many workflows.
FAQ
Can a skill call an MCP server?
Yes. A common pattern is to write a skill that tells the model which MCP server to use and in what situation. The skill provides the judgment; the MCP server provides the action.
Do I need MCP if I’m only using one AI host?
Not necessarily. If you’re sure you’ll stay inside a single tool and your workflow is mostly instructions, skills may be all you need. The strongest argument for MCP is interoperability and per-user auth.
Is MCP going away?
No credible reading of the current ecosystem supports that. Skills complement MCP rather than replace it. If anything, MCP support has widened across major vendors since skills launched.
How do I start without overbuilding?
Begin with a skill. If the workflow needs real actions in an external system under real user accounts, graduate the capability to a server while keeping the skill as the playbook that decides when to call it.
A simple checklist before you build
- Write down the actual job in one sentence.
- Mark whether it’s “instruct the model” or “act on an external system.”
- Mark whether it needs per-user auth.
- Mark whether more than one host or team member needs it.
- Pick one abstraction based on the answers.
- Resist the urge to also build the other “just in case.”
That’s the whole framework. The cost of choosing well here isn’t theoretical — it’s the difference between an afternoon of editing markdown and a sprint of standing up a service you didn’t need.
Sources
- Agent skills vs Model Context Protocol — How do you choose? (ravichaganti.com)
- Tools, Skills, and MCP — When to Use Which Without the Headache (dailyaistudio.substack.com)
- MCP servers vs. skills: Choosing the right context for your AI (Red Hat Developer)
- MCP is dead, or MCP vs Skills — revisited (Alon Nisser, Medium)
- Hacker News discussion: Claude Skills are awesome, maybe a bigger deal than MCP
