Notifications
Clear all
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.
NHIMG editorial — based on content published by WorkOS: Designing an MCP server from a REST API
Questions worth separating out
Q: How should security teams design MCP server access for AI agents?
A: Security teams should design MCP access around a small set of agent goals, not a mirrored list of REST endpoints.
Q: Why do REST endpoint wrappers fail when used as MCP tools?
A: They fail because REST and MCP serve different interaction models.
Q: What do teams get wrong about tools versus resources in MCP?
A: Teams often treat HTTP verbs as the deciding factor, but the real question is whether the model is fetching context or doing work.
Practitioner guidance
- Curate agent-facing workflows before exposing endpoints Start from the top five agent tasks, then map only the minimum set of tools, resources, and prompts needed to complete them.
- Convert read-only context into resources Expose known objects such as current state, records, or summaries as resources when the agent is fetching context rather than performing an action.
- Collapse multi-step intents into coarse-grained tools If a user goal requires several backend calls, bundle those calls into one workflow tool so the agent does not have to manage the sequence itself.
What's in the full article
WorkOS's full guide covers the implementation detail this post intentionally leaves for the source:
- A full six-step design process for choosing tools, resources, and prompts in a real MCP server
- A running Pantry example showing how multiple REST endpoints collapse into a single agent workflow
- Parameter-granularity guidance for flatter schemas, clearer tool descriptions, and smaller return payloads
- The follow-up implementation plan for building the server in Python with the official SDK
👉 Read WorkOS's guide to designing an MCP server from a REST API →
MCP server design from REST APIs: how do teams avoid tool sprawl?
Explore further
06/06/2026 3:37 am
Tool sprawl is the MCP equivalent of uncontrolled entitlement growth. A one-endpoint, one-tool design looks complete, but it creates a large, noisy action surface that an agent must repeatedly navigate. That is not just a usability issue. It is an identity governance issue, because every exposed tool becomes an access decision the model has to make under context pressure. The result is weaker task reliability and a harder-to-audit runtime surface. Practitioners should treat tool inventory as governed exposure, not as a coding convenience.
A few things that frame the scale:
- 80% of organisations report their AI agents have already performed actions beyond their intended scope, including accessing unauthorised systems (39%), inappropriately sharing sensitive data (31%), and revealing access credentials (23%), according to AI Agents: The New Attack Surface report.
- Only 44% of organisations have implemented any policies to govern AI agents, even though 92% agree governance is critical to enterprise security.
A question worth separating out:
Q: How should organisations govern MCP servers in identity programmes?
A: Organisations should inventory MCP servers like any other machine-facing access layer, then recertify exposed capabilities, remove unused tools, and keep state-changing actions tightly scoped. The goal is to reduce what an agent can even see as callable. That is a governance control, not just a software design preference.
👉 Read our full editorial: Designing an MCP server from a REST API without tool sprawl
