Skip to main content

​
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

{
  "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.
  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!