Absorb vs MCP gateways
An MCP gateway places the MCP servers you already run behind one endpoint and controls which tools each client may reach. Absorb starts one step earlier: it compiles the governed MCP server from the OpenAPI specification of an API you operate, and decides which fields each response may carry.
Side by side
| MCP gateway | Absorb | |
|---|---|---|
| Starting point | MCP servers that already exist, local or remote | An OpenAPI specification and a written policy |
| What it decides | Which servers and tools each client may reach | Which operations exist for an agent, and which fields each response returns |
| Tool definitions | As published by each server behind it | Compiled from the specification, with descriptions written and linted for tool selection |
| Response body | Usually passed through from the server | Filtered field by field against the policy, capped in size |
| Argument checks | Whatever each server implements | Validated against the schema, with conditions such as pinning a tenant identifier to a token claim |
| Human approval | Varies by product | Hold any write for Slack, ServiceNow, a signed webhook or the administrative queue |
| Evidence | Centralized request and tool call logs | One audit record per call with the decision, fields removed and drift |
| Security review | Each server and its configuration | One policy and a generated review document |
Where the difference shows
No server to begin with
Most internal APIs have an OpenAPI specification and no MCP server. A gateway needs a server to govern. Absorb produces that server from the specification you already publish.
The response is the exposure
Controlling which tools exist does not control what they return. Absorb cuts every response to the fields the policy lists, so regulated attributes never reach model context.
A contract security can sign
Compilation is deterministic, so one policy and its generated review document describe exactly what agents receive, every time.
Common MCP gateways
Each of these governs MCP servers rather than compiling them from an API specification.
| Gateway | Focus |
|---|---|
| Docker MCP Gateway | Runs each MCP server in an isolated container |
| IBM ContextForge | Federates MCP, A2A and REST APIs behind a registry |
| Microsoft MCP Gateway | Kubernetes deployments with session-aware routing |
| Bifrost | An MCP gateway and an LLM gateway in one Go binary |
Descriptions reflect each project's public documentation as of September 2026.
Running both
Absorb is an MCP server from the client's side, over streamable HTTP, SSE or stdio. A gateway can list it next to other servers while Absorb keeps enforcing the policy, the field filtering and the audit record for the API behind it.
- The gateway governs which servers a client reaches.
- Absorb governs what one API exposes and returns.
- Each keeps its own record, and the Absorb record includes the fields removed.
When a gateway alone is sufficient
If your agents only use MCP servers published by software vendors, there is no specification of yours to compile. A gateway that controls which of those servers and tools each client may reach is the right tool, and Absorb adds nothing. Absorb is warranted when the API is your own, the data is regulated or personal, or writes need authorization.
Questions
Is Absorb an MCP gateway?
It overlaps with one. Absorb serves MCP to your agents and enforces a policy on every call, but it governs the contract of an API you own rather than routing between MCP servers. Teams that run many third-party servers often use both.
Can we put Absorb behind our MCP gateway?
Yes. From the gateway's side Absorb is an MCP server over streamable HTTP, SSE or stdio, so it can be listed next to other servers. The gateway must preserve the authorization header so Absorb can identify the calling agent.
Which specifications does Absorb accept?
OpenAPI 3.0, 3.1 and Swagger 2.0 in YAML or JSON. The compiler has been validated against the 4,130 public specifications in the APIs.guru directory, of which 99.95 percent load and compile.
Other comparisons
Absorb vs OpenAPI-to-MCP wrappers
Publishing an entire specification as tools, against compiling a policy into a defined allowlist.
Absorb vs API gateways
Forwarding the requests you receive, against determining which operations exist for an agent.
Absorb vs building it yourself
A wrapper per service and its maintenance cost, against one policy per API.
Compile your own API and assess the result
Send a specification. We will show the tools it produces, the operations it withholds, and the document your security function would review.