Any OpenAPI spec, as MCP tools. Secured by Hodor.

The internal API is usually the hard part

Most useful company data sits behind an internal REST API that was designed for a service account, not for an agent. Connecting an agent to it directly means handing over a long-lived key with whatever scopes the API happens to offer — usually far broader than the task needs, and with no way to express a rule on a payload.

The usual alternative is to write an MCP server that wraps the API, then re-implement identity, permissions, argument validation and logging inside it. That is a piece of security-critical infrastructure per API, maintained by whoever needed the integration first.

Hodor already sits between your agents and your applications and brokers every tool call. Generating the tool list from the spec means the API arrives inside that boundary rather than beside it — with the identity, permission, policy and audit machinery already attached.

What you get

Generating every tool is the start, not the goal

A real enterprise spec describes a great many operations, and turning all of them into tools an agent can see would make things worse rather than better. Every tool definition ships in the prompt on every turn, so a bloated catalog costs tokens and context window before it costs you an incident — and every tool the agent can see is a tool it can call by mistake.

So the generated list is a catalog to draw from, not a catalog to hand over. Permissions are the tools you link to an identity, and only those appear in the connection that identity opens. Locking an agent down to the small set of operations its job actually needs is the same motion here as it is for any other MCP server on Hodor.

From there the payload rules do the rest: constrain the arguments a generated tool can be called with, gate a call on the state of another application, and redact or tokenize anything in the response the model has no business reading.

Questions we get asked

What does Hodor generate from a spec?

A complete MCP tool list. You point Hodor at the OpenAPI spec and it turns the whole thing into MCP tools, so there is no MCP server to hand-write or maintain alongside the API.

Do the generated tools get the same governance as the rest of my catalog?

Yes. They are Hodor tools like any other: scoped per identity, constrained by payload and cross-application policies, subject to PII redaction, and audited on every call — even though they started life as plain REST.

Does the agent end up holding the API's credential?

No. The harness authenticates to Hodor with a Hodor key, never with the credential for the application it is targeting. On every call Hodor validates the request against the agent's permissions and policies, swaps in the real credential, executes, and returns the result.

A large spec produces a lot of tools. Does the agent see all of them?

Only if you link all of them. Permissions are the tools you attach to an identity, and those are the only ones that appear in the tool list its MCP connection exposes. The model cannot see, discover or call anything outside that list.

Can two agents get different subsets of the same API?

Yes. The same upstream server can expose a different tool list to each identity, so one team's catalog is not another's. Add or remove a tool and the agent's connection reflects it on the next call — no redeploy, no new keys.

Can we reshape the generated tool definitions?

Yes — tool definitions on Hodor can be reshaped rather than taken as they come. You can rewrite descriptions, make an optional parameter required, set defaults, constrain types, and enumerate the values a field can take, per agent and per workflow, without forking anything upstream.

Related: all features · the MCP gateway · MCP Safety Index