Skip to main content

​
MCP context

The mcp context object is available in CEL expressions when processing Model Context Protocol (MCP) requests. It identifies which MCP resource — a tool, prompt, or resource — is being accessed, and which backend target it belongs to.
The mcp object is only present when the request is an MCP request. Exactly one of mcp.tool, mcp.prompt, or mcp.resource will be set, depending on the type of MCP operation being performed.

​
mcp.tool

Present when the MCP request is invoking a tool (for example, tools/call or tools/list).
​
mcp.tool.target
string
The name of the MCP backend target that provides the tool. This corresponds to the name field of the target in your Agentgateway configuration.
mcp.tool.target == "my-mcp-server"
​
mcp.tool.name
string
The name of the tool being invoked.
mcp.tool.name == "read_file"
mcp.tool.name in ["read_file", "list_files", "get_info"]
mcp.tool.name.startsWith("read_")

​
mcp.prompt

Present when the MCP request is accessing a prompt (for example, prompts/get or prompts/list).
​
mcp.prompt.target
string
The name of the MCP backend target that provides the prompt.
mcp.prompt.target == "my-mcp-server"
​
mcp.prompt.name
string
The name of the prompt being accessed.
mcp.prompt.name == "summarize"
mcp.prompt.name in ["summarize", "translate"]

​
mcp.resource

Present when the MCP request is accessing a resource (for example, resources/read or resources/list).
​
mcp.resource.target
string
The name of the MCP backend target that provides the resource.
mcp.resource.target == "my-mcp-server"
​
mcp.resource.name
string
The name or URI of the resource being accessed.
mcp.resource.name == "config.json"
mcp.resource.name.startsWith("public/")

​
Using MCP context in authorization rules

MCP authorization rules are CEL expressions configured under mcpAuthorization.rules. A request is allowed if any rule evaluates to true. 
policies:
  mcpAuthorization:
    rules:
      # Allow anyone to call the 'echo' tool
      - 'mcp.tool.name == "echo"'
      # Only test-user can call 'add'
      - 'jwt.sub == "test-user" && mcp.tool.name == "add"'
      # Any user with a specific nested JWT claim can call 'printEnv'
      - 'mcp.tool.name == "printEnv" && jwt.nested.key == "value"'

​
Examples

Allow a caller to invoke only a safe subset of tools:
mcp.tool.name in ["read_file", "list_files", "get_info"]
Only allow access to tools on a specific MCP server:
mcp.tool.target == "trusted-server"
Combine target and tool name for fine-grained control:
mcp.tool.target == "trusted-server" && mcp.tool.name == "read_file"
Allow any caller to read resources under a public/ prefix:
mcp.resource.name.startsWith("public/")
Admins can call any tool; other users can only call read-only tools:
jwt.role == "admin" || mcp.tool.name.startsWith("read_")
Allow a specific user to call a specific tool:
jwt.sub == "test-user" && mcp.tool.name == "add"
Allow tool access based on a custom JWT claim:
mcp.tool.name == "printEnv" && jwt.nested.key == "value"
Only allow a named prompt for users with a verified identity:
mcp.prompt.name == "summarize" && has(jwt.sub)
Allow read-only operations across tools and resources, deny writes:
mcp.tool.name in ["read_file", "list_files"] ||
mcp.resource.name.startsWith("public/")
Allow a sensitive tool only from internal networks:
cidr("10.0.0.0/8").containsIP(source.address) && mcp.tool.name == "execute_query"

​
Real-world authorization configuration

The following example is taken from the Agentgateway authorization example. It shows how to configure multiple MCP authorization rules that combine mcp and jwt context: 
policies:
  jwtAuth:
    issuer: agentgateway.dev
    audiences:
      - test.agentgateway.dev
    jwks:
      file: ./manifests/jwt/pub-key
  mcpAuthorization:
    rules:
      # Allow anyone to call 'echo'
      - 'mcp.tool.name == "echo"'
      # Only the test-user can call 'add'
      - 'jwt.sub == "test-user" && mcp.tool.name == "add"'
      # Any user with the claim nested.key == "value" can call 'printEnv'
      - 'mcp.tool.name == "printEnv" && jwt.nested.key == "value"'
Rules are evaluated in order and a request is allowed as soon as any rule matches. Put the most permissive rules (like open tools) first and more restrictive rules last for clarity.