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.
At a glance
What this is: This blog argues that MCP design should start with user jobs and workflow context rather than exposing every API endpoint as a tool.
Why it matters: That matters because identity and access design for AI agents works better when tools are mapped to real tasks, not when capability sprawl is mistaken for usable governance.
Context
MCP adoption often starts with a capability-first mindset, but the security and governance problem appears when teams treat exposed tools as the same thing as usable access. If the agent cannot reliably understand the workflow, organisations end up with technically reachable functions that are difficult to govern, monitor, or justify.
For AI agent programmes, the practical question is not how many endpoints can be surfaced, but which jobs should be exposed through MCP security patterns and which should stay out of the tool layer altogether.
Key questions
Q: How should teams design MCP tools around user workflows?
A: Start from the user job, not the API catalog. Group endpoints into a small number of outcome-based tools, validate them in the interface where the agent will operate, and remove functions that do not map to a clear task. That makes the MCP easier to use, easier to govern, and less likely to become an unreviewed capability dump.
Q: Why do technically complete MCPs still fail in practice?
A: Because completeness does not equal usability. An MCP can expose every available endpoint and still fail if the agent cannot understand which tools matter for the user’s actual goal, how they connect, or when they should be used. The result is weak adoption, noisy governance, and broader access than the workflow requires.
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. That usually means more ambiguity, more misuse, and more permissions than necessary, because the tool layer mirrors system structure instead of operational intent. Teams then have to govern a capability catalog rather than a manageable set of business tasks.
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.
Technical breakdown
Why endpoint completeness does not produce usable agent workflows
MCPs expose tools, prompts, and resources, but the presence of an endpoint does not mean the agent can use it in a meaningful sequence. The article’s core point is that a tool catalog mirrors backend structure, while users think in jobs, outcomes, and progress. When tool design is endpoint-led, the agent receives fragments of capability without the context needed to choose, combine, or sequence actions correctly. That mismatch creates fragile automation, poor adoption, and unnecessary access surface. Practical implication: map tool design to task flows before publishing broad tool access.
Practical implication: Design MCP tool surfaces around user jobs, not backend completeness.
How workflow context changes MCP authorisation design
Workflow context determines whether a tool should be exposed, how much context it needs, and what guardrails make sense around its use. In practice, an MCP that serves a chat interface, a coding assistant, or an orchestration layer will need different resource boundaries and different expectations for user intent. This is where job-based design intersects with identity governance: the more ambiguous the workflow, the more important it becomes to constrain tool scope and avoid over-broad access just because an API exists. Practical implication: define workflow-specific access patterns before deciding what the MCP should expose. See the NHI Authentication Guide.
Practical implication: Align tool exposure with the workflow context in which the agent will operate.
Why progress-focused design beats endpoint catalogs
Progress-focused design treats the MCP as a means to an end rather than a list of actions. That means selecting the smallest useful tool set, grouping related actions into coherent tasks, and giving the agent enough context to complete a job without forcing users to understand the backend shape. This is less about interface polish and more about operational clarity. A well-scoped MCP can reduce confusion, lower accidental misuse, and make governance easier because each tool maps to an understandable business outcome. Practical implication: reduce exposed surface area by designing for outcomes instead of completeness. Read OWASP Agentic Applications Top 10.
Practical implication: Use outcome-based grouping to shrink the exposed tool surface.
Breaches seen in the wild
- Smithery.ai MCP hosting breach 2025: A Smithery.ai build flaw gave GitGuardian a live fly.io token controlling 3,000+ hosted MCP servers and the API keys their clients sent.
Read and download The State of NHI & AI Agent Breach Report 2026, covering 200+ breaches impacting Non-Human Identities including AI Agents.
NHI Mgmt Group analysis
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.
Workflow-first design is the missing control layer for MCPs. The article correctly shifts attention from tool inventory to task intent, which is where most governance failures begin. If a tool cannot be tied to a concrete job, it should not be assumed safe merely because it is available through an MCP. This is especially relevant where multiple agents, assistants, or orchestration layers may interact with the same tools. The practical takeaway is that access decisions should follow documented workflows, not engineering convenience.
Job-to-tool mapping: This is the key concept the article sharpens. An MCP that maps to jobs users actually want to complete is easier to adopt and easier to govern than one built as a generic API wrapper. That distinction matters because usability and control are linked. When tool boundaries reflect real work, security teams can reason about purpose, scope, and exceptions with far more precision.
MCP governance should borrow from product design, but not confuse design with control. Thinking like a PM helps teams understand demand, sequence, and context, yet identity teams still need to define who or what can use each tool, under what conditions, and with what visibility. The article is strongest when it shows that technical completeness is not the same as operational readiness. Practitioners should use product thinking to shape the interface and security thinking to shape the permissions.
From our research library:
- 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.
- Read next: MCP Security Guide
What this signals
Tool exposure should be treated as a governance decision, not a packaging exercise. When MCPs are built from backend capabilities first, the organisation inherits a broader identity surface than the workflow actually needs. That makes later access review harder, because reviewers are forced to assess technical possibility rather than business necessity.
Job-to-tool mapping is the control point that will matter most as MCP usage grows. Teams will increasingly need to decide which jobs are safe to expose to agents, which should remain human-mediated, and which should be split into smaller tool steps. That choice will shape both adoption and control quality, especially as environments mix chat interfaces, coding assistants, and orchestration layers.
For practitioners
- 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.
- Review exposed tools for purpose fit Remove or gate any tool that cannot be tied to a clear business job, even if the underlying API is technically available.
Key takeaways
- MCPs fail when teams equate API completeness with usable access and build around endpoints instead of tasks.
- A workflow-first design makes it easier to justify, constrain, and review what an agent can do.
- Practitioners should map jobs, test in the real interface, and remove tools that do not support a clear business outcome.
Related NHI Mgmt Group resources: MCP Security Guide · NHI Authentication Guide · OWASP Agentic Applications Top 10
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP Agentic AI Top 10 and OWASP Non-Human Identity Top 10 address the attack and risk surface, while NIST CSF 2.0 sets the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Agentic AI Top 10 | ASI02 — Tool Misuse | The article is about how agent tools should be shaped around jobs rather than exposed as raw capabilities. |
| Recommendation — Constrain agent tools to task-specific actions and remove generic endpoint exposure where it invites misuse. | ||
| OWASP Non-Human Identity Top 10 | NHI-10 — Human Use of NHI | The post centres on humans defining what non-human actors should be allowed to do through MCP tooling. |
| Recommendation — Define which tasks humans may delegate to non-human identities and document the intended scope of tool use. | ||
| NIST CSF 2.0 | PR.AA-05 — Access Permissions, Entitlements and Authorizations | MCP tool exposure is an access decision that should follow documented business need and scope. |
| Recommendation — Review MCP entitlements against documented job needs and remove exposed actions that lack a clear purpose. | ||
Key terms
- Model Context Protocol: Model Context Protocol is an open protocol that lets AI agents connect to tools and data sources. It expands what an agent can reach, so governance has to cover not only the model and its prompts, but also every system that can receive or return agent-driven data.
- Workflow-oriented MCP: An MCP design approach that exposes tools around user outcomes rather than raw backend endpoints. It reduces confusion and overexposure by grouping actions into the tasks people actually want completed, which makes governance and access review far easier to reason about.
- Tool Sprawl: Tool sprawl is the accumulation of overlapping systems that each solve part of the same identity or operations problem. In practice, it creates duplicate workflows, inconsistent policy enforcement, and more manual reconciliation, which weakens confidence in access decisions and slows down secure scaling.
Deepen your knowledge
NHI governance, agentic AI identity, and machine identity lifecycle are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are building or maturing an IAM programme, it is worth exploring.
Published by the NHIMG editorial team on October 22, 2026.
NHI Mgmt Group, the independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org