DocsMCP observability

Operations

MCP observability

Agents need runtime evidence. Observability turns each MCP call into a debuggable event with trace ids, execution modes, status, latency, and structured errors.

Updated Jun 25, 20266 min read

Implementation

Path to ship.

1
Capture initialize, tools/list, search_docs, execute, and tools/call events.
2
Record execution mode, upstream method, upstream status, latency, and trace id.
3
Redact API keys, bearer tokens, cookies, OAuth secrets, and credential query params.
4
Expose enough detail for debugging without leaking upstream secrets or user data.

Guide

What to log

Useful MCP logs show what the agent asked for, which tool handled it, whether the call reached upstream, and what structured result came back. They should also show when policy blocked execution.

Astrail runtime modes make behavior easier to interpret: safe REST execution, Code Mode, website browser runtime, auth required, permission denied, validation failed, and mapping required.

Guide

What not to log

Do not log plaintext credentials, authorization headers, OAuth tokens, cookies, client secrets, or provider API keys. Observability should reduce risk, not create a second secret store.

For production, pair structured logs with dashboard analytics so teams can spot failing tools, slow upstreams, and repeated permission denials.

FAQ

Common questions.

Why do agents need trace ids?

Trace ids let humans connect an agent answer to the exact tool call, runtime decision, upstream status, and log event.

Should denied calls appear in logs?

Yes. Denials are important evidence, especially when the runtime correctly prevented an upstream request.