MCP Gateway Access Logs

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. See Enabling Access Logs.

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.

Field	Type	Description
`api_type`	string	API protocol type. Always `mcp` for MCP requests.
`mcp_method`	string	JSON-RPC method invoked, for example `tools/call`, `resources/read` or `server/discover`. Present on all MCP requests.
`mcp_primitive_type`	string	MCP primitive category: `tool`, `resource`, or `prompt`. Present only when a primitive was matched.
`mcp_primitive_name`	string	Name of the specific tool, resource, or prompt invoked, for example `get_current_weather`. Present only when a primitive was matched.
`mcp_error_code`	integer	JSON-RPC error code of a failed request. Present only when the request failed.

The mcp_error_code field holds the code of Tyk’s own error, or, when the upstream MCP server returns a JSON-RPC error, the code from its response. Tyk’s codes depend on the protocol version the request uses. See MCP Error Codes for the full list.

Access Logs When the Proxy Fronts a Tyk-Managed REST API

When an MCP proxy is generated directly from a Tyk-managed REST API rather than fronting a remote MCP server, a single tools/call request produces two separate access log entries when access logs are enabled on the Gateway. The first entry is for the MCP proxy request itself, and carries the MCP fields described above. The second is for Tyk’s internal call into the paired source REST API, dispatched through the gateway’s standard request handling. That second entry has no MCP fields at all: its api_type reflects the source API’s own type (oas for a Tyk OAS API), and it is otherwise indistinguishable from a request made directly against that API.

{
  "api_id": "orders-mcp",
  "api_name": "Orders MCP Proxy",
  "api_type": "mcp",
  "client_ip": "10.0.0.42",
  "latency_total": 187,
  "method": "POST",
  "mcp_method": "tools/call",
  "mcp_primitive_name": "get_order_status",
  "mcp_primitive_type": "tool",
  "path": "/mcp",
  "prefix": "access-log",
  "status": 200,
  "trace_id": "4bf92f3577b34da6a3ce929d0e0e4736"
}

{
  "api_id": "orders-rest",
  "api_name": "Orders REST API",
  "api_type": "oas",
  "client_ip": "10.0.0.42",
  "latency_total": 142,
  "method": "GET",
  "path": "/orders/{id}/status",
  "prefix": "access-log",
  "status": 200,
  "trace_id": "4bf92f3577b34da6a3ce929d0e0e4736"
}

If OpenTelemetry tracing is enabled alongside access logging, both entries carry the same trace_id: Tyk dispatches the internal call to the source API within the same trace as the originating MCP request, so the two entries are spans of one trace rather than unrelated hits. Without tracing enabled, there is no shared identifier between the two entries, so correlate them by timestamp. The proxy’s own latency_total includes the time spent on the source API call, so it is always the larger of the two figures.

This dual-record pattern isn’t unique to access logs. The Dashboard’s MCP analytics charts, and the Tyk Pump analytics pipeline underneath them, follow the same rule: only the MCP proxy’s own record is recorded as MCP traffic, so the source API’s analytics include this internal traffic indistinguishably alongside any direct hits it receives. See Tyk Pump for how analytics records are processed and stored.

Configuring Which Fields to Include

By default, each record includes all available fields. To log only some fields, use an access log template. See Access Log Templates. Add api_type and the four mcp_ fields to the template to keep the MCP detail.

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. Tyk reads the JSON-RPC body before it checks the key, so the record also has the primitive fields:

{
  "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",
  "mcp_primitive_name": "get_current_weather",
  "mcp_primitive_type": "tool",
  "path": "/mcp",
  "prefix": "access-log",
  "status": 401
}

For a request that uses 2026-07-28, the same failure records -33001. An initialize lifecycle call produces a record with no mcp_primitive_type. Its mcp_primitive_name is the method name:

{
  "api_id": "my-weather-mcp",
  "api_type": "mcp",
  "client_ip": "10.0.0.42",
  "latency_total": 18,
  "method": "POST",
  "mcp_method": "initialize",
  "mcp_primitive_name": "initialize",
  "path": "/mcp",
  "prefix": "access-log",
  "status": 200
}

Overview

MCP Gateway

AI Studio

Prerequisites

MCP Fields

Access Logs When the Proxy Fronts a Tyk-Managed REST API

Configuring Which Fields to Include

Example Log Records

​Prerequisites

​MCP Fields

​Access Logs When the Proxy Fronts a Tyk-Managed REST API

​Configuring Which Fields to Include

​Example Log Records

Prerequisites

MCP Fields

Access Logs When the Proxy Fronts a Tyk-Managed REST API

Configuring Which Fields to Include

Example Log Records