Topic starter
25/10/2026 11:01 am
TL;DR: Teams that design MCPs around API endpoints rather than user jobs end up with broad capability and poor usability, according to Willow. MCP governance works better when access is framed around workflow fit and task review instead of endpoint counts.
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: 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.
Q: How should teams design MCP tools around user workflows?
A: Start from the user job, not the API catalog.
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.
Glossary terms: Model Context Protocol, Workflow-oriented MCP, Tool Sprawl
Explore further
View Full Forum → | NHI Foundation Course → | Our Services → | Read the full analysis →
This topic was modified 7 days ago by NHI Mgmt Group
27/10/2026 7:15 pm
Capability sprawl is a governance problem, not just a UX problem. When teams expose every endpoint because it is technically available, they create an access model that is hard to explain, review, or constrain. The issue is not simply that users dislike the interface. It is that broad tool exposure makes it harder to justify why an agent needs each capability, which weakens both least-privilege thinking and operational oversight. Practitioners should treat endpoint proliferation as an identity and access design smell, not a product detail.
A few things that frame the scale:
- 24,008 unique secrets were exposed in MCP configuration files in 2025 alone, the protocol's first year of widespread adoption, according to the State of Secrets Sprawl 2026.
A question worth separating out:
Q: What is the difference between a tool catalog and a workflow-oriented MCP?
A: A tool catalog lists what the backend can do, while a workflow-oriented MCP exposes only the actions that help complete a specific job. The first maximises coverage, but the second maximises usability and governance. For practitioners, the difference shows up in how clearly access can be justified and reviewed.
👉 Read our full editorial: MCP success depends on job design, not endpoint completeness
This post was modified 7 days ago by NHI Mgmt Group