Powering the MCP ecosystem

Make the tools your agents rely on discoverable and governed, including the REST APIs that were never built for agents.

An agent ecosystem only works if agents can find the tools they need and reach them safely. Most enterprise capability still sits behind conventional REST APIs that MCP clients cannot call, and wiring each one up by hand does not scale as the number of tools and teams grows.

What you can do

  • Turn an existing REST API into MCP tools from its OpenAPI specification so that agents can call it without any change to the backend.
  • Serve the standard MCP methods over JSON-RPC with SSE streaming so that any compliant MCP client can discover and invoke tools.
  • Let agents discover tools at runtime through tools/list so that new capability appears without re-integrating each client.
  • Gate which tools each caller may list or call so that privileged tools stay restricted by identity or claim.
  • Reach tools hosted behind another gateway over a fabric:// link so that an ecosystem can span teams and organisations.

How it works

MCP clientagentMCPAgent GatewayMCP surfaceJSON-RPC 2.0SSEOPA policyTool gatingidentity from _meta resolved to a DIDallow and deny gates filter list and callMCP proxyOpenAPI to toolsREST APIbackend, unchangedfabric://Remote gatewaylinked tools

An MCP proxy takes a backend’s base URL and its OpenAPI specification and builds an MCP server that exposes each operation as a tool, so a plain HTTP API becomes callable by MCP clients with no backend change. An MCP surface then wraps that server, or any MCP server, with the gateway’s controls: it proxies the standard methods (initialize, tools/list, tools/call, resources/read, prompts/get) over JSON-RPC 2.0, with Server-Sent Events for streaming.

Access is enforced two ways. An OPA policy on the surface evaluates each request, and MCP tool gating matches tool names against regex allow and deny gates, each optionally conditioned on its own policy, so you can expose a family of tools to one caller and hide it from another. Caller identity travels in the MCP _meta object (fields such as agentIdentity), which the gateway resolves to a DID for attribution and cross-gateway verification. To reach a tool server behind a different gateway, a surface targets a fabric:// address and the request is carried over the encrypted gateway-to-gateway link.

A tools/call that a gate or policy rejects is refused before it reaches the backend, and tools/list returns only the tools the caller is allowed to see.