Skip to main content

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 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 any of these four fields from the underlying registry server’s mcp_config:
  • input_guardrails_config
  • output_guardrails_config
  • tool_guardrails_config
  • enable_server_info_validation
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.
  2. servers_config.servers[i].* — per-server. Set on an individual entry, this overrides the base value for that one server only.
Both may coexist in the stored gateway, but at expansion time common_overrides always wins on conflict: for any of the four keys 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 key; common wins.
  • 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"] },
      "enable_server_info_validation": true
    },
    "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 both input_guardrails_config and enable_server_info_validation from common_overrides. Its expanded_servers[i].mcp_config will contain neither of those keys — they’re 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.

​
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: Update an existing gateway. Only provided fields are updated.
  • 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!