The best talk I saw at the MCP Dev Summit in New York was Pedro Rodrigues’ session, “Skills Are Not the MCP Killer.”
If you missed Pedro’s session, it’s worth watching:
Pedro is an AI Tooling Engineer at Supabase. His talk took on the take that’s been running on Twitter for months: that Anthropic shipping Skills meant the end of MCP. It didn’t, and Pedro proved it with a live demo, a benchmark, and a model for thinking about the two that made the whole debate click.
Three things stuck with me. A security failure he reproduced live. A framing that explains why the versus debate is the wrong question. And one line about how agents actually behave that anyone deploying MCP in production needs to hear. All three connect to what we’re building at Obot, and to the themes from David Soria Parra’s keynote we covered last week.
The View That Leaked Every Team’s Data
Pedro gave Claude 4.6 a simple prompt: “Create a team task summary view so team members can see how their team is doing.” He ran it four ways. MCP only. Skill only. MCP plus skill. Neither.
In the MCP-only run, the agent had Supabase’s full toolkit, including search_docs. It ignored search_docs. It decided it knew what a Postgres view was, and it built one.
It worked. Team members could see their tasks. They could also see every other team’s tasks.
In Postgres, a view on top of a table with Row-Level Security enabled bypasses RLS by default. The fix is one flag: security_invoker. Without it, the view is a side door around the policies you wrote on the underlying table. The agent didn’t know that. The knowledge was buried somewhere in its training data, but nothing told it to check.
In the MCP-plus-skill run, the same agent used security_invoker correctly. The skill didn’t teach the agent how to write a view. It told the agent to read the docs first. The docs did the rest.
The MCP server gave the agent the capability to build the view. The skill gave it the context to build it safely.
If you’re deploying MCP behind a corporate firewall, that’s the failure mode to worry about. An autonomous agent with database write access, composing SQL from old training data, against a system you assumed was protected by RLS. Pedro reproduced it on stage.
The Pilot and the Co-pilot
After the demo, Pedro got to the framing question. The Skills-vs-MCP debate, he argued, treats two different problems as if they’re the same.
MCP solves the integration problem. How do N agents talk to M services without N×M custom integrations? Tools, resources, prompts, transport, OAuth. The whole protocol exists so any compliant agent can talk to any compliant server.
Skills solve the context saturation problem. How do you give an agent the right instructions for a task without dumping every workflow into its context window? Skills load lazily. The agent reads the description, decides if the skill is relevant, and only then pulls in the full instructions.
Pedro’s analogy: MCP is the pilot, skills are the co-pilot. You don’t fire the pilot because the co-pilot knows the route.
That clicked for me. It’s the model we’ve been moving toward at Obot for months. The protocol layer and the instruction layer aren’t substitutes, they’re complements. An MCP server without a skill is a tool with no instructions. A skill without an MCP server has nothing to act on. You need both, and in production, you need to govern both.
This framing becomes even clearer when you look at how large enterprises are deploying MCP in practice. Uber’s MCP strategy shows what it takes to operationalize the protocol at scale – standardization, lifecycle management, and governance across thousands of services – but it also highlights a key gap: integration alone isn’t enough without a strong context layer guiding how those tools are used.
Agents are Lazy
Pedro: “Agents are very lazy to go beyond their training data, and they need a push to search the web or find the right information.”
That line stuck. Most enterprise teams underestimate this. We picture agents as researchers who’ll use a search tool the moment one is available. They won’t. When the question feels familiar (what is a Postgres view?), the model falls back on what it already knows, even when what it knows is outdated or wrong for your environment.
A search_docs tool inside an MCP server isn’t enough. The agent has to be told, at the right moment, to use it. That instruction doesn’t belong in the tool description. Pedro made the point explicitly: don’t bloat your MCP tool descriptions with workflow guidance. Put it in a skill, which can hold opinionated workflows, security checklists, and product-specific patterns without polluting every tool call.
Skills and MCP servers aren’t one-to-one. A single MCP server can power many skills, with different workflows for different teams built on the same underlying capabilities. A single skill might call several MCP servers. Both have value on their own. The bigger opportunity is in how they reinforce each other. MCP servers get safer when a skill teaches the agent how to use them. Skills get more useful when they have real tools to act on.
Why We’re Expanding Obot Beyond MCP
Pedro’s talk landed on the same conclusion we’ve been moving toward for months at Obot.
We started as a control plane for MCP. Catalog, auth brokering, policy, audit. The protocol layer was where enterprise teams needed governance first. That’s still true. But governing MCP alone leaves a gap.
If agents are loading skills autonomously, and skills encode the guidance that determines whether your MCP-powered actions are safe, then skills are part of the control surface. Who can author them? Which ones are approved for production? Which agents loaded which skills against which systems? Most teams answer those questions today with shared Notion pages and copy-pasted markdown.
We’ve added a skill registry to Obot, alongside the MCP catalog. The controls we already apply to MCP servers (provenance, approval, scope, audit) now extend to skills. IT curates the registry. Developers consume from it. Security gets visibility into which skills shipped with which agent runs. Given how quickly the skill supply chain is becoming an attack surface, that visibility isn’t optional.
Obot is no longer just an MCP gateway. It’s the control plane for the agent context layer: MCPs and skills, together.
The bottleneck is context, not capability
Pedro’s thesis: the bottleneck isn’t capability. MCP is capable enough. The models are capable enough. The bottleneck is context. Getting the right instructions to the agent at the right moment so it doesn’t fall back on stale training data and ship something that bypasses your security model.
Teams that figure out skills-plus-MCP early, with governance built in, will ship safer agents faster than the teams treating skills as a separate track or as a replacement for MCP.
Skills aren’t the MCP killer. They’re what makes MCP usable in production. The control plane that governs both is where this goes next.
If you missed Pedro’s session, watch the recording here. It’s the most concrete argument I’ve seen this year for why skills and MCP belong together.
Want to see how Obot governs MCPs and skills as one control plane? Request a demo.
Meet with an Obot Architect
Get expert guidance on deploying Obot as your enterprise MCP gateway and aligning it with your infrastructure.
👉 Click here to book a time that works with your schedule.
