The second wave of MCP: Building for LLMs, not developers
By Steven Van ·
Vercel's guide argues MCP servers should expose single workflow tools, like one deploy_project call, instead of chaining separate API endpoints.
Vercel has published a guide arguing that most early MCP servers were built the wrong way: as thin wrappers around individual API operations, which suits how developers work but not how LLMs work. A developer writes the orchestration once and reuses it, keeping track of IDs and state between calls. An LLM starts every conversation fresh, so with low-level API wrappers it has to rediscover and re-run the same sequence each time, often getting nested configurations or required fields wrong.
Vercel's recommendation, laid out in its announcement, is to design MCP tools around complete user intentions rather than API endpoints. Its example: instead of four separate tools (create_project, add_environment_variables, create_deployment, add_domain) that an LLM must call in order while passing project IDs between them, expose one deploy_project tool that handles the whole workflow internally and returns a conversational result, such as "Project deployed at example.com. Build completed in 45s," instead of a raw status code.
Its suggested process for building these tools:
- Walk through a real user request manually with the existing APIs first, and turn the tedious or repetitive steps into a single tool
- Keep deterministic work, such as API sequencing, error recovery and state management, in plain code, and only involve the LLM for parts that need reasoning or natural language
- Test with real user workflows: an LLM making repeated attempts or asking for clarification is a sign the tool design needs to change
Vercel points teams building MCP servers on its platform to its Next.js MCP template and documentation to get started.
