Observability that preserves privacy

The mechanism

Useful telemetry answers which operation ran, under which policy decision, for how long and with what outcome. It does not require copying every prompt, bearer token or tool result into a shared log. Start with metadata and add payload capture only under a deliberate, access-controlled policy.

Correlate the host’s user task, protocol attempt and business operation using separate identifiers. One task may involve several requests; one intended write may survive retries. Flattening these into a single ID makes incidents harder to reconstruct.

The current protocol deprecates its older logging feature for new implementations. Use application logging and supported observability systems appropriate to the runtime. For stdio, keep diagnostics on stderr so observability cannot corrupt the protocol stream.

Worked example

This is a synthetic log event schema. It records a decision and outcome without storing incident text, secrets or raw authorization headers. Counts and durations remain null until an actual run produces them.

{"task_id":"demo-task-1","request_id":8,"intent_id":null,
 "method":"tools/call","tool":"lookup_incident",
 "policy":"read-only-fixtures-v1","decision":"allow",
 "outcome":"not_run","duration_ms":null,"result_bytes":null,
 "payload_logged":false}

Practice: predict, inspect, explain

Offline exercise. Build a three-event trace for allowed lookup, denied write and timed-out read. For each event, identify which fields are needed for debugging and which would leak private content. Then ask whether a reviewer can distinguish an attempted operation from an executed one.

Expected observation: the trace should support a causal explanation without exposing the record. Add retention, access and deletion decisions to the telemetry design. A correlation ID helps only if you can follow it across the relevant trusted components.

Troubleshooting and trade-offs

If a dashboard counts every HTTP 200 as success, it misses tool errors and application failures. If a denial log records the entire forbidden payload, the logging system becomes another disclosure surface. Track latency distributions and failure categories with clear denominators. Do not label sample events or illustrative traces as production measurements.

Interview practice

Completion check

Explain one denied and one completed operation from metadata-only synthetic traces.

Sources and version notes

This edition targets MCP 2026-07-28, checked 6 October 2026. SDK examples are version-sensitive and labelled when not executed. Synthetic fixtures are learning material, not protocol conformance evidence.

• Official documentation: Logging
• Official documentation: Debugging
• Official documentation: Progress