MCP Registry

Highflame's MCP Gateway is the control-plane surface for registering, securing, and operating MCP servers. Highflame MCP registry is a security-first proxy that sits between MCP clients and downstream servers, and it is managed through Studio.

Instead of allowing clients to connect directly to every MCP server, the gateway creates a single control boundary where Highflame can authenticate the client, determine which server and tool are allowed, evaluate runtime guardrails, and capture the resulting telemetry.

What the MCP registry provides

Highflame MCP registry is more than an MCP reverse proxy. The current gateway supports:

• registry-backed routing so each configured server is exposed through a stable gateway endpoint

• MCP session management for standard MCP methods, such as tools, prompts, and resources

• OAuth 2.1 + PKCE for clients that cannot send custom headers

• token brokering for third-party MCP servers that require per-user downstream OAuth

• Shield integration for tool-call guardrails and policy evaluation

• multi-tenant enforcement so requests stay scoped to the right account and project

This lets developers standardize how agents access tools without forcing every client to implement its own auth, policy, and observability logic.

Registry Model

In Studio, the MCP registry acts as the source of truth for the servers your project is allowed to use. A registry entry typically defines:

• the MCP server identity and description

• the upstream connection details

• how the server should authenticate

• which tools are enabled for use

• any policies or baseline controls attached to that server

Tool discovery and tool enablement are intentionally separate. A server can expose many tools, but only the subset you enable should be available to agents in production.

Authentication And Access Patterns

The gateway supports more than one way to authenticate MCP traffic:

• API key flows for clients that can send project-scoped credentials directly

• OAuth 2.1 + PKCE for clients such as Claude Desktop, Cursor, and Windsurf

• token broker mode for third-party MCP servers where the registry fetches the user's downstream token and injects it server-side

That last mode is important for developer tooling. It means the MCP client authenticates once to Highflame, and the MCP registry handles downstream provider credentials on behalf of the user. The client never needs to manage provider tokens directly.

Runtime Enforcement

The MCP Gateway works with Shield to evaluate tool interactions before and after execution. Depending on the server, tool, and policy configuration, Highflame can:

• inspect requests before they reach the downstream MCP server

• inspect tool responses before they are returned to the client

• apply Cedar policies using project and request context

• record the tool call, policy outcome, and related signals for later investigation

This turns MCP access into a governed execution path instead of a direct network connection.

Operating MCP Servers In Studio

Teams manage the MCP Gateway from Studio. Common workflows include:

• adding a new server to the registry

• reviewing discovered tools and enabling only the ones that should be live

• attaching policies to a server or project

• checking connectivity and auth configuration

• tracing how a tool was used in production

The next page covers the security model for MCP servers and tools in more detail.