Skip to main content

Documentation Index

Fetch the complete documentation index at: https://tyk.io/docs/llms.txt

Use this file to discover all available pages before exploring further.

When Tyk Gateway processes an MCP request, it adds four MCP-specific fields to the structured access log record for that request. These fields let you filter, aggregate, and analyze MCP traffic in your log management tooling using the same access log pipeline you use for REST APIs. For an overview of all MCP observability signals, see MCP observability.

​
Prerequisites

Access logging must be enabled in your Tyk Gateway configuration. Set access_logs.enabled to true in tyk.conf: 
{
  "access_logs": {
    "enabled": true
  }
}

​
MCP fields

The following fields are added to access log records for MCP requests. Each field is only included when it has a non-empty value; fields are omitted from the record entirely when not applicable, keeping log volume low on lifecycle calls such as initialize and ping.
FieldTypeDescription
api_typestringAPI protocol type. Always mcp for MCP requests.
mcp_methodstringJSON-RPC method invoked, for example tools/call or resources/read. Present on all MCP requests.
mcp_primitive_typestringMCP primitive category: tool, resource, or prompt. Present only when a primitive was matched.
mcp_primitive_namestringName of the specific tool, resource, or prompt invoked, for example get_current_weather. Present only when a primitive was matched.
mcp_error_codeintegerGateway-mapped JSON-RPC error code. Present only when the request failed at the gateway layer.
The mcp_error_code field reflects errors that occur within the gateway: authentication failures, rate limit rejections, and upstream errors. It does not capture error codes from within the upstream MCP server’s JSON-RPC response body.
Error codeMeaning
-32001Authentication required
-32002Access denied
-32003Rate limit exceeded
-32004Upstream error (502/503/504)
-32600Invalid request (400)
-32603Internal error (500)

​
Configuring which fields to include

By default, when access logging is enabled, all available fields are included in each log record. To restrict the fields logged, set a template array in access_logs: 
{
  "access_logs": {
    "enabled": true,
    "template": [
      "client_ip",
      "api_id",
      "api_name",
      "api_type",
      "method",
      "path",
      "status",
      "latency_total",
      "mcp_method",
      "mcp_primitive_type",
      "mcp_primitive_name",
      "mcp_error_code"
    ]
  }
}
When a template is configured, only the listed fields appear in each log record. Fields in the template that have no value for a given request are omitted.

​
Example log records

A successful tools/call request produces a record similar to the following: 
{
  "api_id": "my-weather-mcp",
  "api_name": "Weather MCP Proxy",
  "api_type": "mcp",
  "client_ip": "10.0.0.42",
  "latency_total": 312,
  "method": "POST",
  "mcp_method": "tools/call",
  "mcp_primitive_name": "get_current_weather",
  "mcp_primitive_type": "tool",
  "path": "/mcp",
  "prefix": "access-log",
  "status": 200
}
A request that fails at the gateway due to a missing or invalid key produces a record with mcp_error_code set and no primitive fields (the primitive was never reached): 
{
  "api_id": "my-weather-mcp",
  "api_type": "mcp",
  "client_ip": "10.0.0.42",
  "latency_total": 4,
  "method": "POST",
  "mcp_error_code": -32001,
  "mcp_method": "tools/call",
  "path": "/mcp",
  "prefix": "access-log",
  "status": 401
}
An initialize lifecycle call produces a record with mcp_method set but no primitive fields: 
{
  "api_id": "my-weather-mcp",
  "api_type": "mcp",
  "client_ip": "10.0.0.42",
  "latency_total": 18,
  "method": "POST",
  "mcp_method": "initialize",
  "path": "/mcp",
  "prefix": "access-log",
  "status": 200
}