The Boundary Between MCP and Skill
Conclusion: MCP is a service; Skill is an Agent SOP orchestrator.
First, I agree that most things MCP can do, Skill can also do.
But the difference lies in what MCP can do that Skill cannot.
Examples
- Web search
- Query code on GitHub
- Fetch prototype design data from Figma
- Create a database on Supabase
The first two are technically possible locally, but not feasible in practice.
The last two are completely impossible to do locally because they involve third-party service data and authorization.
MCP is a Service — It Provides Capabilities
Web search is a service that provides real-time access to the internet. If you want your agent to search and read the latest materials, you cannot possibly set up a search engine locally.
Fetching Figma data is also a capability. But to get Figma data, you must rely on Figma’s official API. If Figma exposes its API via MCP, you can only use the capabilities provided by its MCP service.
When to Use MCP
In the current context where Skill is thriving, our need for MCP only exists for irreplaceable service capabilities.
To put it simply, MCP is just a remote API. It is only useful when you cannot handle certain requirements locally. Otherwise, we can use local Skill scripts — more controllable, more secure, and more convenient.
How to Decide: MCP or Skill
| Scenario | Choice | Reason |
|---|---|---|
| Access third-party services (Figma, Supabase, etc.) | MCP | Involves authorization and remote data; cannot be replaced locally |
| Real-time web search | MCP | Cannot set up a search engine locally |
| File processing, code inspection, text transformation | Skill | Can be done with local scripts; more controllable |
| Complex multi-step workflow orchestration | Skill | Skill naturally supports SOP workflow orchestration |
| Need MCP capabilities + local processing | Skill + MCP | Skill orchestrates the flow; MCP provides remote capabilities |
If it can be solved locally, don’t connect to the cloud.