How Tyk security policies govern MCP proxy access: which proxies a consumer can reach, which tools and resources they can invoke, and what rate limits and quotas apply, all configured in one place and applied consistently across every key.
Use this file to discover all available pages before exploring further.
A Tyk security policy defines the access rules and usage limits for a consumer. For MCP proxies, policies go beyond the standard rate limit and quota controls available for REST APIs. They let you control access and apply rate limits at the level of individual tools, resources, and prompts, and restrict which JSON-RPC protocol methods a consumer can use at all. This page explains what MCP policies control, how to configure them, and how Tyk merges multiple policies applied to the same key.
A policy is a reusable template applied to one or more API keys. Rather than configuring limits and access rights on each key individually, you define them once in a policy and issue keys that inherit those rules automatically. When you update the policy, every key bound to it picks up the change.For MCP proxies, policies serve three purposes:Controlling access: a policy determines which MCP proxies a consumer key can reach. Without an entry in the policy’s access rights, the consumer receives 403 Forbidden regardless of what key they present.Governing MCP capabilities: beyond proxy-level access, policies let you restrict which JSON-RPC methods a consumer can use and which specific tools, resources, and prompts they can invoke. This lets you give different consumers different views of the same MCP proxy without creating separate proxy definitions.Enforcing usage limits: policies apply rate limits and quotas at multiple levels: across the whole policy, per MCP proxy, per JSON-RPC method, and per named primitive. Each consumer key tracks its own independent counters.
Tyk evaluates access control at three levels, in order:Proxy access: the policy’s access rights list determines which MCP proxies the key can reach. A key can only call a proxy listed in its access rights.JSON-RPC method access (json_rpc_methods_access_rights): controls which protocol-level operations the consumer may use. For example, you can allow tools/call and tools/list while blocking sampling/createMessage. Use an allowed list to restrict to specific methods, or a blocked list to exclude specific methods while permitting all others.Primitive access (mcp_access_rights): controls which specific tools, resources, and prompts the consumer can invoke. Each primitive type (tools, resources, prompts) has its own allowed and blocked list. Values are Go regular expressions, so "internal_.*" matches any tool whose name starts with internal_. A non-empty allowed list acts as an explicit allowlist; blocked entries are excluded from whatever is otherwise permitted.
Rate limits can be applied at four levels within a policy entry for an MCP proxy:Policy global: the top-level rate and per fields on the policy apply across all APIs the key accesses.Per MCP proxy: the limit field inside an access rights entry applies a rate limit specific to calls to that proxy, independent of the consumer’s overall policy rate.Per JSON-RPC method (json_rpc_methods): sets a rate limit for calls using a specific method name, such as tools/call. The counter applies across all tools invoked via that method.Per primitive (mcp_primitives): sets a rate limit scoped to a specific named tool, resource, or prompt. A consumer who exhausts their limit on generate_report is blocked from calling that tool while remaining free to call others.All applicable limits are checked independently on every call. Whichever is exhausted first blocks the request.
A quota sets a maximum total number of calls over a renewal period (daily, weekly, or monthly). A consumer who exhausts their quota receives 429 Too Many Requests until the period resets. Quotas are configured at the policy level using quota_max and quota_renewal_rate. See Quotas for details.
In the Tyk Dashboard sidebar, click Policies then Add Policy.
On the Access Rights tab, find your MCP proxy in the list and click it to add it to the policy.
Expand the proxy’s access rights block. You will see sections for primitive rate limits and access control.
To configure primitive rate limits, click Add Rate Limit. Set the Rate and Per (in seconds) values, then click Add Primitive to associate a named tool, resource, or prompt with that limit. Add multiple primitives to the same group if they share a limit; create separate groups for different limits.
To configure access control for methods and primitives, use the access control tabs within the access rights block. Add tool, resource, prompt, or method names and toggle them between allowed and blocked.
On the Configurations tab, set the policy name, key expiry, and global rate limit.
Create or update a policy via POST /api/portal/policies (create) or PUT /api/portal/policies/{policy-id} (update). The MCP-specific fields sit inside the access_rights entry for each MCP proxy.The following example creates a policy that grants access to a weather MCP proxy, restricts the consumer to read-only methods, limits them to specific tools, and applies per-primitive rate limits:
A consumer key can have multiple policies applied to it. Tyk merges MCP-specific fields as follows:
Rate limits: the most permissive limit wins. If two policies define a limit for the same primitive, the higher rate value is used.
mcp_access_rights and json_rpc_methods_access_rights: allowed lists are merged by union (the consumer gains access to the combined set). blocked lists are also unioned, so a primitive blocked in any policy remains blocked.
Proxy access: the consumer gains access to the union of all proxies listed across all their policies.
A policy takes effect when it is applied to an access key. In the Tyk Dashboard, go to Keys, click Add Key, select the policy from the Apply Policy dropdown, and generate the key. Issue the key to the consumer; they include it in the Authorization header of every MCP request.See Policies for full details.
