Building an MCP server from a REST API: IAM risks and controls

At a glance

What this is: This is a hands-on guide to building an MCP server from a REST API, and its central finding is that the real security work happens in how endpoints are selected, described, and authenticated.

Why it matters: It matters because MCP turns ordinary API surfaces into agent-invokable capabilities, which means IAM, OAuth, and NHI governance must account for tool intent, prompt design, and transport exposure.

Context

MCP server design is an identity and access problem before it is a code problem. Once a REST API is wrapped as tools, resources, and prompts, the security boundary shifts from classic request handling to deciding which capabilities an LLM agent can invoke, under what description, and through which authentication path.

The article focuses on building a Python MCP server that exposes a curated subset of a REST API rather than the whole surface. That makes it relevant to NHI governance because every exposed tool becomes a delegated machine interaction, and every omitted endpoint is part of the security model, not just the product design.

Key questions

Q: What is the safest way to expose a REST API through MCP for agent use?

A: Expose only the endpoints that have a clear agent use case, then map them to the right MCP primitive instead of mirroring the whole API. Keep read-only data in resources, keep workflows in prompts, and reserve tools for actions that truly need execution. The safest design is intentionally smaller than the source API.

Q: Why do MCP tool descriptions affect security outcomes?

A: Because the model uses descriptions, type hints, and parameter shapes to decide which tool to call. If those descriptions overlap or stay vague, the agent can choose the wrong action, retry the wrong call, or reach capability the operator did not intend. Good descriptions function as a governance control, not just documentation.

Q: Who should own authentication for a remote MCP server?

A: The server owner should own authentication for a remote MCP server because the server becomes the control point for every agent action. That means bearer token validation, OAuth flow handling, and access scope decisions must be enforced server-side, not left to the client alone. Without that ownership, the deployment risks becoming a loosely governed proxy for backend privilege.

Q: What happens when resources and tools are not clearly separated in an MCP server?

A: The model can lose the distinction between read access and action access, which makes it easier to overexpose capabilities or confuse retrieval with execution. A clean separation keeps context fetches low-risk and makes state-changing paths easier to audit, review, and constrain.

Technical breakdown

Tools, resources, and prompts define the attack surface

MCP splits server capabilities into three primitive types. Tools are action-oriented calls the agent can invoke, resources are read-only data addresses the model can fetch, and prompts are predefined workflows the user selects to prime the agent. The security consequence is that each primitive carries a different trust expectation: tools can change state, resources can reveal context, and prompts can steer multi-step execution. In this article, the server author chooses a subset of 24 REST endpoints and maps them into eight tools, three resources, and two prompts. That is not just interface design. It is authorization design expressed through model-facing semantics.

Practical implication: Classify each REST endpoint by whether it should be invoked, read, or workflow-primed before you expose it to an agent.

OAuth and transport choice change the control boundary

The guide distinguishes stdio from streamable HTTP. Stdio works when the client launches the process locally, while streamable HTTP is the remote-friendly transport that supports a real auth model and normal network infrastructure. The article pairs that with OAuth-based authentication and token verification, which means the server is not just exposing functions over HTTP, it is admitting delegated access from an external identity context. That matters because the transport determines whether the MCP surface is a local utility or a networked identity boundary. Once remote, the server needs the same discipline you would apply to any externally callable service with bearer tokens and session-bound trust.

Practical implication: Treat remote MCP deployment as an authenticated service boundary, not as a local developer convenience with network access bolted on.

Docstrings become part of the authorization model

FastMCP turns function signatures into JSON Schema and docstrings into tool descriptions that the model uses to decide what to call. That makes naming, parameter constraints, and usage guidance a governance control, not just developer ergonomics. The article shows that a weak description causes tool overlap, retry loops, and wrong tool selection, while tighter typing and clearer when-to-use guidance improve model behavior. For identity practitioners, this is the practical edge of prompt and tool governance: the agent does not infer policy from code alone. It also infers intent from the natural-language descriptions attached to those capabilities.

Practical implication: Review tool names, docstrings, and parameter constraints as access-control artifacts that shape which actions the agent will attempt.

Threat narrative

Attacker objective: The objective is to get an agent to invoke more API capability than intended by exploiting how the MCP surface is exposed, described, and authenticated.

1. Entry occurs when a remote MCP server is exposed over streamable HTTP and accepts OAuth-backed delegated access from an external client identity.
2. Credential and permission scope are then translated into tool availability, because the model can only call what the server has described and registered as actionable surface.
3. Impact follows when overly broad tool selection, weak descriptions, or poorly bounded parameters let the agent reach more of the underlying REST API than the operator intended.

Breaches seen in the wild

• Moltbook AI agent keys breach: Moltbook breach exposed 1.5M AI agent keys.
• LiteLLM PyPI package breach: LiteLLM PyPI supply chain attack, credentials stolen from users.

Read and download The State of NHI & AI Agent Breach Report 2026, covering 150+ breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

MCP server design is an authorization problem disguised as an integration task: the article shows that the security decision is not whether an API can be wrapped, but which parts of that API become agent-invokable capabilities. That means the control plane now sits in the mapping layer between REST endpoints and MCP primitives. Practitioners should treat that mapping as a governed access boundary, not as application glue.

Tool descriptions are part of the control model: FastMCP uses docstrings, type hints, and return shapes to influence model selection. That creates a new governance surface where ambiguous language can cause wrong tool selection even when authentication is correct. The implication is that intent clarity, parameter narrowing, and explicit usage hints are now access-quality controls for NHI-adjacent workflows.

Streamable HTTP changes the trust model of MCP deployment: stdio keeps the server local and process-bound, while remote transport turns the MCP server into a network-accessible identity endpoint. Once that boundary is crossed, bearer token handling, token audience, and transport protection become operational requirements rather than implementation details. Practitioners should review remote MCP servers the same way they review any other externally callable delegated service.

Curating the exposed surface matters more than covering the whole API: the article repeatedly emphasizes selecting, splitting, merging, or omitting endpoints before code. That is the right control stance for REST-to-MCP conversions because least privilege is only meaningful when the exposed surface is intentionally smaller than the source API. The practical conclusion is to govern the exposed MCP catalog as a separate identity surface.

Runtime trust in agents depends on clear workflow boundaries: prompts, tools, and resources are not equivalent from a governance perspective. Prompts pre-shape multi-step behavior, tools can execute state changes, and resources expose read-only context. Mature IAM and NHI programmes should use that distinction to decide where approval, logging, and review need to be strongest.

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.
• Read next: MCP Security Guide

What this signals

Exposure mapping is the first control plane: once a REST API becomes an MCP server, the security problem shifts from endpoint inventory to capability inventory. Teams should expect governance pressure on which routes become tools, which remain hidden, and which are downgraded to read-only resources.

Tool intent debt: the article makes clear that natural-language descriptions influence model behaviour as much as schemas do. That means ambiguous tool wording creates operational debt in the same way weak permission naming creates access debt in classic IAM.

MCP-specific leakage is already showing up at scale: 24,008 unique secrets were exposed in MCP configuration files in 2025 alone, according to the State of Secrets Sprawl 2026. That scale makes strong boundary design and secret hygiene prerequisites, not nice-to-haves.

For practitioners

• Define the MCP exposure boundary first Inventory each REST endpoint and decide whether it should become a tool, a resource, a prompt, or remain hidden. The safe default is to expose less than the source API and to document why each capability is visible to an agent.
• Tighten tool intent and parameter bounds Rewrite tool names, docstrings, and type hints so each capability has a distinct purpose and a narrow input shape. Use closed sets where possible and avoid overlapping descriptions that could cause the model to pick the wrong action.
• Treat remote MCP as an authenticated service Use OAuth-based authentication, verify bearer tokens at the server, and apply the same transport protections you would use for any network-facing delegated access path. Remote MCP is not equivalent to local stdio.
• Test tool selection with a real model Run conversation tests that ask the model to choose between overlapping tools, then refine descriptions when it selects the wrong one or loops on retries. The goal is not only protocol correctness, but reliable intent mapping under real usage.
• Separate read-only context from state-changing actions Keep resources strictly read-only and reserve tools for changes, then confirm that the model can fetch context without being able to act on it. That separation reduces accidental privilege expansion in agent workflows.

Key takeaways

• Wrapping a REST API in MCP creates a new identity boundary where capability selection matters as much as authentication.
• Tool descriptions, schema tightness, and primitive choice shape what the agent can do, so they need governance review.
• Remote MCP servers should be treated as authenticated services with explicit exposure limits and separate read versus write paths.

Key terms

• MCP Server: An MCP server is a tool endpoint that connects an AI agent to external systems and data sources through Model Context Protocol. Because it extends what the agent can reach, it becomes part of the identity and access surface and must be reviewed like any other privileged connector.
• Tool: A tool is an MCP-exposed action that the model can choose to call at runtime. It is the equivalent of an executable privilege boundary, because its name, description, and schema influence what the agent believes it may do and what backend actions it can trigger.
• Resource: A resource is a read-only MCP object identified by a URI and fetched when the model needs supporting context. Resources are useful for exposing data without granting action rights, but they still carry governance implications if the data can influence later tool selection or reveal sensitive state.
• Streamable HTTP: Streamable HTTP is the stateless transport used for modern MCP deployments. It replaces persistent session-style connections with standard HTTP requests and responses. That design makes it easier to scale MCP servers behind load balancers, run multiple replicas, and preserve governance without tying traffic to one server instance.

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 responsible for identity security strategy or NHI governance in your organisation, it is worth exploring.