Topic starter
06/06/2026 2:07 am
TL;DR: A REST API mapped one endpoint at a time into MCP usually becomes noisy, brittle, and hard for agents to use, because MCP is designed around curated tools, resources, and prompts rather than thin wrappers, according to WorkOS. The practical lesson is that server design must start from agent goals and context windows, not HTTP endpoints, or the agent will lose the thread before completing useful work.
Editorial analysis by NHI Mgmt Group, based on content published by WorkOS: “Designing an MCP server from a REST API”.
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.
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.
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.
Practitioner guidance
- 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.
Bottom line: A direct REST-to-MCP mapping usually produces a noisy interface that agents can technically call but struggle to use reliably.
Explore further
View Full Forum → | NHI Foundation Course → | Our Services → | Read the full analysis →
06/06/2026 3:37 am
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.
A few things that frame the scale:
- 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.
A question worth separating out:
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.
👉 Read our full editorial: Designing an MCP server from a REST API without tool sprawl