Skills or MCP? You're asking the wrong question
The 2026 debate frames Agent Skills and MCP servers as rivals: pick one. They're not rivals. MCPs are verbs; Skills are playbooks. The interesting systems use both, and understanding why tells you a lot about where a hosted connector layer fits.
Every few months the agent world finds a new “X vs Y” to argue about, and in 2026 it’s Agent Skills vs MCP servers. Threads pit them against each other as if adopting one means abandoning the other. The framing is wrong, and it leads teams to build the wrong thing.
Here’s the one-line version, and then the why:
MCPs are verbs. Skills are playbooks. One gives an agent the ability to act on a system; the other gives it the know-how to act well.
Two different jobs
An MCP server is a running program that speaks the Model Context Protocol. It exposes real tools and live data (a database, an internal API, a SaaS platform) that the model otherwise cannot reach. It’s a connection. It has to be running somewhere. When your task involves the words “query,” “fetch,” or “current state,” you need an MCP server, because you need to touch a live system.
An Agent Skill is a folder: a SKILL.md file, maybe some scripts and reference docs. No server, no connection. It teaches the model how to do something repeatably: a checklist, a house style, a procedure it should follow every time. A Skill can’t fetch your unread emails. It can describe, in precise terms, the right way to triage them once something else has fetched them.
The distinction that actually matters at build time:
| MCP server | Agent Skill | |
|---|---|---|
| What it is | A live server exposing tools + data | A folder of instructions + files |
| Answers | ”Do this thing in that system" | "Here’s how we do this thing” |
| Needs to run? | Yes, a process hosted somewhere | No, it’s read into context |
| Good for | Fetching, writing, current state | Procedures, style, repeatable workflows |
| Context cost | Real (tool defs are heavy) | Tiny until invoked |
The part everyone underweights: cost
The reason this isn’t a symmetric trade is context economics.
A Skill costs almost nothing to have available: on the order of a few dozen tokens of metadata until the model decides to invoke it. You can hand an agent a hundred Skills and barely move the needle.
MCP tools are the opposite: every tool definition is heavy (name, schema, field docs, examples) and by default they all load before the conversation starts. This is the whole reason deferred tools exist. So the real guidance isn’t “Skills good, MCP bad.” It’s this: reach for a Skill when you’re teaching behaviour, reach for an MCP server when you need to touch a system, and be deliberate about the MCP tools you load, because they’re the expensive ones.
The pattern that actually works: compose them
The teams getting the most out of agents in 2026 aren’t choosing. They’re layering:
- Pin one MCP server per external system you need to act on: your CRM, your inbox, your ticketing.
- Write thin Skills that orchestrate them: the playbook that says when to call which tool, in what order, with what house rules.
The Skill is the recipe; the MCP server is the pantry. “When a new lead comes in, add them to the CRM, then send a welcome email from the shared inbox, then post a note to the team channel.” That sequence is a Skill. Each of those three actions is an MCP tool call. Neither layer wants to be the other.
Where a hosted connector layer fits
This is exactly the seam FloConnector sits in, and being clear about the Skills-vs-MCP distinction is what keeps the product honest.
FloConnector is the MCP layer: the verbs. One hosted endpoint that exposes the tools of the platforms a business runs on, with managed OAuth so the AI client never sees a vendor credential, namespaced by vendor (gmail_, slack_), and gated to only what a workspace has actually connected and paid for. It’s the reliable, secure “pantry”: the live systems, safely reachable.
What it deliberately is not is your playbook. How your business handles a refund, how your replies should read, when a lead should move to the next stage: that’s yours to encode, and a Skill is the right container for it. A good connector layer makes its tools boringly predictable precisely so that the Skills you write on top of them are simple.
There’s a deeper point here. Some workflows are worth collapsing into a single composite tool: one call where FloConnector’s trusted harness makes the many underlying calls and threads the IDs. That’s a verb we author when the payoff is high. But most of the time, the better division of labour is thin, predictable tools from the connector layer, with the sequencing logic living in a Skill you own and can change without redeploying anything.
So, which one?
Both. Almost always both.
If someone tells you to pick, ask them what the task needs. “Pull this week’s new leads and draft the follow-ups in our tone” is one MCP call and one Skill, not a choice between them. The fetch is a verb. The tone is a playbook. Build each with the tool that’s actually shaped for it, and stop trying to make one do the other’s job.
Keep reading
More from the blog
Code mode needs a sandbox. Query mode doesn't.
Context engineering for MCP has two named answers: deferred loading for too many tools, code execution for too much data. Code execution buys its savings with an agent sandbox. Here's the third answer I built FloConnector on instead, why I think it's the right default, and where it loses.
What is an MCP server? A plain-English guide
An MCP server is the piece that lets an AI like Claude actually do things in your other software: read a spreadsheet, send an email, raise an invoice. Here's what that means, how it works, and why you probably shouldn't build one yourself.
How FloConnector keeps 50+ connectors out of your context window
Loading every tool a business might need costs ~72K tokens before the model reads a word. Deferred tools flip that: the model pays only for what it reaches for. How it works, why it isn't part of MCP, and what a server can actually do about its own context cost.