MCP Gateway (govern external servers)

The MCP Gateway is how Corveil proxies out to external and third-party MCP servers. Org admins register a server once, store a single credential, and grant who may call which tools. Developers and agents then reach those tools through Corveil — with RBAC, argument rules, rate limits, and a full audit trail — instead of every person running the server locally with a personal key.

Two MCP surfaces

This page is outbound: Corveil governing external MCP servers.

To connect a client to Corveil's own tools (the knowledge graph, Insights, and the control plane at /mcp), see Corveil MCP (connect a client).

What it is

Without the gateway, a stdio MCP server (AWS, analytics, …) typically lives on a laptop. Each developer installs it, drops their own keys in the environment, and there is no org-wide picture of who called what.

With the gateway, that server sits behind Corveil:

• One org-held credential. Upstream tokens never leave Corveil. Callers authenticate with a Corveil virtual API key; Corveil injects the stored secret on the way out.
• RBAC. Server-level and per-tool allow/deny, scoped to the organization, a team, a user, or an API key. Default-deny: no allow row means the server is invisible and every tool call is refused.
• Argument rules. Regex, allowed values, and numeric ranges on tool parameters, so a granted tool cannot be pointed at an unintended target.
• Rate limits. Per-minute and daily caps, scoped by the same grants.
• Audit. Every proxied call (and every blocked one) is logged with method, tool, latency, and the reason it was blocked, if any.

The caller-facing URL is always /mcp/{slug}/mcp. Admins manage servers under Connections → Tools. Admin-only — members cannot register servers or store upstream credentials. See Roles & Permissions.

Supported transports

The caller always speaks Streamable HTTP to Corveil. Two transports sit behind that URL:

Transport	What it is	Who can use it
streamable_http	Proxy to a remote HTTP MCP upstream. Credentials inject as headers. Catalog templates cover servers such as GitHub, Linear, Slack, and Notion.	Any org with the MCP Gateway enabled. An admin registers a server or installs a catalog template, then stores the credential and grants access.
local_process	A stdio MCP server (JSON-RPC over stdin/stdout) executed by Corveil's isolated runner, not by the gateway process. The gateway forwards to the runner over an authenticated internal channel.	Vetted catalog only, enabled per-org. You cannot register an arbitrary stdio process. Corveil ships a curated catalog of pinned servers; staff turn the stdio_mcp flag on for your org, then an admin installs the template.

local_process is not "connect any stdio server." The runner launches only slugs that appear in the vetted catalog, with a pinned command and a supply-chain digest it verifies before every spawn. An org without stdio_mcp never sees those templates and cannot proxy them.

The vetted-catalog model

Stdio MCP servers are pre-vetted before they become installable:

1. Read-first posture. Prefer servers whose tools are lookups, reports, and describe calls. Write-capable tools, if any, ship with a default deny plan.
2. Pinned launch vector. A specific package at a pinned version, plus a lockfile whose sha256 digest the runner checks on every spawn. Runtime uvx / npx (resolve-from-the-index at launch) is not used.
3. Catalog install is adoption, not authoring. Installing a template adopts the pinned server. It does not let an operator supply their own command.

AWS is the reference local_process server: awslabs.aws-api-mcp-server — read-first AWS API access, run behind the isolated runner. More vetted servers are added over time; Google Analytics is the worked catalog example of the same runbook.

Remote HTTP (streamable_http) templates are a separate, self-serve catalog path: an admin can also register a remote HTTP MCP URL by hand. That path does not extend to stdio.

How to request a vetted MCP server

There is no self-serve form to register an arbitrary stdio process. The customer-facing path is a request:

1. Ask. Email hello@corveil.com, or your Corveil contact, and name the MCP server you want governed (package, vendor, and why the org needs it). An org admin can make the request.
2. Vetting. Corveil reviews the server (read-first posture, pinned version, digest) and, if it is accepted, adds it to the catalog. That work is an engineering change, not an in-dashboard toggle.
3. Enablement. Staff turn stdio_mcp on for your org. The template then appears under Connections → Tools → Browse Catalog. An admin installs it, stores the org credential, and grants who may call it.

Until that flag is on, the template is hidden and the slug 404s. That is intentional: stdio support is vetted catalog, enabled per-org, not a self-serve "run whatever is on npm" feature.

If the server you need is already in the catalog (for example AWS) and your org already has stdio_mcp, skip the request: install from Browse Catalog, add the credential, and grant access.

Using a governed server from a client

Once a server is installed and you have an allow rule, point an MCP client at the proxy URL. Authenticate with a Corveil virtual API key — never the upstream secret.

{
  "mcpServers": {
    "github": {
      "type": "streamableHttp",
      "url": "https://your-corveil-host/mcp/github/mcp",
      "headers": {
        "Authorization": "Bearer sk-citadel-your-key-here"
      }
    }
  }
}

The pattern is always https://{corveil-host}/mcp/{slug}/mcp. Discover which servers you can reach:

curl https://your-corveil-host/mcp/servers \
  -H "Authorization: Bearer sk-citadel-your-key-here"

The list is RBAC-filtered: you only see servers you are allowed to call. Client setup for Corveil's own tools at /mcp (no slug) is on Corveil MCP.