The second wave of MCP: Building for LLMs, not developers
MCP servers are failing because they're built for developers, not LLMs. Here's why the next wave changes everything.
Why it matters
MCP adoption is shifting from API-wrapper-first to LLM-native tool design. Teams that build for agent reasoning patterns—not developer workflows—will see better adoption and model performance.
The key facts
10 to knowFirst wave MCP servers were thin API wrappers with minimal changes
LLMs don't reuse past code or maintain long-term state—each conversation is fresh
Low-level API wrappers cause repeated orchestration, inconsistent LLM behavior, wasted inference
Best practice: one tool handling complete user intentions beats four tools splitting pipeline steps
Strategic insight: MCP adoption requires rethinking tool design for agent reasoning, not developer ergonomics
MCP standard adoption pattern: initial wave focused on API-wrapper parity, not LLM-optimized design
LLMs lack state persistence and code reuse between conversations; each conversation requires tool rediscovery
Thin API wrappers create friction: repeated orchestration, inconsistent behavior, redundant problem-solving
Design principle shift: MCP tools should expose complete user intentions (e.g., deploy end-to-end) rather than individual API operations
Published by Vercel—major infrastructure/AI platform provider, credible source on developer tooling and LLM integration patterns
Go to the source
Vercel Blogvercel.com
Publisher excerpt: When the MCP standard first launched, many teams rushed to ship something. Many servers ended up as thin wrappers around existing APIs with minimal changes. A quick way to say "we support MCP". At the time, this made sense. MCP was new, teams wanted to get something out quickly, and the obvious…
