Skip to main content
An agent that cannot see your systems cannot do operations work. The Komodor Agentic Operation Platform (KAOP) gives it exactly two ways to reach anything external: a built-in integration from the catalog, or the MCP Gateway for tools you expose yourself. This page explains what each path is, how to choose, and what both share underneath — read it before you connect anything.

​
The two paths

Built-in integrations

A ready-made connection to a system KAOP already knows — Datadog, AWS, Azure, GitHub, Kubernetes, PagerDuty, Slack and more. You supply credentials; the tools, auth handling, and connection health come with it.

MCP Gateway

A connection to a tool surface you own — any MCP server, or an OpenAPI surface KAOP turns into tools. You define what the tools are; the gateway governs who may call them.
There is no third path. Anything an agent reaches outside itself arrives through one of these two, which is what makes the question “what can this agent touch?” answerable at all.

​
How to choose

Start with the catalog. Reach for the gateway when the catalog does not cover the system, or when the capability you want is genuinely yours.
The two are not exclusive, and most real agents use both. A remediation agent might read Datadog through a built-in integration and open a change through your own service via the gateway.

​
Cases worth naming

Use the built-in integration for what it covers, and expose the extra capability through the MCP Gateway. They coexist on the same agent, and each keeps its own credentials.
Register it with the MCP Gateway. The gateway is the governance boundary — it decides which agents may call which of its tools — so you get policy over a surface you already maintain.
Register the OpenAPI surface with the gateway instead. You do not have to build an MCP server to give agents access to an existing API.
Connect each one, then bundle them with an integration group and attach the group to the agent as a set.

​
What both paths share

Whichever path a connection takes, the same three mechanisms apply.

​
Credentials

Secrets are never part of an agent’s code or image. You store a credential once, bind it to the agents allowed to use it, and it is delivered to a run in memory without its value being exposed to you or written into the run’s evidence. Both paths resolve their secrets this way. See Credentials & secrets.

​
Governed access

A connection existing is not the same as an agent being allowed to use it. An agent reaches a connection only when that connection — or the group containing it — is attached to the agent, and its actions are still checked against policy at the moment it acts. See Standards & Guardrails.

​
Evidence

Every call an agent makes through either path is recorded in the run: which tool, with what arguments, and what came back. This is what lets you audit a conclusion instead of trusting it. See Runs & evidence.

​
What is not a connection path

Two adjacent surfaces are easy to mistake for a third way in. Both are about work arriving, not about an agent reaching out:
  • Endpoints (Integrations → Endpoints) are inbound URLs an external system posts to in order to start a run. They are not triggers and not integrations. See Triggers & schedules.
  • Outbound webhooks (Integrations → Webhooks) are KAOP posting events to an endpoint of yours. See Outbound webhooks.

​
Next steps

Built-in integrations

The catalog, the auth modes, and how to connect and test one.

MCP Gateway

Register your own MCP server or OpenAPI surface.

Integration groups

Attach a set of connections to an agent in one move.

Credentials & secrets

The store both paths use.