When the endpoint is only one step in a larger user intent. If the agent would need to call several adjacent endpoints to finish the task, a single workflow tool is usually better. Thin wrappers increase noise, expand context, and make the server harder for the agent to use correctly.
How to decide when a REST endpoint is too small for an MCP tool
A REST endpoint is usually too small to expose as its own MCP tool when it only represents one fragment of a larger job. The useful unit is the user intent, not the HTTP path. If an agent would have to string together several adjacent endpoints to complete the task, the tool should usually wrap the workflow instead of mirroring each API call one by one.
Why thin wrappers make agents worse, not better
Very small tools often look precise, but they can increase the number of decisions the agent must make. That raises selection noise, creates more context to inspect, and makes it easier for the model to pick the wrong tool or stop too early. For agentic systems, the better boundary is the smallest action that reliably completes a meaningful outcome, not the smallest endpoint the backend exposes.
That is especially true when a task depends on ordered steps, shared state, or repeated lookups across related resources. In those cases, a single workflow tool can hide brittle plumbing while preserving the business action the agent is trying to perform. The goal is not to expose every possible primitive, but to expose the level of abstraction the agent can use correctly on the first try.
What good MCP tool boundaries look like in practice
Good boundaries usually have three traits. First, they map cleanly to one user outcome, such as “create case”, “submit report”, or “provision access”. Second, they return enough context for the agent to decide the next step without extra probing. Third, they avoid exposing internal sequencing that the agent should not have to reconstruct.
If an endpoint simply fetches a field that is only useful as a prerequisite for another call, it is often better as an internal step inside a broader tool. If the endpoint carries distinct business meaning, has its own validation rules, or can complete a task independently, it is more likely to deserve separate exposure. The test is whether the agent would use it directly for a real intent, not whether it exists as a technically neat API.
That judgment matters for protocols and authorization design as well, because MCP tools should fit the scope of the action they enable. See the MCP authorization specification for the principle that tool access and token audience should track the actual resource or action being served, not an overly fragmented surface. For API-level exposure choices, the same instinct appears in OWASP API Security Top 10, where broken authorization and overly broad exposure often start with boundaries that are too thin.
Risk and Threat Considerations
Overexposing tiny tools can create both operational fragility and security drag. A larger tool surface gives the agent more chances to choose the wrong primitive, but it also gives attackers and misconfigured agents more opportunities to combine small actions into unintended outcomes. The risk grows when adjacent endpoints reveal intermediate state, partial secrets, or access paths that were never meant to be separately consumable.
Failure mechanism: Fragmented tools force the agent to reconstruct a workflow from multiple calls, which increases mis-selection, context drift, and the chance that one exposed step becomes a reusable abuse primitive.
Impact: The result is more failed tasks, more noisy retries, harder authorization review, and a wider surface for confused-deputy style misuse when an agent can invoke each step independently.
Where a small endpoint would only ever be safe inside a larger sequence, treat it as an internal implementation detail. If the endpoint can be directly and safely understood as a standalone user action, or if it materially changes what the agent is allowed to do, then it may deserve its own tool despite the overhead.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP API Security Top 10 addresses the attack and risk surface, while NIST SP 800-53 Rev 5 and NIST Zero Trust (SP 800-207) set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP API Security Top 10 | API5 — Broken Function Level Authorization | Thin MCP tools can expose excess action boundaries and misuse paths. |
| Recommendation — Group adjacent calls into one tool and restrict direct access to the underlying functions. | ||
| NIST SP 800-53 Rev 5 | IA-9 — Service Identification and Authentication | MCP tools often mediate service-to-service or agent-to-service access across backend actions. |
| AC-6 — Least Privilege | Overly fine-grained tools can expand the number of callable privileges an agent can assemble. | |
| AU-2 — Event Logging | Workflow tools and fragmented endpoints both need auditable action traces for agent use. | |
| Recommendation — Bind each tool to the service action it performs and authenticate that interaction explicitly. Minimise exposed tool privileges to the smallest useful task boundary. Log tool invocations at the workflow level so agent actions stay attributable. | ||
| NIST Zero Trust (SP 800-207) | Zero Trust Architecture | Tool boundaries should align with explicit verify-and-authorize decisions for each action. |
| Recommendation — Treat each tool call as an individually authorized action and avoid implicit trust across chained steps. | ||
Practitioner Guidance
What to prioritise: Start with the user intent and work backward to the smallest action boundary that still completes that intent without forcing the agent to chain brittle primitives. If the tool needs a companion call to make sense, it is probably too small.
What to verify: Check whether the tool can be used correctly from its name, input, and output alone. If the agent needs hidden backend knowledge, prior state assumptions, or a second adjacent endpoint to finish the job, collapse the calls into a workflow tool.
Common mistake: Treating API granularity as a reason to expose every endpoint. In MCP, the cleanest tool is often the one that removes plumbing from the agent rather than reproducing it.
Practitioner takeaway: Expose the level of abstraction that matches a real task, not the lowest-level API shape; when in doubt, prefer a single, well-scoped workflow tool over multiple thin wrappers.