Same gateway you trust for APIs. Now for MCP.

Bring tool-level controls and observability to the remote MCP servers your AI agents are already calling.
On the platform your team already runs.

10+ years

Governing protocols at enterprise scale

NatWest, Capital One +

Production deployments at Tier-1 banks

SOC2 & ISO compliant

Trusted by regulated buyers

THE PROBLEM

MCP is hitting production. Your API controls don't reach it.

Remote MCP servers are HTTP services. Without a gateway in front of them, they accumulate the same risks any ungoverned service does, with one extra dimension: a single MCP server typically exposes dozens of tools with very different cost and risk profiles. list_files is cheap. execute_sql is expensive. send_email is irreversible. Sharing one rate limit across all three is a production incident waiting to happen.

Authentication is fragmented

Each MCP server implements its own auth, or none. There is no central place to issue credentials, enforce access, or revoke instantly when an agent or employee is offboarded.

Access is binary

An agent either has access to a server or it does not. There is no way to say "this agent can read but not delete" without running separate servers per role, which multiplies infrastructure.

No cost or risk control at the tool level

A poorly behaved or compromised agent can call expensive, irreversible operations with no throttle. There is no mechanism to protect high-value actions from high-volume noise.

Zero visibility

No standard way to see which agents are calling which tools, how often, or where failures occur. Compliance teams cannot audit. SREs cannot triage.

What Tyk MCP Gateway does

One control plane in front of every remote MCP server.

Tyk sits in front of remote MCP servers and applies authentication, granular access control, per-tool rate limiting, and full observability to every JSON-RPC request. MCP proxies are managed alongside your existing REST and GraphQL APIs in the same Dashboard, using the same policies and the same key management.

There is no separate system to operate. No new team to hire. The platform and security teams already using Tyk get MCP governance as a native capability on the infrastructure they already run.

What Tyk MCP Gateway does

Four reasons enterprise teams choose Tyk for MCP.

01

TRUST TRANSFER

The team already
managing your APIs.

A decade governing REST, SOAP, GraphQL, gRPC and streaming. MCP is incremental.

02

UNIFIED MANAGEMENT

One control plane across
REST, GraphQL, & MCP.

MCP proxies in the same Dashboard, with the same policies and keys as your existing APIs.

03

GRANULARITY

Tool-level control, not
protocol-level approximation.

API-level rate limiting is too blunt for AI agents. Tyk applies controls per tool and per consumer.

04

SOVEREIGNTY

Runs in any environment
your data must stay in.

On-prem, any cloud, or polycloud. Regulated buyers don’t compromise on data residency to govern AI agents.

What’s shipping today

Available today

Configurable through the Dashboard, the Tyk Operator, or the management API.

Capability
Detail
Proxy management
Full create, read, update, delete via Dashboard and API. Same model as REST and GraphQL APIs.
Authentication
Bearer token, API key, JWT, OAuth 2.0, mTLS. All Tyk auth methods apply to MCP.
OAuth 2.1
Native implementation with Protected Resource Metadata. Spec-compliant clients self-configure.
Tool-level rate limiting
Five independent levels per consumer: policy global, per proxy, per method, per tool, per resource or prompt.
Per-consumer RBAC
Proxy, method, and primitive level. Allow and block lists with regex support.
Filtered discovery
tools/list, resources/list, prompts/list responses scoped per consumer policy.
Observability
Dashboard analytics by proxy and primitive. OpenTelemetry metrics and structured access logs with MCP-specific fields.
Traffic management
Circuit breakers, request size limits, header transforms per tool, resource, or prompt.
Upstream auth (Enterprise)
OAuth 2.0 client credentials for OAuth-protected upstream MCP servers.
Deployment
Cloud, self-hosted, or hybrid. Same MDCB-managed clusters as your existing APIs.
Tyk Operator
MCP proxies and policies as Kubernetes CRDs. GitOps-driven deployment and lifecycle management.

HOW IT WORKS

One proxy, many agent roles, no new infrastructure.

A single policy grants a read-only agent access to a weather MCP proxy, restricts it to specific tools, limits its overall call volume, and applies a tighter limit on the expensive generate_forecast tool.

What it can do:

Up to 200 calls per minute to this proxy. get_current_weather shares that budget. generate_forecast has a separate, tighter budget of 10 calls per minute.

What this agent sees:

When it calls tools/list, Tyk returns three tools, not the full upstream catalogue. The other tools on the server are invisible because the agent has no entitlement to them.

What happens at the limit:

When generate_forecast hits 10 calls, the agent receives a 429 on that tool only. The other tools continue to work.

policy.json
Weather Agent — Standard Tier
{
  "name": "Weather Agent — Standard Tier",
  "rate": 1000, "per": 60,
  "access_rights": {
    "{proxy-id}": {
      "limit": { "rate": 200, "per": 60 },
      "json_rpc_methods_access_rights": {
        "allowed": ["tools/call", "tools/list"]
      },
      "mcp_access_rights": {
        "tools": {
          "allowed": ["get_current_weather", "search_weather", "generate_forecast"]
        }
      },
      "mcp_primitives": [
        {
          "type": "tool",
          "name": "generate_forecast",
          "limit": { "rate": 10, "per": 60 }
        }
      ]
    }
  }
}

HOW IT COMPARES

The right depth, on the right surface.

Two categories of vendor are entering the MCP space. Both have structural limits.

OPTION A

MCP-native gateways

Purpose-built for MCP capabilities, not Enterprise needs. Often fast-moving and feature-rich within their narrow surface.

Govern MCP only

REST and GraphQL APIs sit outside their scope

Adds a separate platform, separate team, separate audit trail

Structural limit:
Narrow surface area.

OPTION B

Traditional API gateways

Already in your estate. Most have announced MCP proxying and basic auth.

API-level rate limiting only, not tool-level

Filtered discovery is rare and partial

Tool-level granularity requires JSON-RPC body parsing, not a config flag

Structural limit:
Depth at the policy layer.

TYK

One platform, full depth.

Ten years of API gateway expertise applied to MCP, on the same control plane as your REST and GraphQL APIs.

Per-tool rate limiting with independent consumer counters

Per-consumer filtered discovery across tools, resources & prompts

Unified Dashboard, policies and keys across every protocol

No structural limit.
One platform, one team.

WHERE IT SITS IN THE STACK

MCP Gateway and AI Studio:
the full stack for governing AI.

AI Studio governs what happens inside the LLM loop: models, tokens, cost, and agent tool orchestration. MCP Gateway governs the infrastructure underneath the tools themselves: securing, observing, and rate-limiting the MCP servers those tools call. Most enterprise customers will run both, because the two layers answer different questions.

Tyk MCP Gateway
Tyk AI Studio
Primary concern
Govern traffic to remote MCP servers
Govern LLM usage, cost, and agent tooling
What it sees
Requests, JSON-RPC methods, primitives
Tokens, models, tools, spend
Auth model
API keys, OAuth 2.1, JWT, mTLS
OAuth, API keys for LLM providers
Rate limiting
Per-tool, per-consumer, per-method
Per-model, per-budget
Who uses it
Platform engineers, security teams
AI engineers, cost owners

FAQ

The remote MCP server pattern is. Local MCP, which is around 90% of the public landscape today, is not enterprise-fit because it bypasses your infrastructure entirely. Tyk MCP Gateway is built for the remote deployment model, which is HTTP-based and behaves like any other API. That is the pattern enterprise teams are now standardising on.

Yes. The gateway sits in front of your existing remote MCP servers. The upstream servers do not change. Tyk handles authentication, access control, rate limiting, and observability at the gateway layer. Customers have dropped Tyk in front of MCP infrastructure in a single afternoon.

Tyk supports all standard authentication methods: bearer token, API key, JWT, OAuth 2.0, and mTLS. For teams following the MCP spec’s recommended approach, Tyk also implements OAuth 2.1 with Protected Resource Metadata. Spec-compliant clients discover the authorisation server automatically, without any manual configuration. For agents connecting to upstream MCP servers that are themselves OAuth-protected, upstream OAuth 2.0 client credentials are available in the Enterprise edition.

Without a gateway, there is no mechanism for per-consumer access control. Agent access to an MCP server is all-or-nothing. Tyk’s filtered discovery applies each agent’s policy at the gateway layer: when an agent calls tools/list, Tyk returns only the tools, resources, and prompts that agent is entitled to see. The upstream server doesn’t change, and no separate deployment is needed per role.

Four layers. The Dashboard shows request volume, error rates, and latency broken down by proxy and by individual primitive (tool, resource, or prompt), without any custom configuration. Every request also produces a structured access log entry with four MCP-specific fields: mcp_method (the JSON-RPC method), mcp_primitive_typemcp_primitive_name, and mcp_error_code, which you can feed into your SIEM, log aggregator, or compliance pipeline.

For metrics, Tyk emits two MCP-specific OpenTelemetry metrics: tyk.mcp.requests.total, a counter broken down by method, primitive type, primitive name, error code, and HTTP status; and tyk.mcp.primitive.duration, a histogram of upstream execution time per primitive. Route them to Prometheus, Grafana, Datadog, or any OTel-compatible backend.

For tracing, every MCP request produces a distributed trace spanning agent, gateway, and upstream server. MCP-specific attributes (method, primitive type, primitive name, error code, and session ID) are set on each span, so when something fails your SREs can pinpoint whether the issue is at the gateway or upstream in seconds, not hours.

Not to use MCP Gateway. MCP Gateway runs standalone and governs MCP infrastructure on its own. AI Studio governs the LLM loop above the tools. Most enterprises adopting both will run them together because they answer different questions.

Tyk MCP Gateway is fully compliant with MCP spec 2025-11-25, including Streamable HTTP transport and full SSE (Server-Sent Events) support with session continuity across reconnects.

The full feature set, including five-level rate limiting, per-consumer RBAC, filtered discovery and OAuth 2.1 PRM, is in the OSS gateway. Upstream OAuth 2.0 client-credentials auth, for connecting to OAuth-protected upstream MCP servers, as well as the control plane management layer is Enterprise Edition. Talk to us if you want a detailed walk-through against your specific use case.

Tyk Cloud, self-managed on-prem, any cloud, or polycloud. The same deployment model used by our regulated customers in financial services, healthcare and government, because the customer controls where the software and data live.

Tyk MCP Gateway is available as part of the Tyk API Management platform. If you’re an existing Tyk customer, contact your account team. If you’re evaluating Tyk, start with a self-managed trial or request a demo to see the MCP Gateway in action with your own API estate.

Book a demo

Book a demo

Read the docs

Read the docs

See it in production.

A 30-minute demo, walked through by a solutions architect. We’ll show tool-level rate limiting, filtered discovery, and the audit trail your security team will ask for, against your own use case.