Six months into the MCP (Model Context Protocol) boom, we’re making old mistakes. Everyone is chasing what’s possible instead of asking what works.
Most MCP projects today simply wrap existing APIs and call that “integration.” But that’s not enough. The real challenge isn’t exposing endpoints, it’s designing experiences that make AI workflows natural, safe, and useful.
The API-Wrapper Trap
Here’s what I see too often:
- Teams convert OpenAPI specs into MCP endpoints.
- They assume AI agents can just pick the right tool.
- But that fails when tools overlap, or when the AI has to reason across pagination, permissions, or sequential steps.
Example: A user asks, “Find all failed logins from suspicious IPs.” A basic server might expose list_logs() and get_log(). The AI then has to manage filtering, correlation, and edge cases. That’s brittle, because those APIs were designed for developers, not for AI reasoning. And it risks leaking more than permissions allow.
From POC to Product
The real opportunity is workflow-first, not API-first design.
- Start with what users want to do: “investigate security incident,” “set up auth for my project,” “prepare a branch for review.”
- Encode domain knowledge and safe defaults directly into the tools.
- Support workflows that align with real jobs-to-be-done, not just raw calls.
When I built an Auth0 MCP server, I started by wrapping APIs. But actual users wanted something else: higher-level tasks like “set up auth quickly.” That’s when the demo became a product.
What Matters Going Forward
- Winning MCP servers won’t be the ones with the most endpoints. They’ll be the ones with the clearest workflows.
- Product thinking matters: guardrails, context passing, domain expertise.
- Security isn’t optional — it’s foundational.
MCP isn’t just a protocol. It’s a new frontier in product design. If you build wrappers, you’ll miss the point. If you build bridges between human intent and AI action, you’ll shape the future.