Skip to main content
When Tyk Gateway proxies MCP traffic, it makes four MCP-specific fields available as metadata dimension sources in custom OTel metric instruments. Use these dimensions to monitor tool call volumes, track latency per primitive, classify gateway errors, and correlate usage to individual sessions, all through the same observability infrastructure you use for your REST APIs. For an overview of all MCP observability signals, see MCP observability.

MCP fields reference

The following fields are derived from the JSON-RPC payload and available as metadata dimension sources in custom metrics. All four fields are populated only for MCP APIs. For non-MCP requests they are empty strings, so existing metric instruments are unaffected.
mcp_error_code reflects errors mapped by the gateway layer (authentication failures, rate limit rejections, and upstream errors), not error codes in the upstream MCP server’s JSON-RPC response body. See MCP access logs for the full list of gateway error codes.

Use cases

The examples below use Tyk’s custom metrics system. Each instrument is a JSON object in the opentelemetry.metrics.api_metrics array in tyk.conf.

MCP traffic volume by method

Track how many requests each JSON-RPC method receives across all MCP APIs. This shows the distribution of tools/call, initialize, resources/read, and other operations.

Top tools by call volume

Identify the most frequently invoked tools, useful for cost attribution and optimization. Add api_id to compare usage across multiple MCP backends.

Tool execution latency: upstream

Measure how long the upstream MCP server takes to respond per tool. Use this to identify slow tools and performance regressions; this measurement excludes gateway overhead.

Total request duration with MCP labels

Measure end-to-end latency (client → gateway → upstream → client) with MCP labels attached. Compare this with upstream latency to quantify gateway overhead.
The histogram_source field accepts three values: "upstream" (upstream server latency only), "total" (end-to-end including gateway), and "gateway" (gateway processing time only, excluding upstream). Use "gateway" to isolate gateway overhead.

JSON-RPC error classification

Count MCP errors by their gateway-mapped JSON-RPC error code. Unlike HTTP errors, MCP errors are typically returned with HTTP 200; mcp_error_code is the only reliable way to detect gateway-layer failures.
Filter this instrument in your metrics backend to exclude the empty error_code value (successful requests), or add a status_codes filter if your upstream signals errors via HTTP status.

Per-session tool usage

Correlate tool call volume to individual MCP sessions using the authenticated session alias. Use this to identify heavy users, debug specific sessions, or allocate costs to teams.
alias is the human-readable key alias set on the API key or OAuth token. If your sessions are identified differently (for example, via a JWT claim), use the context source with the appropriate jwt_claims_<name> key instead.

Multi-API MCP backend comparison

Compare performance across multiple MCP backends by including api_id alongside tool dimensions. Use this to determine whether the same tool performs differently on different upstream MCP servers.

Session efficiency

Measure the ratio of productive tools/call operations to session lifecycle calls (initialize). A low ratio may indicate clients that open sessions but make few tool calls, useful for detecting misconfigured AI clients or idle connections.
To compute efficiency, query your metrics backend for the ratio of tools/call to initialize counts:

Complete configuration example

Add the following to tyk.conf. This covers all the instruments needed for the Grafana dashboard panels:
The tyk.mcp.requests.total counter uses 6 dimensions. Keep the total dimension count at 10 or fewer per instrument to stay on the OTel SDK fast path. See Performance Considerations for guidance.