Skip to main content

​
The basics

​
Do I need to modify my MCP server to use Tyk?

No. Tyk sits in front of your existing MCP server as a reverse proxy. Your upstream server does not need to know about Tyk; it receives standard MCP requests over HTTP and responds normally. All authentication, access control, rate limiting, and observability are applied at the gateway layer.

​
Does Tyk work with both local and remote MCP servers?

Tyk is designed for remote MCP servers: servers reachable over HTTP or HTTPS from the gateway. If your MCP server currently runs locally over stdio (the standard desktop configuration), you will need to either deploy it as an HTTP service or use one of the available stdio-to-HTTP bridge tools to expose it as a remote endpoint before Tyk can proxy it.

​
Do I need to build or host an MCP server at all?

Not necessarily. Tyk can generate an MCP proxy from a Tyk OAS REST API that is already onboarded to Tyk. See REST API to MCP. If you don’t have a Tyk Gateway deployment and just want to turn an OpenAPI spec into a standalone MCP server for local use, for example with Claude Desktop or Cursor, see the api-to-mcp CLI tool instead. It has no gateway-level authentication, access control, or observability of its own.

​
Which transport methods does Tyk support?

Tyk supports only the Streamable HTTP transport (POST /mcp and GET /mcp). It does not support stdio or the legacy HTTP+SSE transport. For details, see Transport.

​
What MCP protocol versions does Tyk support?

Tyk passes the MCP-Protocol-Version header through to the upstream unchanged; version negotiation is handled between the client and the upstream MCP server. The current MCP specification version is 2025-11-25. See MCP proxy definition for details on configuring the proxy definition.

​
Can Tyk proxy multiple MCP servers?

Yes. Each remote MCP server gets its own MCP proxy definition in Tyk, with its own listen path, upstream URL, authentication configuration, and middleware. An AI agent that needs to reach GitHub’s MCP server and an internal database tools server connects to two separate Tyk endpoints, each governed independently. There is no limit on the number of MCP proxies you can create.

​
Can one REST API back multiple MCP proxies?

Yes. A single Tyk-managed REST API can serve as the source for multiple REST API-to-MCP proxies, each with its own tool selection, enrichment, and policies. This is useful for slicing a large API into smaller, purpose-built tool catalogs, for example, giving a read-only reporting agent a proxy exposing only GET operations, and a separate proxy with write access for an operations agent. See How to slice one API into multiple MCP proxies.

​
The Dashboard

​
What can I configure for an MCP proxy in the Dashboard?

The MCP Designer has two tabs for a proxy fronting a remote MCP server, and a third for a proxy generated directly from a Tyk-managed REST API. The Settings tab covers core proxy configuration (name, upstream server URL, gateway assignment) and proxy-level middleware that applies to all traffic through the proxy. For a REST API to MCP proxy, the upstream and gateway fields are replaced by a read-only Source API panel, since both are inherited from the source API: The Tool mapping tab (REST API to MCP proxies only) lets you choose which of the source API’s operations are exposed as tools, and override their names, descriptions, and parameters. See Managing MCP proxies: Tool mapping tab. The Primitives tab lists the tools, resources, and prompts defined for this proxy and lets you manage per-primitive middleware (access control, rate limits, timeouts, circuit breakers, and more) without editing the definition directly.

​
What requires editing the proxy definition directly?

The Primitives tab covers most per-primitive middleware. A few options require the definition editor (Actions → View MCP Proxy Definition) or the Dashboard API:
  • Transform request body: advanced request body transformation via Go template
  • middleware.operations: method-level middleware applying to all calls of a specific JSON-RPC method (for example, all tools/call requests)
  • Policy access fields (mcp_access_rights, json_rpc_methods_access_rights): these are in a policy, not in the proxy definition. See MCP Gateway policies
urlRewrite, transformRequestMethod, and mockResponse are accepted by the configuration schema but have no effect on MCP primitives. See MCP middleware for the full capability reference.

​
How do I add middleware to a specific tool, resource, or prompt?

Open the proxy and click the Primitives tab. Click Add Primitive, select the type (Tool, Resource, or Prompt), and enter the name exactly as the upstream MCP server advertises it. Click the primitive in the list to open its detail view, then click Add Middleware. Available middleware includes Allow, Block, Rate Limit, Circuit Breaker, Request Size Limit, Ignore Authentication, Transform Request/Response Headers, Virtual Endpoint, Track Endpoint, Do Not Track Endpoint, and Post Plugins. Each middleware option maps directly to the corresponding field in x-tyk-api-gateway.middleware.mcpTools, mcpResources, or mcpPrompts in the proxy definition.

​
How do I set a rate limit that applies to all consumers of a proxy?

Use the Primitives tab. Add the tool as a primitive, click it, and add Rate Limit middleware. This rate limit applies in aggregate, across all keys calling that tool on this proxy combined. It protects the upstream from overload regardless of which consumer is calling. For per-consumer rate limits, use a security policy instead. See Policies versus middleware.

​
Security

​
Research shows that most public MCP servers have no authentication. How does Tyk address this?

This is one of the most documented problems with the current MCP ecosystem. Studies in 2025 found that a significant proportion of publicly accessible MCP servers had no authentication at all, exposing their full tool catalogs to anyone who could reach the endpoint. Tyk adds authentication in front of your upstream server without requiring any changes to it. All authentication methods Tyk supports for REST APIs (Bearer tokens, API keys, JWT, OAuth 2.0, and mutual TLS) apply identically to MCP. Your upstream server never needs to validate credentials; Tyk does it before the request gets there.

​
How do I stop an AI agent from calling destructive tools?

Put the tools that agents can call on an allowlist. Tyk then blocks every other tool, including new tools that the upstream adds later. See Access control and How to block an MCP tool.

​
Over-permissioning is a known MCP problem. How does Tyk help?

Over-permissioning (agents having access to more tools and data than they need) compounds in the absence of a central control point. When every agent connects directly to every MCP server, there is no practical way to enforce least-privilege access at scale. Tyk makes over-permissioning addressable through three mechanisms:
  1. Per-proxy tool allowlists: configure which tools are accessible through each proxy, regardless of what the upstream server exposes. Applies to all consumers of that proxy.
  2. Security policies: proxy access: issue API keys against policies that grant access only to the specific MCP proxies a given agent needs. An agent that needs GitHub MCP does not automatically have access to your internal database MCP server.
  3. Security policies: primitive ACLs: use mcp_access_rights in the policy access rights entry to restrict which specific tools, resources, and prompts an individual consumer can invoke, without affecting other consumers of the same proxy. This lets you grant two agents access to the same MCP proxy while giving each a different subset of its tools.

​
What happens if an agent’s API key is compromised?

Revoke the key from the Tyk Dashboard under Keys. Access to every MCP proxy that key was permitted to reach is cut off immediately on the next request, with no grace period and no upstream credential rotation required. The upstream MCP server is unaffected; only requests carrying the revoked Tyk key are blocked. If the key was scoped to specific MCP proxies via a policy, other agents on the same policy are not affected.

​
Does exposing my REST API to AI agents via an MCP proxy affect my existing REST API consumers?

No. The MCP proxy is a separate consumer of the REST API, with its own credential and policy. Your existing consumers keep their keys, limits, and access rights. See Proxy Identity and Security.

​
Authentication and OAuth

​
What authentication methods can AI agents use?

Any authentication method Tyk supports for REST APIs also applies to MCP: Bearer tokens (API keys), JWT, OAuth 2.0 (with external token introspection), and mutual TLS. The inbound authentication method is configured per proxy in the server.authentication section of the API definition. For most deployments, Bearer token authentication using Tyk-issued API keys is the simplest starting point. For organizations with an existing OAuth 2.1 identity provider, JWT authentication allows agents to present tokens issued by your IdP directly.

​
Does Tyk support the MCP OAuth 2.1 specification?

Yes. The MCP specification (version 2025-11-25) bases its authorization model on OAuth 2.1 and recommends that MCP servers expose Protected Resource Metadata (RFC 9728) so clients can discover authorization servers automatically. Tyk implements this end-to-end:
  • The /.well-known/oauth-protected-resource endpoint is served natively by Tyk when PRM is enabled, with no upstream changes required.
  • On authentication failure, Tyk includes a WWW-Authenticate: Bearer resource_metadata=... header pointing to the PRM document.
  • OAuth 2.1-aware MCP clients follow this header, discover the authorization server, obtain a token, and retry, without any pre-configuration.
  • On the upstream side, Tyk can acquire and inject OAuth tokens using the client credentials flow (Enterprise Edition), so upstream MCP servers that require OAuth tokens receive them automatically.
See MCP Gateway: OAuth 2.1 authentication for the complete guide.

​
What is Protected Resource Metadata and do I need to configure it?

PRM is the machine-readable discovery document at /.well-known/oauth-protected-resource. It tells OAuth clients which authorization server to use and which scopes the API supports. The MCP specification recommends all MCP servers expose it. You do not strictly need it if you are issuing Tyk API keys manually and configuring agents with the key directly. PRM becomes valuable when:
  • You have many AI agents that should self-configure their auth without manual setup.
  • You are using an OAuth 2.1 identity provider and want agents to obtain tokens automatically.
  • You need to comply with the MCP specification’s authorization recommendations.
Configure it by adding a protectedResourceMetadata block to the proxy’s server.authentication section. See MCP Gateway: OAuth 2.1 authentication (configuring PRM).

​
Our upstream MCP servers each require different credentials. How do we manage that?

Configure the upstream authentication independently per proxy. Tyk supports three patterns:
  • Static token injection: inject a fixed Bearer token (such as a GitHub PAT) into every proxied request via global transformRequestHeaders middleware.
  • OAuth client credentials: have Tyk obtain and refresh an OAuth token from the upstream’s authorization server using configured client credentials (Enterprise Edition).
  • Basic authentication: inject HTTP basic auth credentials via upstream.authentication.basicAuth.
In every case, the agent presents a Tyk credential and Tyk presents the correct vendor credential to the upstream. Agents never need to know about or hold vendor-specific credentials.

​
Sessions and connections

​
MCP is described as stateful. How does Tyk handle sessions?

The MCP protocol establishes sessions identified by an Mcp-Session-Id header. After initialisation, clients include this identifier on every subsequent request so the server can associate them with established session state. Tyk passes the Mcp-Session-Id header through unchanged in both directions. It does not maintain session state itself; session management is an upstream concern. If your upstream MCP server is load-balanced across multiple instances, configure session-aware routing (sticky sessions) in Tyk’s upstream load-balancing settings to ensure requests from the same session consistently reach the same instance.

​
What happens if the SSE connection drops?

The client must reconnect. Tyk does not reconnect the stream for the client. It passes the Last-Event-ID header through to the upstream, which resumes the stream. See Session close.

​
Does Tyk buffer SSE responses?

No. Tyk streams SSE responses to the client without buffering the body. See Transport.

​
Access control

​
What happens when a vendor adds new tools to their MCP server?

If the proxy has a tool allowlist, Tyk blocks the new tools until you add them to the list. If the proxy has no allowlist, agents can call the new tools at once. See Access control.

​
Can I block specific MCP protocol operations for a consumer without affecting others?

Yes. Set json_rpc_methods_access_rights in the consumer’s policy. It applies to each key separately. See Access control.

​
Can I give different agents access to different tools on the same MCP server?

Yes, and there are two approaches depending on how different the access needs to be. Separate proxy definitions work well when agents have clearly distinct roles: for example, a read-only agent and a write-access agent. Create two proxies targeting the same upstream, each with a different tool allowlist. This is straightforward to reason about and administer. Policy-level primitive ACLs (mcp_access_rights) work well when many agents have overlapping but different access needs. See Access control.

​
What happens if two tools on a REST API to MCP proxy end up with the same name?

Tyk validates tool names as it builds the catalog from the source API’s operations. Depending on how the collision arises, it’s either resolved automatically or flagged as a build-time error requiring an explicit name override. See How to resolve tool and parameter collisions.

​
Traffic management

​
Does adding Tyk as a gateway add latency?

Tyk adds a small amount of latency for the middleware chain evaluation, typically 1–5 ms for standard middleware. For most MCP use cases, where tool calls themselves involve network round-trips and computation, this overhead is not significant. The latency that matters is introduced by optional middleware you choose to add: content safety plugins (which involve additional API calls to external services like Bedrock Guardrails) and circuit breakers (which introduce an evaluation step). Each of these is a trade-off you control. Co-locating your Tyk Gateway with your upstream MCP servers in the same network reduces the baseline overhead further.

​
How does rate limiting work for MCP traffic?

Tyk checks every rate limit that applies to a call, and the first limit that the call exceeds blocks it. For the policy levels, see Rate limiting. For the limit shared by all consumers, see Policies versus middleware.

​
Can I set different rate limits on the same tool for different consumers?

Yes. Set mcp_primitives in each tier’s policy. Each key has its own counter. See Rate limiting.

​
What happens when an upstream MCP server is slow or unavailable?

Configure a circuit breaker on the tools that call the problematic server. Tyk monitors the failure rate and temporarily stops forwarding requests to that tool when the error rate exceeds a threshold, giving the upstream time to recover. During the open circuit period, Tyk returns a JSON-RPC error to the agent immediately rather than timing out. Combine this with per-tool timeouts so that a slow upstream response does not stall the entire MCP session. See MCP middleware: circuit breakers and timeouts.

​
Observability

​
What can I see in analytics for MCP traffic?

Tyk records analytics at two levels: proxy level and primitive level. Proxy-level charts (in the Tyk Dashboard under Monitoring → Activity by MCP) show total request volume, error counts, and HTTP error code distribution across all your MCP proxies. Use these to compare traffic and error rates between proxies. Primitive-level charts on the same page break the data down by individual tool, resource, or prompt: call volumes over time, most frequently called primitives, highest error rates, and slowest average latency. These charts let you identify which specific tools agents are using most, which are failing, and which are your performance bottlenecks, without needing external tooling. All MCP analytics appear alongside your REST and GraphQL API data, giving a unified view of the entire API estate. See MCP observability.

​
How do I see which AI agents are calling which tools?

Issue a separate API key per agent (or per agent team). Keys can have an alias set at creation time that identifies the agent. Analytics are reported per key, so filtering by key shows total call volume per agent against each MCP proxy. This is why per-agent key issuance is recommended over shared keys.

​
What MCP-specific information appears in access logs?

Tyk adds four fields to each access log record for an MCP request: mcp_method, mcp_primitive_type, mcp_primitive_name, and mcp_error_code. See MCP fields.

​
Does Tyk export OpenTelemetry metrics for MCP traffic?

Yes. When OpenTelemetry is enabled on the gateway, Tyk emits four MCP-specific metric instruments: These metrics can be scraped by Prometheus and used to build dashboards in Grafana or your preferred metrics platform. See MCP metrics for the full dimension reference and PromQL examples, and How to build a Grafana dashboard for MCP traffic for a step-by-step guide.

​
Can I exclude high-frequency health-check tools from analytics noise?

Yes. Open the proxy, click the Primitives tab, add the tool as a primitive, and add Do Not Track Endpoint middleware to it. Alternatively, add "doNotTrackEndpoint": { "enabled": true } to the tool’s entry in x-tyk-api-gateway.middleware.mcpTools directly. Either way, calls to that tool are excluded from analytics logs and dashboards. See MCP middleware: observability.

​
Governance and enterprise

​
We have developers connecting AI agents directly to MCP servers without oversight. How do we regain control?

This is the shadow IT problem specific to AI agents. Because MCP servers are just HTTP endpoints, developers can point any MCP client at them directly using vendor-issued credentials. The practical approach is to make the Tyk gateway the approved, supported path and deprecate direct connections:
  1. Deploy Tyk proxies for every MCP server your organization uses or permits.
  2. Establish a policy that AI agents must connect via the gateway.
  3. Issue Tyk API keys to authorised agents and revoke or rotate the direct vendor credentials.
  4. Use Tyk analytics to verify that direct connections have dropped to zero.
The governance case for this (central visibility, credential management, access control, audit trail) is covered in How to proxy a remote MCP server through Tyk.

​
How do I apply consistent policies across all MCP servers in my organization?

Create Tyk security policies that span multiple MCP proxies. A single policy can grant access to many proxies and apply a consistent rate limit and quota across all of them. Issuing a key against that policy gives the agent access to every permitted proxy under the same controls. For tool-level rules that apply to all consumers, use the proxy’s middleware. For rules that change by consumer tier, use the policy’s MCP access rights. See Policies versus middleware.

​
Does Tyk provide an MCP service registry?

Yes. The MCP section of the Tyk Dashboard is the central registry of every MCP proxy in your organization. See Managing MCP proxies.

​
Can I generate an MCP proxy from a REST API on all Tyk licenses?

No. Pass-through MCP proxies (fronting a remote MCP server) are available on all Tyk Gateway licenses; specific features, such as upstream OAuth and token exchange, require Tyk Enterprise Edition. An MCP proxy over an upstream REST API requires Tyk Enterprise Edition. See MCP Gateway overview: Requirements for the full licensing table.

​
Do we need a separate Tyk instance for MCP or can it share infrastructure with our REST APIs?

MCP proxies are managed through the same Tyk Gateway and Dashboard instance as your REST and GraphQL APIs. They use the same configuration model, the same policy engine, and produce analytics in the same Dashboard. No separate infrastructure is required. The only constraint is that MCP proxy definitions require Tyk OAS format. They cannot be created as Tyk Classic API definitions.