The Pipeline
Every MCP request passes through a chain of interceptors before reaching the upstream server. Responses pass through the same chain in reverse:| Interceptor | Priority | What It Records | Failure Mode |
|---|---|---|---|
| Trace | 0 (first) | OpenTelemetry spans with trace/span IDs, request/response payloads, duration | Fail open |
| Logging | 75 | Structured log entries for every request/response | Fail open |
| Audit | 75 | Security audit events with severity, outcome, and principal | Fail closed (response) |
| Metrics | 100 (last) | Request counters, latency histograms, error rates | Fail open |
Failure Modes
- Fail open — The interceptor absorbs errors silently. A trace storage failure won’t block your MCP request. Observability should never break your workflow.
- Fail closed — Errors propagate and block the operation. The audit interceptor fails closed on response recording to ensure complete audit trails for compliance.
- BeforeRequest — Any error from any interceptor in the request phase blocks the request entirely. The request never reaches the upstream server.
Where Data Lives
By default, all observability data is stored in a local SQLite database:- Trace records — Every MCP operation with full request/response payloads
- Audit events — Security-relevant events with severity and outcome
- Metrics — Aggregated performance data
Viewing Data
Hub Sync
When connected to Ultra Hub, traces and audit events are automatically synced to the cloud for team-wide visibility. Local storage is always maintained regardless of Hub connectivity.What Gets Recorded
MCP Operations
| Operation Type | Triggered By |
|---|---|
tool_call | AI agent calls an MCP tool |
resource_read | AI agent reads an MCP resource |
prompt_get | AI agent retrieves an MCP prompt |
tool_list | Client lists available tools |
resource_list | Client lists available resources |
prompt_list | Client lists available prompts |
For Every Operation
- Trace ID and Span ID — OpenTelemetry-compatible identifiers for distributed tracing
- Upstream server — Which server handled the request
- Tool/resource/prompt name — What was called
- Request payload — The arguments sent
- Response payload — The result returned
- Duration — How long the operation took
- Status — Success or error
- Principal — The MCP client identity