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.
Why capability-first MCP design fragments the workflow
Capability-first design asks the agent to assemble a task from low-level tools, rather than presenting a workflow that already matches the business job. That usually fragments intent into disconnected actions, increases ambiguity at decision points, and makes it harder to tell whether the agent has the right authority for each step. The result is more orchestration overhead and less predictable execution.
When the tool layer mirrors system structure instead of operational intent, the model has to infer how separate capabilities fit together. That inference is where misuse tends to creep in: the agent may choose a broader path than necessary, chain tools in an unsafe order, or expose intermediate state that the workflow never needed to surface.
Designing from jobs also changes the governance model. A job-based workflow can be reviewed as a bounded business process with clear ownership, expected inputs, and acceptable outcomes. A capability catalog is harder to govern because it is incomplete by definition, and the burden shifts to the agent to discover and combine functions correctly every time.
Why permissions expand when MCP is organised around capabilities
Capability-first MCP tends to overgrant because each tool is exposed as a reusable primitive, even when the actual business task only needs a narrow slice of it. That increases the chance that the agent will see more data, invoke more actions, or inherit more side effects than the task truly requires. A task-shaped design can keep privilege closer to operational intent, which is the cleaner security boundary.
This is also where access reviews get noisy. If a team must reason about dozens of capabilities instead of a small set of jobs, it becomes harder to decide which tool combinations are legitimate, which are exceptional, and which should be removed. The practical outcome is permission creep, especially when teams add tools to solve edge cases without re-anchoring them to a business process.
For the same reason, capability-first design often weakens accountability. If an incident occurs, it is harder to answer a simple question: what business task was this sequence supposed to complete? Without that answer, investigators end up reconstructing intent from tool traces rather than comparing execution against an approved workflow. MCP Security Guide is useful here because it frames the authorisation problem around the transport and tool layer, not just the model prompt.
What job-based MCP design does differently
Job-based MCP design starts from the operational outcome, then exposes only the tools needed to complete that outcome safely. That lets teams define a smaller permission surface, a clearer approval boundary, and a more testable success condition. It also makes it easier to spot when a workflow has drifted, because the observed sequence can be compared to the intended job rather than to a loose list of capabilities.
In practice, this approach reduces the agent’s need to improvise. The less the agent has to infer, the fewer opportunities there are for tool misuse, accidental escalation, or awkward branching into unsupported paths. If a task cannot be expressed cleanly as a job, that is usually a sign that the workflow is either too broad, too under-specified, or too dependent on human judgement to automate end to end.
The task-first model is also easier to scale across teams. Business owners can reason about tasks they recognise, while platform teams can map each task to a controlled set of tool calls. That separation keeps the platform from becoming a generic capability marketplace and makes it more realistic to review, approve, and retire workflows over time. The agentic AI applications guide helps explain why that shift matters for orchestration, governance, and agent behaviour.
Risk and Threat Considerations
Capability-first MCP increases exposure because each extra tool adds another path for misuse, accidental overreach, or confused-deputy behaviour. The main threat is not just malicious action, it is that the agent can be induced or simply guided into using a broader capability than the job requires, which widens blast radius and makes harmful side effects harder to contain.
Failure mechanism: The agent must infer the workflow from exposed functions, so it may chain tools in the wrong order, select an overpowered path, or act with permissions that exceed the intended business task.
Impact: Organisations get more ambiguity, more permission sprawl, weaker reviewability, and a larger operational surface for mistakes or abuse.
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 addresses the attack and risk surface, while NIST SP 800-53 Rev 5 sets the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Agentic AI Top 10 | ASI02 — Tool Misuse | MCP capability sprawl can push agents into unsafe or unnecessary tool use. |
| ASI03 — Identity & Privilege Abuse | Capability-first design can overexpose authority and widen agent privilege. | |
| Recommendation — Constrain tool access to the minimum set needed for each approved job. Map each workflow to least-privilege agent authority and remove excess scope. | ||
| NIST SP 800-53 Rev 5 | AC-6 — Least Privilege | The question is about avoiding broader permissions than a task needs. |
| CM-7 — Least Functionality | Capability-first MCP often exposes more functions than the workflow needs. | |
| AU-2 — Event Logging | Job-shaped workflows are easier to audit than disconnected capability chains. | |
| Recommendation — Limit each agent workflow to the least privilege required for the business job. Disable unnecessary tools and functions that are not required by the approved task. Log workflow intent, tool sequence, and outcome so task execution can be reviewed. | ||
Practitioner Guidance
What to prioritise: Define MCP around the smallest stable set of business jobs, then treat capabilities as implementation details underneath those jobs. If a capability cannot be tied to a named task, challenge whether it should be exposed to the agent at all.
What to verify: For each workflow, confirm that the agent can complete the task without discovering new authority at runtime. The useful test is whether a reviewer can describe the intended business outcome, the allowed tool sequence, and the stop condition without reading the entire capability catalog.
Common mistake: Teams often optimise for tool coverage instead of task clarity. That usually produces a system that looks flexible on paper but is harder to govern, harder to audit, and more likely to drift into unnecessary permissions.
Practitioner takeaway: If you start with capabilities, you are designing for what the system can do; if you start with jobs, you are designing for what the organisation actually meant to happen.