Servers in production need three classes of observability. Each is cheap to add early and painful to retrofit later.
- Server-side structured logs. JSON-lines on stderr (or a sidecar file) with at minimum: timestamp, request id, method, latency, success/error. This is your incident-investigation source of truth.
- Protocol-level logging. MCP defines a
loggingcapability: when both sides advertise it, the client can subscribe to logs and the server emits them asnotifications/messageevents. Useful when debugging integration issues from the host side. - Metrics and tracing. Counter for tools/call by name and outcome; histogram for latency; tracing span per request that propagates through any HTTP calls your tools make. OpenTelemetry is the safe default; the per-tool counter is the single most useful chart you will build.
The piece that catches new operators is the audit log from the security track. Audit logs are distinct from observability logs: they are append-only, immutable, and meant for compliance / forensics rather than debugging. Keep the two streams separate (different files, different rotation policies) so you don't lose audit data to a routine log-purge cron.