The Confusion We All Have
When I started working with AI agents in Claude, I made the same mistake most developers do: I thought MCP was enough.
I installed an MCP server, connected my tools (databases, APIs, file systems), and expected Claude to magically know what to do with them.
It didn't work that way.
MCP opened the doors. But something was missing that knew how to walk through them.
That something is Claude Skills.
What MCP Really Is
MCP (Model Context Protocol) is a communication protocol. Think of it as a bridge between Claude and your external systems.
When you configure an MCP server, you're saying: "Here are my tools. Claude can use them if needed."
But that's all MCP does: provides access.
It doesn't know:
- When to use each tool
- What order to execute them in
- How to handle errors or edge cases
- What the user's actual goal is
It's like having a Ferrari with a full tank but no GPS. You have power, but no direction.
Where Claude Skills Come In
Clause Skills is where you write workflow logic.
A skill is a unit of behavior that tells Claude:
1. What problem it solves (the purpose) 2. What tools it needs (MCP dependencies) 3. How to execute the flow (step-by-step logic) 4. How to handle results (what comes next)
The difference is fundamental:
- **MCP**: "I have access to a database"
- **Skill**: "I need to query the database, filter by date, transform the results, and send an email with the summary"
A Real Example: Price Monitoring
I'm building an agent that monitors competitor prices in real-time.
Without skills, the flow is chaotic:
``` Clause: "What do you need?" User: "Monitor competitor prices" Clause: *confused* "I have access to a web scraping API... should I use it?" ```
With skills, the flow is clear:
```javascript // skill-monitor-prices.ts const monitorPricesSkill = { name: "monitor_competitor_prices", description: "Monitors competitor prices and alerts on changes", dependencies: [ "mcp-scraping", // Access to web scraping tools "mcp-database", // Access to data storage "mcp-notifications" // Access to alert system ], execute: async (context) => { // 1. Scrape current prices const currentPrices = await context.tools.scrape({ urls: context.competitors, selectors: context.priceSelectors });
// 2. Compare with previous prices const previousPrices = await context.db.query( "SELECT * FROM competitor_prices ORDER BY checked_at DESC LIMIT 1" );
// 3. Detect changes const changes = detectPriceChanges(currentPrices, previousPrices);
// 4. Save to database await context.db.insert("competitor_prices", currentPrices);
// 5. Send alerts if significant changes if (changes.length > 0) { await context.tools.sendAlert({ type: "price_change", data: changes }); }
return { changes, timestamp: new Date() }; } }; ```
See the difference:
- **MCP** provides the tools (scraping, database, notifications)
- **Skill** defines the logical flow that connects them
Without the skill, Claude doesn't know it should do this in this specific order. With the skill, it's automatic.
How They Work Together in Production
In my current projects, the architecture looks like this:
``` ┌─────────────────────────────────────┐ │ Claude Agent (with claude-sdk) │ ├─────────────────────────────────────┤ │ │ │ ┌──────────────────────────────┐ │ │ │ Skills (Workflow Logic) │ │ │ │ - monitor_prices │ │ │ │ - generate_reports │ │ │ │ - handle_alerts │ │ │ └──────────────────────────────┘ │ │ ↓ │ │ ┌──────────────────────────────┐ │ │ │ MCP Servers (Tools) │ │ │ │ - Scraping API │ │ │ │ - Database Connection │ │ │ │ - Email Service │ │ │ └──────────────────────────────┘ │ │ │ └─────────────────────────────────────┘ ↓ External Systems ```
When a user asks "monitor prices", Claude:
1. Identifies that the `monitor_prices` skill exists 2. Executes the skill, which orchestrates MCP tools 3. MCP servers do the heavy lifting 4. The skill processes the results 5. Claude returns a summary to the user
Where Most Get It Wrong
I've seen developers make these mistakes:
Mistake 1: Leaving all logic in MCP
Trying to have Claude reason about which tool to use each time. Works for simple cases, but fails in production when there are multiple steps or conditions.
Mistake 2: Making skills too generic
A skill should solve a specific problem, not be a container for "everything price-related". That's fragile.
Mistake 3: Not versioning skills
Your skills will change. Version them like any other API. Allow different agents to use different versions.
How to Start
If you're building an AI agent right now:
1. Map your external tools → That's MCP 2. Define your workflows → Those are skills 3. Start with one simple skill → Monitor, report, alert 4. Iterate in public → Build and share what you learn
The combination of MCP + Skills is powerful because it separates concerns:
- MCP handles **technical connectivity**
- Skills handle **workflow intelligence**
One without the other is incomplete. Together, you build agents that scale.
Takeaway
MCP opens the doors to your systems. But Claude Skills walk through them with purpose. Don't confuse access with intelligence. You need both.
If you're building AI agents, start here: define a skill, connect it to MCP, and watch Claude automatically know what to do.
That's the difference between a tool and a system that works.
