Start from the agent goal, not the endpoint list. Collapse related calls into a few curated tools, expose context as resources, and use prompts for repeatable workflows. The best MCP servers keep the agent’s task space small enough to finish work in one coherent conversation without forcing it to choose among dozens of thin wrappers.
How to keep an MCP surface from turning into a tool catalog
tool sprawl usually starts when teams mirror the REST inventory instead of redesigning for agent work. MCP works better when you group operations by intent, not by verb count, so the agent gets a small set of coherent actions rather than dozens of thin wrappers. That keeps selection simpler, reduces duplicate pathways, and makes each tool easier to understand, test, and govern.
A useful rule is to ask whether the agent can complete a real task without stopping to compare near-identical tools. If the answer is no, the surface is probably too granular. Curated tools should represent meaningful business actions, while repetitive or descriptive data should move into resources and repeatable sequences should move into prompts.
Good MCP design also avoids turning every endpoint into a first-class capability. Many REST APIs have internal structure that is valuable for developers but distracting for agents, especially when the same outcome can be reached through one higher-level tool. The goal is not maximum exposure of the API shape; the goal is a small action set that maps cleanly to the task the agent is trying to finish.
What to expose as a tool, a resource, or a prompt
Use tools for actions that change state, make decisions, or require a bounded execution path. Use resources for context the agent should read, inspect, or reference without turning that data into an action choice. Use prompts for repeatable workflows where the steps are known and you want the agent to follow a consistent pattern rather than improvise a sequence from many low-level calls.
This separation matters because tool sprawl is often a modeling problem, not just an API problem. If every GET, search, lookup, and metadata call becomes a tool, the agent must spend effort navigating the surface instead of solving the task. If context is exposed as resources, the agent can inspect what it needs without a growing command menu.
Teams should also think about task cohesion. A single tool can safely wrap several REST calls when those calls naturally belong to one business action, such as creating a case, validating prerequisites, and returning the final object. That is usually better than exposing each internal step as a separate tool, especially when the intermediate steps are not decisions the agent should make itself.
Designing for control, not just convenience
MCP surfaces become easier to govern when the interface reflects intent boundaries. A smaller tool set improves review, logging, and permission design because teams can reason about what each action really does and who should be allowed to invoke it. It also lowers the chance that the agent will take an unintended path simply because many overlapping tools looked equally plausible.
For protocol-level guidance, the MCP authorization specification is relevant because it frames servers as OAuth 2.1 resource servers and discourages token passthrough. That reinforces the broader design principle: the server should mediate a narrow, well-understood set of actions rather than exposing raw backend structure to the agent.
When teams need a security baseline for the exposed operations themselves, OWASP API Security Top 10 is useful for spotting where overexposed endpoints, broken authorization, and unsafe consumption can creep into the surface. It is not a design pattern for MCP, but it is a strong check on whether the underlying REST capabilities were simplified or merely repackaged.
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 sets the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP API Security Top 10 | API8 — Security Misconfiguration | MCP surfaces can become overexposed if REST capabilities are mirrored too literally. |
| Recommendation — Reduce exposed operations to the minimum set needed for each agent task. | ||
| NIST SP 800-53 Rev 5 | AC-6 — Least Privilege | Curated tools and narrow task scope support least-privilege access to backend actions. |
| AU-3 — Content of Audit Records | A smaller set of meaningful tools makes action logging and review more intelligible. | |
| SI-10 — Information Input Validation | Tool wrappers should validate inputs before translating agent requests into API calls. | |
| Recommendation — Limit each tool to the smallest backend privilege required. Log tool invocations with enough context to explain the agent’s action path. Validate tool arguments before forwarding them to backend services. | ||
Practitioner Guidance
What to prioritise: Start with the top three agent tasks you actually want to support, then design the smallest tool set that completes them end to end. If a tool does not help finish a real workflow, it probably does not belong in the first release.
What to verify: Check whether each exposed tool has a distinct purpose, a clear input contract, and a measurable outcome. If two tools differ only by a minor filter, naming choice, or response shape, collapse them before shipping.
Common mistake: Teams often preserve the REST API one-to-one because it feels safer. In practice, that creates a brittle surface where the agent must choose among wrappers instead of using a curated interface that reflects how work is actually done.
Practitioner takeaway: The best MCP design is intentionally less expressive than the backend API, because constraint is what makes the agent reliable, governable, and usable in one coherent task flow.
Related resources from NHI Mgmt Group
- How should security teams govern MCP servers that wrap REST APIs?
- How should security teams govern AI agents that access APIs through GraphQL and MCP?
- How should security teams avoid tool sprawl in continuous validation programs?
- How should security teams prevent PII from leaking through MCP tool calls?
Deepen Your Knowledge
Free weekly newsletter
Subscribe to the NHI & AI Identity Journal
The latest on NHI and Agentic AI security – articles, research, breaches, news and events every week.
Bonus 33% off our NHI Course when you subscribe.
Reviewed and updated by the NHIMG editorial team on October 7, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org