Skip to main content
The MCP Gateway is the second of the two ways an agent reaches something external, and the one for tools that are yours. Point the Komodor Agentic Operation Platform (KAOP) at an MCP server you run, or at an OpenAPI document, and its operations become tools agents can call — with the gateway deciding which agent may call which. This page covers registering both kinds, how they are authenticated, and what governs access.

​
The two things you can register

Both end up in the same place: a tool server in your Integrations list, groupable and governable the same way. The gateway dials outward to reach them; nothing needs to reach into KAOP.
This is distinct from KAOP’s own MCP server, which is an inbound endpoint your coding agent connects to in order to operate KAOP. See MCP server and Connect coding agents. The gateway is outbound; that one is inbound.

​
Register an MCP server

From Integrations, press Add integration, choose the custom-integration tile, and pick MCP server. The wizard runs in three steps — Connect, Configure, Review.
1

Point it at the server

Server URL is the endpoint, and Transport is how to speak to it.
2

Choose how it authenticates

See Authenticating to your server.
3

Decide which tools to publish

Allow patterns and Deny patterns are globs over tool names, one per line. An empty allow list means every discovered tool; a deny pattern wins over an allow.
4

Name it and put it in a group

Name becomes the namespace its tools are prefixed with — letters, digits, and hyphens only. Group is which integration group it belongs to.
5

Review and test

Save, then run the connection test.
A server in no group reaches nobody. Add it to an integration group — that group’s endpoint is what an agent actually connects to.

​
Transport

The gateway proxies remote servers. There is no local-subprocess transport — a server has to be reachable over HTTP from the gateway.

​
The other settings

​
Register an OpenAPI document

Same entry point; choose OpenAPI document. The wizard is again Connect, Configure, Review.
1

Supply the document

Either a public HTTPS URL KAOP fetches, or upload the document itself. One or the other — not both. OpenAPI 3.0 and 3.1 are supported.
2

Override the base URL if you need to

By default KAOP calls the API at the base the document declares. API base URL overrides that — useful when one document describes several environments.
3

Select the operations to expose

KAOP lists every operation it discovered. Choose the ones that become tools.
4

Add notes where the API is not self-explanatory

A note on an operation is appended to its description, so it travels with the tool and the agent reads it when deciding whether to call.
5

Name it, review, and test

The name namespaces the tools, exactly as for an MCP server.
The operation list is an explicit allowlist. There is no “expose everything” setting and no exclude list — which means an operation added to your API after you imported it stays off until a person enables it. That is deliberate: growing your API never silently widens what agents can do.
Reconfiguring later — Edit operations on the server — is how you add or remove operations. Use refresh to re-read the document after your API changes; the tool names KAOP assigned stay stable so an agent’s configuration does not break underneath it.
Practical limits worth knowing before you point KAOP at a large API: a document may declare up to 1,500 operations, of which up to 200 may be enabled as tools, and the document itself is capped at 5 MB. Select the operations an agent actually needs rather than everything the API offers.

​
Authenticating to your server

Four options, and the right one depends on what your server expects.
A public server or API with no credentials. Legitimate, and the wizard says so: None — public server, no credentials.
Static headers are stored as configuration and are readable back through the admin API. A literal secret in an authentication header is refused for exactly that reason. Use a ${credential:…} reference instead, and the value is resolved at connect time without ever being stored in the header.
For an OpenAPI-backed server the auth posture is deliberately strict: if the bound credential cannot be resolved, the call fails rather than proceeding. Calling your REST API unauthenticated is worse than not calling it.

​
Gateway policy — what governs a call

A tool being registered is not a tool being callable. Four layers apply, and they only ever narrow. A guardrail is evaluated before a policy, so when both would refuse a call, the reason you read names the guardrail you wrote rather than a rule id. If policy evaluation cannot run, the call is refused — the gateway fails closed.

​
Test and health

A registered server carries the same two-part health story as a built-in integration, and the same rule applies: skipped is never a pass. Two things a test can prove, and it tries both: that KAOP can connect and list the server’s tools, and that the credential is permitted to actually do something. A server whose only safe tools need no credentials can only be checked for connectivity, which is what unproven means. Health is also updated by real agent traffic — the badge’s tooltip says which observed it. Hover to see whether you are reading a connection test, a start-up check, or live traffic.
Nothing tests your servers on a schedule. A credential revoked upstream can keep reading as healthy until something touches the server, and a revocation is only reliably caught by a connection test or a refresh. Test after any credential change on your side.

​
Next steps

Integration groups

Required reading — a server in no group reaches nobody.

Credentials & secrets

Where the secrets your server needs should live.

Standards & Guardrails

Rules that block, hold, or redact a tool call.

Integrations overview

The other path, and when to prefer it.