Do We Still Need MCP Servers in the Era of Skills and Coworkers?
MCP servers had a massive moment in late 2025. Now with Claude Skills and AI Coworkers, are they still worth building?
If you were paying attention to the AI tooling space in Q4 2025, you couldn't scroll for five minutes without seeing a new MCP server. GitHub, Slack, Postgres, Jira, your local filesystem — there was an MCP server for all of it. Developers were excited, and rightfully so. The Model Context Protocol gave AI models a standardized way to reach out and touch the world.
Then Skills dropped. Then the idea of AI Coworkers started taking shape. And quietly, the question crept in: do we still need MCP servers?
What MCP Actually Solved
Before you can answer whether MCP is obsolete, you have to be honest about what problem it solved.
LLMs, on their own, are stateless and isolated. They have no persistent memory, no live access to your systems, and no way to take action in the world. MCP was the bridge — a protocol that let a model say "I need to query this database" or "run this shell command" and have it actually happen, in a structured, auditable way.
The explosion of MCP servers wasn't noise. It was developers realizing that context is the bottleneck, not intelligence. Give a capable model the right context and the right tools, and it does remarkable things. MCP made that possible in a composable, open way.
What Skills Change
Skills are different. Instead of exposing raw capabilities through a protocol, Skills package up intent — a pre-built, opinionated behavior that the model knows how to invoke. Think of it like the difference between handing someone a Swiss Army knife versus handing them a pre-written playbook for a specific job.
A /commit skill doesn't just expose git — it encodes the whole workflow: check status, review the diff, draft a message that matches the repo's style, confirm before pushing. You don't configure it. You invoke it.
For common, well-understood tasks, Skills are strictly better than MCP. They're faster to adopt, require no server to spin up or maintain, and they carry institutional knowledge baked in. If MCP servers were npm packages, Skills are the curated standard library.
What Coworkers Change
The Coworker model is a bigger shift. Instead of a single model with tools attached, you have autonomous agents that coordinate — delegating tasks, running in parallel, handing off context between specialized subagents.
This changes where the complexity lives. With MCP, you think about which tools to expose. With Coworkers, you think about which agents to compose and how they hand work to each other. A Coworker doesn't need an MCP server to query your Snowflake warehouse — it can delegate to a data agent that already has that capability wired in.
In theory, this means a lot of MCP servers that existed to connect one model to one tool become redundant. If the agent ecosystem already includes a capable data agent, a web-browsing agent, a code execution agent — you're not building integrations anymore, you're orchestrating agents.
The Case for MCP Surviving
Here's the honest counter-argument: Skills and Coworkers don't cover your proprietary systems.
Your internal ERP has no Skill. Your custom deployment pipeline isn't an available Coworker. Your on-prem data lake, your legacy SOAP APIs, your compliance-restricted environments — none of these will ever have a first-party agent that understands them. MCP remains the right answer anywhere you need a custom integration layer.
The protocol also matters for enterprises that care about auditability. MCP servers can be versioned, logged, and governed independently of the model calling them. You control what capabilities are exposed and to which agents. That's not a small thing in regulated industries.
There's also the ecosystem angle. MCP is open. Any model can call an MCP server — not just Claude. If you invest in building an MCP server for your internal tools, that investment works with whatever model your organization standardizes on next year. Skills are model-specific and runtime-specific. MCP is infrastructure.
A Mental Model That Actually Helps
Think of it this way:
You wouldn't say Salesforce made middleware obsolete. You'd say it eliminated the need to build some middleware. The same logic applies here.
Where I Land
The era of "build an MCP server for everything" is probably over. In the same way the cloud didn't kill on-prem but it did clarify where on-prem is actually justified, Skills and Coworkers will clarify where MCP is actually necessary.
If you're building an MCP server for something that already has a Skill or a well-supported agent — stop. You're doing redundant work. But if you're connecting AI to something internal, regulated, proprietary, or just not covered by the ecosystem yet, MCP is still the right tool and likely will be for a long time.
The hype wave is over. What's left is the genuine use case. That's usually when things get interesting.
---
Questions or pushback? Drop a comment below.
Naveen Davuluri
Director, AI & Applications