> ## 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. # MCP Gateway > Expose your own tools to agents — an MCP server you run, or an OpenAPI document that becomes tools — governed by gateway policy. 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 | You have | Register it as | What KAOP does | | ----------------------------------- | ----------------------- | ------------------------------------------------------------------------------- | | A server that speaks MCP | An **MCP server** | Connects to it, discovers its tools, and brokers them to agents | | A REST API with an OpenAPI document | An **OpenAPI document** | Turns the operations you select into tools — no MCP server of your own required | 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](/developer-tools/mcp-server) and [Connect coding agents](/developer-tools/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**. **Server URL** is the endpoint, and **Transport** is how to speak to it. See [Authenticating to your server](#authenticating-to-your-server). **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. **Name** becomes the namespace its tools are prefixed with — letters, digits, and hyphens only. **Group** is which integration group it belongs to. Save, then run the connection test. A server in no group reaches nobody. Add it to an [integration group](/manage-your-agents/build/integration-groups) — that group's endpoint is what an agent actually connects to. ### Transport | Transport | When | | --------- | ------------------------------------------------------------------------------ | | `http` | Streamable HTTP. The default, and what you want unless your server predates it | | `sse` | Server-sent events, for servers that only speak the older 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 | Setting | What it does | | ------------------------ | ------------------------------------------------------------------------------------- | | **Timeout (seconds)** | How long a call to this server may take before it is abandoned | | **Connection-test tool** | Which tool the connection test invokes. Leave it automatic and KAOP picks a safe read | | **Static headers** | Headers always sent upstream. Use a reference, never a literal secret — see below | | **Tags** and labels | Metadata for organizing and for access control | | **Enabled** | Turn the server off without deleting it | ## Register an OpenAPI document Same entry point; choose **OpenAPI document**. The wizard is again **Connect**, **Configure**, **Review**. 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. By default KAOP calls the API at the base the document declares. **API base URL** overrides that — useful when one document describes several environments. KAOP lists every operation it discovered. Choose the ones that become tools. 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. 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*. Bind a [credential](/manage-your-agents/build/credentials-secrets) or an existing integration connection to the server. KAOP injects it as a bearer token at request time. This is the option to prefer: the secret lives in the credential store, and rotating it there is the whole rotation. An interactive per-server sign-in. You save the server first, then authorize it — KAOP caches the resulting token and refreshes it automatically. For a server that wants a custom header rather than a bearer. Put a **reference** in the value — `${credential:my-api-key}` resolves from the credential store at connect time. 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. ```mermaid theme={null} flowchart TB A["Agent calls a tool"] --> G["Guardrails
block, hold for approval, redact, or alert only"] G --> P["Policies
tool allowlists and rules"] P --> S["Group allow / deny
can only narrow the server's own rules"] S --> V["Server allow / deny
which tools it publishes at all"] V --> U["Your server"] ``` | Layer | What it decides | Where you set it | | ------------------------------- | --------------------------------------------------------------------------------------------------------------- | ----------------------------------------------------------------------------------------------------------------- | | **Server allow / deny** | Which of the server's tools exist as far as KAOP is concerned | On the server | | **Group allow / deny** | Which of a group's members' tools that group grants. It can only narrow — a tool the server denies stays denied | On the [integration group](/manage-your-agents/build/integration-groups) | | **Group binding** | Which group's endpoint an agent connects to, and therefore which tools it sees at all | On the agent | | **Policies** and **Guardrails** | Rules evaluated on every call — block it, redact a matched value, or record the match | **Integrations → Policies**, and [Standards & Guardrails](/security-and-governance/controls/standards-guardrails) | 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**. | Badge | Meaning | | ---------------------- | ----------------------------------------------------------------------------------------------------------------- | | **not checked yet** | Nothing has tried this server | | **healthy** | It answered recently | | **no recent activity** | It passed, but not recently enough to call current | | **unproven** | A check ran but could not conclude — most often because the server has no tool safe to probe | | A named failure | *unreachable*, *timed out*, *permission denied*, *sign-in required*, *credential missing*, *no tools*, and others | 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 Required reading — a server in no group reaches nobody. Where the secrets your server needs should live. Rules that block, hold, or redact a tool call. The other path, and when to prefer it. ## Related topics - [MCP server](/developer-tools/mcp-server.md) - [Integrations overview](/manage-your-agents/build/integrations-overview.md) - [APIs](/developer-tools/apis.md) - [Control plane](/get-started/architecture/control-plane.md) - [Interfaces](/get-started/interfaces.md)