> ## Documentation Index
> Fetch the complete documentation index at: https://docs.komodor.com/llms.txt
> Use this file to discover all available pages before exploring further.

# Integrations overview

> The two ways an agent reaches anything external — the built-in integration catalog or the MCP Gateway — and how to choose between them.

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

<CardGroup cols={2}>
  <Card title="Built-in integrations" icon="plug" href="/manage-your-agents/build/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.
  </Card>

  <Card title="MCP Gateway" icon="code-branch" href="/manage-your-agents/build/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.
  </Card>
</CardGroup>

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.

```mermaid theme={null}
flowchart LR
  A[Agent] --> I["Built-in integration<br/>from the catalog"]
  A --> G["MCP Gateway"]
  I --> S1["Datadog, AWS, GitHub,<br/>Kubernetes, Slack, …"]
  G --> M["Your MCP server"]
  G --> O["Your OpenAPI surface"]
  C[(Credentials)] -.-> I
  C -.-> G
```

## 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.

| Question                      | Built-in integration                                                               | MCP Gateway                                                                               |
| ----------------------------- | ---------------------------------------------------------------------------------- | ----------------------------------------------------------------------------------------- |
| Is the system in the catalog? | Yes — use it                                                                       | No, or the catalog connection does not expose what you need                               |
| Who defines the tools?        | KAOP does                                                                          | You do                                                                                    |
| What do you supply?           | Credentials, and any account or region detail the provider needs                   | A reachable MCP server or an OpenAPI surface, plus its auth                               |
| Typical case                  | Read metrics from Datadog, list resources in AWS, comment on a GitHub pull request | Call your internal deployment service, query your own inventory API, wrap a homegrown CLI |
| Ongoing work                  | Connect once; test and reconnect when credentials change                           | Keep your server or spec available and current                                            |

<Tip>
  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.
</Tip>

### Cases worth naming

<AccordionGroup>
  <Accordion title="The system is in the catalog, but I want a different tool than it offers">
    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.
  </Accordion>

  <Accordion title="I already run an MCP server for my developers">
    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.
  </Accordion>

  <Accordion title="I only have a REST API and no MCP server">
    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.
  </Accordion>

  <Accordion title="I need to reach several systems for one agent">
    Connect each one, then bundle them with an
    [integration group](/manage-your-agents/build/integration-groups) and attach the group to the
    agent as a set.
  </Accordion>
</AccordionGroup>

## 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](/manage-your-agents/build/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](/security-and-governance/controls/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](/manage-your-agents/run/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](/manage-your-agents/build/triggers-schedules).
* **Outbound webhooks** (Integrations → Webhooks) are KAOP posting events to an endpoint of yours.
  See [Outbound webhooks](/manage-your-agents/run/outbound-webhooks).

## Next steps

<CardGroup cols={2}>
  <Card title="Built-in integrations" href="/manage-your-agents/build/built-in-integrations">
    The catalog, the auth modes, and how to connect and test one.
  </Card>

  <Card title="MCP Gateway" href="/manage-your-agents/build/mcp-gateway">
    Register your own MCP server or OpenAPI surface.
  </Card>

  <Card title="Integration groups" href="/manage-your-agents/build/integration-groups">
    Attach a set of connections to an agent in one move.
  </Card>

  <Card title="Credentials & secrets" href="/manage-your-agents/build/credentials-secrets">
    The store both paths use.
  </Card>
</CardGroup>


## Related topics

- [Integration groups](/manage-your-agents/build/integration-groups.md)
- [MCP Gateway](/manage-your-agents/build/mcp-gateway.md)
- [How it works](/manage-your-agents/build/how-it-works.md)
- [Onboarding](/get-started/onboarding.md)
- [Build from scratch](/manage-your-agents/build/build-from-scratch.md)