AISIX AI Gateway · MCP Gateway

One MCP Gateway to govern AI agent tool calls

AISIX AI Gateway fronts your registered Streamable HTTP MCP servers through one /mcp endpoint. Authenticate callers, show each agent only its allowed tools, keep upstream credentials gateway-side, control tool-call traffic, inspect tool arguments and text result content, and record every tools/call attempt in one telemetry pipeline.

Start with the MCP quickstart Talk to an expert

Streamable HTTP upstreams · Default-deny tool access · MCP-native JSON-RPC errors

One governed path

AI agentsMCP clients

/mcp

AISIX

Caller authentication
Allowed tool filtering
Limits · guardrails

MCP serversTools & APIs

Usage events Prometheus

Why a gateway

Direct agent-to-server access breaks at production scale

MCP standardizes tool calls. Your platform still needs one place to decide who can discover a tool, who can invoke it, which credential reaches upstream, and what happens when policy blocks the call.

Credentials spread into agent runtimes

Each direct integration needs its own upstream secret handling and rotation path.

Tool access grows broader than intent

Agents can discover tools they should never see when access rules live only in prompts or app code.

One request becomes an unbounded loop

Repeated tool calls can exhaust upstream capacity without a shared request and concurrency boundary.

Operations lose the execution trail

Different clients produce different logs, making server, tool, outcome, and latency hard to compare.

MCP Gateway architecture

Enforce policy between agent intent and tool execution

This runtime data path shows how AISIX AI Gateway exposes one MCP server endpoint to clients and routes permitted, policy-compliant tool calls to registered upstream servers using credentials that stay inside the gateway.

Server registration and policy configuration happen outside this runtime path through the self-hosted Admin API or managed control plane.

Agents & MCP clients

Connect to one endpoint with an AISIX caller API key.

Authorization: Bearer …

AISIX MCP Gateway/mcp

Authenticate callerResolve one caller API key boundary.
Filter & authorize toolsFilter tools/list, then recheck tools/call.
Apply runtime controlsRequest limits, concurrency, guardrails; managed budget checks.
Authenticate upstreamAttach only the registered server credential.

Every tools/call attempt → usage event; MCP-labeled metrics

github__*

runbooks__search

catalog__lookup

Registered MCP servers

Reachable from AISIX over Streamable HTTP.

Controls and guardrails apply to tools/call. The MCP handshake and tools/list stay available so a throttled caller can connect and see only the tools it is allowed to use.

Documented capabilities

Every claim maps to the AISIX MCP Gateway docs

These controls follow the same six-part documentation path you use to configure and verify the product.

One endpoint, namespaced tools

Register enabled Streamable HTTP servers, then expose their tools through one /mcp endpoint. AISIX prefixes each tool as <server>__<tool> so calls route to the correct upstream.

See how aggregation works

Gateway-side upstream authentication

Keep upstream credentials out of agents. Configure no auth, bearer, x-api-key, or OAuth 2.0 client credentials per registered MCP server.

Review authentication modes

Tool access that starts closed

A caller key with no allowed_tools grant sees and calls no tools. Grant one exact tool, a server namespace, or every tool—and recheck authorization before every upstream call.

Configure tool access

Limits for runaway tool loops

Apply request-rate and concurrency limits to tools/call through the caller API key. In managed deployments, shared budget decisions can also stop a call before AISIX contacts upstream.

Set MCP traffic controls

Guardrails in both directions

Inspect arguments before a tool runs and inspect text results before they return. A blocked input never reaches upstream; a blocked result is withheld as an MCP protocol error.

Inspect guardrail behavior

Tool-level operational signals

Measure call volume and failures with usage events that identify the caller, server, tool, outcome, timing, and guardrail decision, plus Prometheus metrics that distinguish MCP traffic.

Observe MCP tool calls

From server to governed tool

Connect an MCP client in three steps

Self-hosted and managed deployments use the same /mcp client path and tool-access concepts. The management surface and available policy controls differ: managed deployments add budget enforcement and finer guardrail scoping.

Register an upstream server

Give the Streamable HTTP server a display_name, URL, authentication mode, and timeout.

Grant the caller only the tools it needs

Attach exact names such as github__create_issue or a server-scoped pattern such as github__* to allowed_tools.

Point the MCP client at AISIX

Connect to /mcp with the caller API key. Discovery returns only permitted tools, and every tool call is checked again.

Open the complete quickstart

mcp-client.json

{
  "mcpServers": {
    "aisix": {
      "url": "https://gateway.example/mcp",
      "transport": "Streamable HTTP",
      "headers": {
        "Authorization": "Bearer sk-caller"
      }
    }
  }
}

Client field names vary. The stable contract is the AISIX /mcp URL plus the caller API key header.

One caller boundary

Govern models, MCP tools, and A2A agents together

One AISIX caller API key can define the models a caller may use, the namespaced MCP tools it may discover and call, and the A2A agents it may reach. MCP tool calls use the same policy and telemetry boundary without pretending tool traffic carries model tokens or model cost.

Explore AISIX AI Gateway

Caller API key

Allowed modelsAllowed MCP toolsAllowed A2A agents

FAQ

Precise answers for the production path

Product behavior below follows the current AISIX MCP Gateway documentation—not generic gateway assumptions.

What does the AISIX MCP Gateway do?

AISIX AI Gateway fronts registered Streamable HTTP MCP servers through one /mcp endpoint. It authenticates callers, filters tool discovery, checks tool access, applies traffic controls and guardrails to tool calls, authenticates upstream, and records MCP usage telemetry.

Which MCP transport does AISIX support upstream?

Registered upstream MCP servers must use Streamable HTTP. AISIX does not document stdio-to-HTTP conversion as an MCP Gateway capability.

Can each caller be limited to specific MCP tools?

Yes. The caller API key carries allowed_tools grants. You can grant one exact namespaced tool, every tool on one registered server, or all tools. A key with no grants cannot list or call MCP tools.

Does the MCP client receive upstream server credentials?

No. The caller API key authenticates the client to AISIX and is not forwarded upstream. AISIX keeps the configured upstream credential gateway-side and supports no authentication, bearer tokens, API keys, and OAuth 2.0 client credentials.

Are initialize and tools/list rate-limited or scanned?

No. Request-rate limits, concurrency limits, and guardrails apply to tools/call. In managed deployments, shared budget checks also apply. A throttled caller can still connect and list the tools its key is allowed to see.

What do MCP usage events contain?

Usage events identify the caller API key, registered server, upstream tool, status, latency, guardrail outcome, request ID, and timestamp. They do not contain tool arguments or results, and MCP token and cost fields remain zero.

Do guardrails store MCP tool arguments or results?

No. AISIX inspects tool arguments and text results in flight. The MCP Gateway guardrail path does not store that content; content capture is a separate surface.

Your next MCP call

Put one governed endpoint between agents and tools

Start with the MCP quickstart Talk to an expert

AISIX on GitHub ↗Read all MCP Gateway docs