# Turn existing APIs into MCP tools

> Let agents use the REST APIs your teams already run, with no change to the APIs, by publishing each operation as a governed MCP tool.

Your teams already run REST APIs that agents could use, if agents could reach them. MCP clients cannot call a plain HTTP API, so each one has to be rebuilt as an MCP server or wired into each agent by hand. That work does not scale as the number of tools and teams grows, and every hand-built integration needs its own access control.

## What you can do

- Turn a REST API into MCP tools from its OpenAPI specification so that agents can call it with no change to the API itself.

- Let agents discover the tools they need at runtime through tools/list so that no agent depends on a hand-maintained list of the operations it can call.

- Reach an MCP server directly by URL, or through a connection to a partner’s gateway, so that tools hosted by another team or company are available to your agents too.

- Control which tools each caller can see and call so that agents reach only the operations they are entitled to.

## How it works

On the Proxies page, Add MCP Proxy starts a wizard that takes the API’s Base URL and its OpenAPI Specification as OpenAPI 3.0 YAML. Each operation in the specification becomes an MCP tool, and the proxy serves those tools over MCP on its own address, so the API behind it stays exactly as it is.

To govern the tools, put the proxy behind an MCP surface: set the Managed Agent element’s Endpoint Type to via MCP Proxy and choose the proxy. The same setting reaches any other MCP server by Direct URL, or tools published on a partner’s linked gateway via Gateway Connection. The surface proxies the standard MCP methods, such as initialize, tools/list, and tools/call, over Streamable HTTP, the current MCP transport. It also accepts the legacy HTTP and Server-Sent Events (SSE) transport, and detects which transport an upstream MCP server uses, so older clients and servers keep working.

Agents discover tools by calling tools/list, which returns only the tools the caller is allowed to see. On the surface, OPA policies and the MCP Tool Gating element make that decision for each caller, and a tools/call that a gate or policy rejects is refused before it reaches the API.

Per-caller tool control applies on the MCP surface. A new MCP proxy also serves every tool in its specification on its own route, with no sign-in or policy. Turn off Also serve on its own route (no sign-in) on the proxy, and point agents at the surface’s Access Point.

## Related

- [Expose a REST API as MCP tools](/products/affinidi-trust-fabric/agent-gateway/how-to-guides/setup/expose-a-rest-api-as-mcp-tools.md): Create an MCP proxy from an OpenAPI specification and attach it to a surface.

- [MCP protocol](/products/affinidi-trust-fabric/agent-gateway/concepts/protocols/mcp.md): How the gateway serves and proxies MCP tools.

- [Control MCP tool access with per-tool policies](/products/affinidi-trust-fabric/agent-gateway/how-to-guides/policies/control-mcp-tool-access-with-per-tool-policies.md): Bind individual tools to policies and gate whole families by pattern.

- [Retire shared API keys](/products/affinidi-trust-fabric/agent-gateway/use-cases/retire-shared-api-keys.md): How per-caller credentials and MCP Tool Gating decide which tools each agent sees.

- [Let agents work across companies](/products/affinidi-trust-fabric/agent-gateway/use-cases/let-agents-work-across-companies.md): How a connection to a partner’s gateway carries identity and policy across the boundary.