Designing an MCP server from a REST API without tool sprawl

At a glance

What this is: NHI Mgmt Group's analysis, drawing on WorkOS's blog post: A REST API should not be exposed to MCP as a one-tool-per-endpoint wrapper, and curated tools, resources, and prompts produce a more usable agent interface.

Why it matters: IAM and identity teams building agent integrations need this because MCP server design changes how access, context, and action are exposed to autonomous systems and other non-human identities.

Context

MCP server design becomes a governance problem when teams treat an API surface as if it were already an agent interface. A REST API is built for human developers chaining calls over time, while an MCP server is built for an LLM agent with a finite context window, no persistent memory of the API, and a need to complete tasks with fewer round trips.

The article’s central point is that the failure mode is not technical incompatibility but poor translation between two different users. When teams expose every endpoint as a tool, the agent inherits too much noise, too many choices, and too much intermediate state, which makes the server harder to use and harder to govern as part of an AI-enabled identity surface.

Key questions

Q: How should teams avoid tool sprawl when exposing REST APIs through MCP?

A: 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.

Q: When does a REST endpoint become too small to expose as an MCP tool?

A: 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.

Q: How do tools, resources, and prompts differ in MCP server design?

A: Tools are for actions, resources are for context the model reads, and prompts are reusable workflows that structure multi-step behaviour. A practical rule is to ask whether the model is acting, knowing, or following a standard procedure. That choice determines the primitive that will be easiest for the agent to use.

Q: Why do MCP servers built from REST APIs often feel brittle for agents?

A: Because REST was optimized for human developers who can learn an API once and reuse it, while agents operate inside a finite context window and must make sense of every tool description and result in real time. Too many tools, too many round trips, and too much JSON make the conversation harder to complete.

Technical breakdown

Why a thin REST-to-MCP wrapper fails

The core mistake is mapping every endpoint directly to a tool and assuming the agent will sort it out. MCP tools are part of the model’s prompt, so each extra tool description consumes context and each intermediate response stays in the conversation history. REST endpoints are optimized for predictable developer-driven workflows, but agents need curated affordances that reduce choice overload and preserve task continuity. A server with dozens of thin wrappers can be technically correct and still unusable because the model loses the thread before it completes the goal. The architectural issue is not transport, it is interface design for a different consumer.

Practical implication: collapse endpoint sprawl into fewer agent-level workflows instead of mirroring the REST surface one call at a time.

How MCP tools, resources, and prompts divide responsibility

The three MCP primitives solve different problems. Tools are for action, especially when the model must create, update, or trigger something. Resources are for retrieving context by URI when the model needs to know rather than act. Prompts are reusable workflows that encode a standard sequence for a user or agent to invoke. The article’s useful distinction is that not every GET is a resource and not every POST is a tool. The right test is whether the model is fetching context it already has in mind, performing work, or following a structured procedure. That distinction keeps the server smaller and more legible to the agent.

Practical implication: classify each capability by intent first, then choose the primitive that best matches the model’s role in the workflow.

Why tool granularity matters for agent reliability

Granularity is a reliability control as much as a usability choice. A coarse tool such as plan_week_meals can hide multiple REST calls behind one agent-facing action, which prevents the model from having to reason across five or six intermediate steps. By contrast, oversplitting creates tool sprawl, increases selection errors, and bloats the conversation with low-value JSON. The article also notes that return shape matters: tools should return compact, structured outputs with a clear summary the model can reuse. That keeps the agent’s working memory focused on the outcome rather than the plumbing.

Practical implication: design tools around agent goals and return only the minimum structured state needed for the next decision.

NHI Mgmt Group analysis

Tool sprawl is an interface governance failure, not a code-generation problem: the article is right to treat MCP design as a curation exercise. A direct endpoint mapping assumes the agent can absorb a human API the way a developer does, but that assumption breaks once the consumer is a context-limited model. The practical conclusion is that the control surface must be designed around task completion, not endpoint inventory.

Curated agent interfaces are the real security boundary for MCP: when every REST endpoint becomes an exposed tool, the server expands the agent’s reachable state in ways the model cannot manage well. That increases the chance of wrong tool selection, unnecessary disclosure through intermediate responses, and brittle workflows that are hard to audit. The lesson for identity teams is that exposure design belongs in the same governance conversation as authorization.

Granularity is a trust calibration mechanism: the article’s strongest insight is that the right unit of exposure is the smallest unit the agent can use correctly, not the smallest unit the API team can generate. Curated workflows, compact resources, and standard prompts reduce ambiguity and make the agent’s action space more legible. That is a design constraint practitioners should enforce before MCP servers reach production.

Model Context Protocol changes how non-human identities are expressed: the server is no longer just an integration layer, it is the interface that shapes what an AI agent can perceive and do. Once MCP becomes the agent’s user interface, teams must treat tools, resources, and prompts as identity surfaces with governance consequences. That means design decisions at the server layer now affect control, observability, and the agent’s effective privilege boundary.

Named concept: agent-facing tool curation: this article makes the case that MCP success depends on selecting and shaping only the actions an agent can complete reliably. That concept captures the difference between a callable endpoint and a usable agent primitive. Practitioners should use it as the design test for whether a server is exposing capability or simply publishing noise.

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.
• AI-related credential leaks surged 81.5% year-over-year in 2025, with the surrounding AI infrastructure leaking 5x faster than core LLM providers, according to the State of Secrets Sprawl 2026.
• Read next: MCP Security Guide

What this signals

Agent-facing tool curation: MCP server design should be treated as identity interface design, because the exposed tools define what the agent can meaningfully do. The practical boundary is not the API catalogue but the set of actions the model can complete without losing state, which is why overexposure becomes a governance problem as much as a usability one.

Teams building non-human identity governance for AI systems should think in terms of workflow surfaces rather than endpoint surfaces. A server that exposes fewer, more intentional primitives is easier to authorise, easier to observe, and easier to reason about when autonomous or semi-autonomous behaviour enters the stack.

For practitioners

• Curate agent-facing workflows Start from the user goal and collapse related endpoints into a few agent-level tools that complete a task end to end instead of exposing every REST route individually.
• Map data to resources Expose read-only context such as recipes, current pantry state, or meal plans as resources when the agent needs the information, not a state-changing action.
• Reserve prompts for repeatable flows Use prompts for standard multi-step procedures that a user or agent should invoke as a named workflow, such as a meal-planning sequence.
• Flatten tool inputs and outputs Keep schemas flat, use constrained primitive fields, and return short structured results so the model can preserve state without carrying deep JSON through the conversation.
• Design for failure as a normal state Return model-readable error messages that suggest the next valid step, and prefer recoverable responses over hard exceptions when the agent is missing information.

Key takeaways

• A direct REST-to-MCP mapping usually produces a noisy interface that agents can technically call but struggle to use reliably.
• Curating tools, resources, and prompts around agent goals reduces context loss, selection errors, and unnecessary intermediate state.
• The practical control is not endpoint exposure but interface curation, because the agent’s usable privilege boundary is shaped by how the server is designed.

Key terms

• MCP Tool: An MCP tool is a capability exposed through the Model Context Protocol so an AI agent can call external functions, retrieve data, or trigger actions. Technically, it is a structured interface with defined inputs, outputs, and permissions, allowing controlled interaction between an agent runtime and systems such as databases, APIs, or workflows.
• MCP Resource: An MCP Resource is a data object, file, or service endpoint exposed through the Model Context Protocol for an AI agent to read or reference. In technical terms, it is a named, addressable context source that can be discovered, described, and accessed through MCP permissions, metadata, and transport rules.
• 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.
• Prompt Workflow: A reusable instruction pattern that starts a structured sequence for the agent to follow. Unlike a tool, it is not primarily about state change. It is useful when the task has a standard shape and the user is intentionally selecting a known operating procedure.

Deepen your knowledge

NHI governance, agentic AI identity, and machine identity security 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.