Absorb vs OpenAPI to MCP wrappers
Wrapper tools answer whether an agent can reach an API. Absorb answers the questions that follow: which operations exist for this agent, which fields are returned, whose credentials are used, and what record remains afterward.
Side by side
| Spec wrapper | Absorb | |
|---|---|---|
| What the agent sees | Every documented operation, including writes and internal routes | Only operations a policy names, with wildcard writes refused unless named |
| Response handling | The upstream body, unmodified | Field level projection, unlisted fields dropped, size capped |
| Sensitive data | Any data the API returns reaches the model | Excluded fields never leave your network |
| Credentials | Typically held in the agent's configuration file | Held at the edge from environment or vault, agents never see them |
| Argument checks | Forwarded without validation | Validated against the schema, with policy conditions such as binding a tenant identifier to a verified token claim |
| Human approval | None | Hold any write for Slack, ServiceNow, a signed webhook or the administrative queue |
| Evidence | Application logs, where they exist | One audit record per call with the decision, fields removed and drift, exportable to your SIEM |
| Security review | The entire API is reviewed again | One policy and a generated review document |
| Context cost | The whole spec, loaded as tool definitions | Only the operations the policy names, with descriptions written for tool choice |
Why the distinction matters
Refusal beats instruction
Instructing a model not to call an operation is guidance. Not emitting the operation is a control. Absorb never publishes what the policy excludes, so there is nothing to invoke.
The leak is usually in the response
Most exposure comes not from a destructive verb but from regulated data in a nested object that nobody examined. Filtering is applied at field level, and undocumented attributes are removed by default.
Specifications drift
Production diverges from the document over time. absorb probe compares live responses against the specification before deployment, and the runtime records mismatches thereafter.
When a wrapper is sufficient
If the API is read only, public, and returns nothing you would object to seeing in a transcript, a wrapper is adequate and less expensive. Absorb is warranted when the API is internal, the data is regulated or personal, write operations exist, or authorization is required before agents interact with it.
Questions
Does Absorb replace the wrapper we already run?
Yes, for production use. Absorb speaks the same protocol to the same clients, so changing the endpoint is a configuration change in the agent. What differs is what is published and what is returned.
Can we keep using the spec we already publish?
Yes. Absorb reads OpenAPI 3.0, 3.1 and Swagger 2.0 in YAML or JSON, and has been validated against the 4,130 public specifications in the APIs.guru directory, of which 99.95 percent load and compile.
Does compilation use a model?
No. Compilation is deterministic: the same specification and policy always produce the same tools, which is what makes the output reviewable.
Other comparisons
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.
Absorb vs MCP gateways
Governing the MCP servers you already run, against compiling a governed server from your own 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.