MCP workflows: what matters more than exposing every tool?

TL;DR: Technically complete MCPs often fail because teams design around API endpoints instead of the jobs users are trying to complete, which leaves agents with broad capability but poor usability, according to Willow. The practical implication is that MCP governance should start with workflow fit, tool framing, and user context, not endpoint inventory alone.

Editorial analysis by NHI Mgmt Group, based on content published by Willow: “Before You Build Your Next MCP: Think Like a PM”.

Key questions

Q: How should teams design MCP tools around user workflows?

A: Start from the user job, not the API catalog.

Q: Why do technically complete MCPs still fail in practice?

A: Because completeness does not equal usability.

Q: What breaks when MCP design starts with capabilities instead of jobs?

A: The workflow breaks into disconnected actions that the agent has to infer on the fly.

Practitioner guidance

• Define jobs before tools Interview users and map the specific outcomes they want an MCP to support before exposing any endpoints or resources.
• Collapse endpoint sprawl into task-based tools Group related API actions into fewer, outcome-oriented tools so the agent sees a workflow instead of a raw capability list.
• Test the workflow in the real interface Validate each MCP against the actual entry point the user will use, such as a chat surface or coding assistant, because context changes what usable access looks like.

Bottom line: MCPs fail when teams equate API completeness with usable access and build around endpoints instead of tasks.

Explore further

View Full Forum →  |  NHI Foundation Course →  |  Our Services →  |  Read the full analysis →