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

# MCP Gateways

# MCP Gateways API Documentation

Welcome to the MCP Gateways API documentation. This guide describes how to compose one or more registered MCP servers into a single gateway with input/output guardrail overrides.

## Purpose

The MCP Gateways API lets you build runtime-ready MCP configurations by referencing registry servers (managed via the MCP Registry Servers API) and applying gateway-specific overrides such as input and output guardrails. The expanded gateway configuration is what the secure-mcp-gateway runtime ultimately consumes.

A gateway references one or more registry servers by `saved_name` + `server_version`. When the gateway is expanded, overrides from the gateway take precedence over the base server configuration.

## Override Surface

The gateway may override the following fields:

**Per-server (and also settable gateway-wide in `common_overrides`)** — override the matching field on the underlying registry server's `mcp_config`:

* `input_guardrails_config`
* `output_guardrails_config`

**Gateway-wide only (settable only in `common_overrides`)** — applied once across the gateway, no per-server equivalent:

* `server_tools_guardrails_config` — the guardrails policy the MCP Gateway uses when checking server info and tool listings for guardrails violations. The **`input` section** of the configured guardrail is what is evaluated, with `X-Enkrypt-Mode: prompt`.

These overrides can be set in two places:

1. **`servers_config.common_overrides`** — gateway-wide. Whatever you put here is applied to every server in this gateway, so you don't have to repeat the same guardrail config on every entry. `server_tools_guardrails_config` may only be set here.
2. **`servers_config.servers[i].*`** — per-server. Set on an individual entry, this overrides the base value for that one server only. Only `input_guardrails_config` and `output_guardrails_config` are accepted here.

Both may coexist in the stored gateway, but at expansion time **`common_overrides` always wins on conflict**: for any input/output guardrails key that `common_overrides` sets, the per-server value for the same key is dropped. The semantic of "common" is "the same value for every server" — letting a per-server entry diverge would contradict it. Per-server overrides remain useful for keys that `common_overrides` does not set.

Everything else (command, args, OAuth, denied tools, source metadata) is inherited unchanged from the registry server. Use **get-gateway-config** to see the expanded view that the runtime will consume.

### How the expanded response is shaped

When you call **get-gateway-config**, the response is deduplicated:

* `common_overrides` is echoed once at the top level of the response.
* Each `expanded_servers[i].mcp_config` is the registry server's base `mcp_config` plus that entry's per-server overrides, with **any key that `common_overrides` sets removed** — those keys live only at the top-level `common_overrides`. This applies even if the per-server entry also set the same input/output key; common wins. `server_tools_guardrails_config` is gateway-wide only and never appears under an individual server's `mcp_config`.
* Keys that `common_overrides` does not set continue to flow through per-server overrides onto each server's `mcp_config`.
* The raw stored per-server override block is echoed at `expanded_servers[i].gateway_overrides` for visibility, even where common ends up winning on a specific key.

### Example

```json theme={"system"}
{
  "gateway_saved_name": "my-shared-gateway",
  "servers_config": {
    "common_overrides": {
      "input_guardrails_config": { "enabled": true, "guardrail_name": "Org Input Guardrail", "block": ["injection_attack", "pii"] },
      "server_tools_guardrails_config": { "enabled": true, "guardrail_name": "Org Server/Tools Guardrail", "block": ["policy_violation", "injection_attack", "pii"] }
    },
    "servers": [
      { "saved_name": "my-filesystem-server", "server_version": "v1" },
      {
        "saved_name": "my-github-server",
        "server_version": "v1",
        "input_guardrails_config": { "enabled": true, "guardrail_name": "GitHub-Specific Guardrail", "block": ["injection_attack", "pii", "topic_detector"] }
      }
    ]
  }
}
```

In the example above:

* `my-filesystem-server` inherits `input_guardrails_config` from `common_overrides`. Its `expanded_servers[i].mcp_config` will not contain that key — it's only on the top-level `common_overrides`.
* `my-github-server` tries to set its own `input_guardrails_config`, **but `common_overrides.input_guardrails_config` is also set, so the per-server value is dropped at expansion time** — common wins. The effective `input_guardrails_config` for both servers is the org-wide one. The per-server attempt is still echoed in `expanded_servers[i].gateway_overrides` for visibility, so you can see what was stored versus what is effective.
* `server_tools_guardrails_config` lives once at the top-level `common_overrides`; the MCP Gateway reads the **`input` section** of that guardrail (with `X-Enkrypt-Mode: prompt`) when it checks server info and tool listings for violations.

## Offered APIs

Our API suite includes the following endpoints:

* **add-gateway**: Create a new gateway that references one or more registry servers, with optional per-server overrides.

* **get-gateway**: Retrieve a gateway's stored configuration (server references and overrides only — not the expanded view).

* **get-gateway-config**: Retrieve the **expanded** gateway configuration with server references resolved and overrides applied. This is what runtime consumers should fetch.

* **modify-gateway**: Partially update an existing gateway. The `servers_config` body is **deep-merged** onto the persisted config — fields you don't send are left untouched. The `servers` array is keyed by `(saved_name, server_version)`, so a patch entry upserts (deep-merges with existing or appends as new). Send `_delete: true` on a server entry to remove it. Use `null` at any level to delete that key (RFC 7396 / JSON Merge Patch). Inside a guardrails policy, `additional_config` deep-merges; arrays (`block`) and primitives replace wholesale. See the modify-gateway endpoint reference for examples.

* **delete-gateway**: Soft delete a gateway.

* **list-gateways**: List all gateways in the project with pagination and an optional `is_active` filter.

## Required Headers

* **`apikey`** (or `api_key`): API key for authentication. Required on every call.
* **`X-Enkrypt-MCP-Gateway`**: Required for `get-gateway`, `get-gateway-config`, `modify-gateway`, and `delete-gateway`. Set to the gateway's `gateway_saved_name`.
* **`X-Enkrypt-MCP-Gateway-Version`**: Optional. Defaults to `v1`.

## Obtaining an API Key

To get started with the MCP Gateways API, you need to obtain an API key. Follow these steps:

1. **Login**: Access your account at [app.enkryptai.com](https://app.enkryptai.com).
2. **Get API Key**: Navigate to the API section to get your unique API key.
3. **Authentication**: Use this API key in the `apikey` header of your API calls.

Let's ensure safer AI together!