Everyone is adding Model Context Protocol (MCP) servers to everything right now. And I get it. MCP is clean. It’s standardized. You write a server, expose some tools, and suddenly your LLM can query your log platform, pull a dashboard, and fire an alert. It feels like the right abstraction.
But I’ve watched teams at serious companies burn weeks building MCP integrations for workflows that should have been skills, and build skills for things that genuinely needed MCP. The confusion is costing people real time.
Here’s how I think about it.
MCP is plumbing. Skills are expertise.
An MCP server answers the question: What can the agent do?
It gives the model access to tools. It tells it to query this API. Read this dataset. Write to this system. MCP is the connection layer between an LLM and the real world. It’s a capability grant.
A skill answers a different question: How should the agent think about this class of problem?
A skill is packaged judgment. It’s the sequence of steps, the domain heuristics, the “when you see X, do Y before you do Z” reasoning that an expert would apply. Skills encode workflow. MCP encodes access.
You need both. But they’re not interchangeable, and using one where you need the other produces bad outcomes.
Where I see this break down
Take a security operations team running on a log analytics platform. They want to use AI to help with alert investigation. The instinct is to build an MCP server. Expose a tool to search logs. Expose a tool to query threat intel. Expose a tool to pull asset context. Now the LLM can “investigate” an alert.
Except it can’t. Not really.
What you’ve given the agent is access. You haven’t given it the investigation workflow. You haven’t encoded that a CSPM alert on an S3 bucket means you look at CloudTrail first, then cross-reference IAM activity in the last 24 hours, then check if the bucket is tagged as sensitive before you escalate. That’s not an MCP problem. That’s a skill problem.
An agent with MCP tools and no skill is like a new analyst who has access to every system in your environment but has never done an investigation before. They can query anything. But they don’t know what to query, in what order, or with what hypothesis.
The skill is the training. MCP is the access badge.
When you actually need MCP
You need an MCP server when the agent requires real-time access to live data or systems that it couldn’t otherwise reach.
- Querying your log platform for events in a time window
- Pulling current alert state from your SIEM
- Creating or updating a monitor programmatically
- Checking asset inventory against a live CMDB
These are tool calls. They’re stateless, they return data, they take an action. MCP is the right abstraction.
You also need MCP when you want multiple agents or multiple surfaces to share access to the same capabilities. One MCP server for your log platform. Every agent, every integration, every IDE plugin — they all talk to the same server. That’s the right use of the protocol.
When you actually need a skill
You need a skill when you’re encoding a repeatable workflow with judgment baked in, as in the examples below.
- Investigate this alert type (here’s the right sequence, here are the hypotheses to test, here’s how to structure the output).
- Parse this log format (here are the edge cases, here’s what the vendor does wrong, here’s the correct field extraction).
- Build a detection rule for this threat pattern (here’s the methodology, here’s what makes a rule noisy vs. precise).
- Do an incident retrospective (here’s what to pull, here’s how to structure the timeline, here are the questions to answer).
These aren’t tool calls. They’re workflows. The agent needs to know what to do with the tools it has — not just that the tools exist.
A skill can call MCP tools. That’s the pattern that actually works: skill provides the reasoning framework, MCP provides the data access. The skill orchestrates. MCP executes.
The test I use
When someone asks me, “Should this be a skill or an MCP server,” I ask them one question:
If a senior expert on your team was doing this manually, would the hard part be getting access to the data? Or knowing what to do with it once they had it?
If the hard part is access, you need MCP. If the hard part is judgment, you need a skill.
Most of the time, if you’re honest, the hard part is the judgment. That’s why the MCP server alone never quite works the way people expect. You gave the agent the keys. You didn’t teach it to drive.
The practical version
Stop building MCP servers for things that are actually workflow problems. Start treating skills as first-class artifacts — things you design, test, version, and improve over time, the same way you’d maintain a runbook.
Your MCP server is infrastructure. Your skills are your team’s expertise, packaged. Both matter. They’re just answers to different questions.
What’s your split right now — are you over-indexed on MCP, or have you started treating skills seriously?
More importantly, how are you controlling autonomy and tool access at the execution level?
