Benefits of Tracing MCP Calls Through Agent Gateway

When an agent calls an MCP server and the answer crawls back, everyone blames the model. Agent gateway MCP tracing replaces that argument with a timeline.

Since September 30, 2026, Agent Gateway on the Gemini Enterprise Agent Platform can send traces to Cloud Trace, in Preview. One trace follows a request from your agent through the gateway to tools, other agents and MCP servers. It is built on OpenTelemetry and W3C TraceContext. Below is the setup, then four things you get for it.

Set up agent gateway MCP tracing

Enable the API and give the three Google-managed service agents permission to write spans. If your agent exports its own spans, grant its service account the same role.

gcloud services enable cloudtrace.googleapis.com --project=<project-id>

for SA in \
  "service-<project-number>@compute-system.iam.gserviceaccount.com" \
  "service-<project-number>@gcp-sa-networksecurity.iam.gserviceaccount.com" \
  "service-<project-number>@gcp-sa-agentgateway.iam.gserviceaccount.com"; do
  gcloud projects add-iam-policy-binding <project-id> \
    --member="serviceAccount:${SA}" \
    --role="roles/cloudtrace.agent"
done

Whoever creates the policy needs roles/compute.networkAdmin or roles/compute.admin. Whoever reads traces needs roles/cloudtrace.user.

Now write the telemetry policy and import it.

# tracing-policy.yaml
name: "projects/<project-id>/locations/<region>/telemetryPolicies/mcp-tracing"
displayName: "Tracing policy for Agent Gateway traffic"
targetTelemetry:
  resources:
  - "//networkservices.googleapis.com/projects/<project-id>/locations/<region>/agentGateways/<gateway-name>"
tracingConfiguration:
  samplingRate: 0.01
  parentBasedSampling:
    enabled: true
    samplingRate: 1.0

gcloud beta network-services telemetry-policies import mcp-tracing \
  --source=tracing-policy.yaml \
  --location=<region>

samplingRate is the fraction of requests traced. With parentBasedSampling.enabled: true, the gateway honors the sampled flag in an incoming traceparent header, and the inner samplingRate is the fraction of those pre-sampled requests it traces. Run gcloud beta network-services telemetry-policies describe mcp-tracing --location=<region> to confirm the policy landed. The Agent Gateway monitoring docs cover the rest.

Benefit 1: You can see which hop is slow

The gateway writes a child span for its own processing, and your agent's spans sit above it when the agent exports them. In Trace explorer you get list, timeline and graph views, and you can filter by latency, HTTP status code or request URI.

Compare the networkservices.googleapis.com/agentgateway/total_latencies metric with the span breakdown and you can tell whether the delay is in the gateway or in the downstream tool or MCP server. That matters most for third-party MCP servers, where you can't add instrumentation yourself.

Benefit 2: Logs and traces link both ways

Every gateway request log entry has a trace field shaped like projects/<project-id>/traces/<trace-id>. In Logs Explorer, open an entry and choose View trace details. In Trace, click Show logs to see the gateway request logs for that request.

The trace shows where time went. The log shows what was asked: jsonPayload.agentGatewayInfo.mcpInfo records the MCP method, such as tools/call, and its primary parameter, such as the tool name. To pull every gateway log line for one trace:

resource.type="networkservices.googleapis.com/Gateway"
resource.labels.gateway_name="<gateway-name>"
trace="projects/<project-id>/traces/<trace-id>"

Benefit 3: Production-friendly cost, set once at the gateway

Google recommends a rate of 0.01 or 0.001 for high-traffic production, to balance visibility against ingestion cost. That is one request in a hundred, or one in a thousand. One policy can also attach to several gateways, so a platform team can set the rate once.

The policy lives on the gateway, so you configure it without touching agent code. To check that tracing works at all, temporarily set samplingRate to 1.0.

Benefit 4: Whole traces instead of fragments

If parent-based sampling is off, you can end up with disconnected root traces. With it on, and with your agent passing the W3C traceparent header through an OpenTelemetry SDK, the agent's span and the gateway's child span land in one trace.

If the agent's service account lacks roles/cloudtrace.agent, you only see the gateway child span. Check that first when a trace looks headless.

When it's not worth it

It is Preview. Google's page says Pre-GA features are available as is and might have limited support, so don't hang an SLO on it yet.

Spans only exist for sampled requests. At 0.001, a rare failure often has a log entry but no trace, and the log entry's traceSampled field tells you which case you're in.

Don't expect transcripts either. The gateway page doesn't document span contents, and Google's Agent Platform trace docs say prompts and model responses aren't stored in spans. Plan on timing and structure, and confirm in a real trace. If you have one agent calling one MCP server you own, your own OpenTelemetry spans may be enough.

Gotchas

• If nothing shows up, describe the policy: it must be in the same region as the gateway and reference the right gateway.
• A missing cloudtrace.agent grant on any of the three service agents means missing spans.
• Parent spans only appear if the agent propagates traceparent through an OpenTelemetry SDK.

Gateway traces are cheap to run at low sampling, so when an MCP tool call is slow in production you can name the slow hop instead of guessing.