Conversations over MCP: what actually happened to one request New in 1.16.0
Follow one request across a CritterWatch-monitored fleet with the list_conversations / get_conversation MCP tools (and the cw-conversations CLI): every message it caused, which handler failed, what that cascaded into, and where the time went.
Use when a Bobcat spec failed and you need the causal chain behind it, when a production request failed and you want a Bobcat spec that reproduces it, or when asked 'what actually happened to this order / request / correlation id'. Covers finding a conversation (by correlation id, conversation id or W3C trace id; matchedBy), the OpenTelemetry trace tools beside them (query_recent_traces, get_trace, check_trace_provider_health), reading hops, observed vs inferred edges and the timeline's gaps, the completeness discipline (never present a possibly-partial chain as whole), the mcp.conversations.read capability and its per-service scope, the two flows between Bobcat and CritterWatch, and anonymising production data in a spec.
Skill details
- Skill name:
wolverine-integrations-critterwatch-conversations - Applies to:
wolverine,marten,polecat,fisher - Tags:
observability,critterwatch,mcp,conversations,correlation,tracing,causation,bobcat,sdd,diagnostics,agents,cli - Added in: 1.16.0
- License: Proprietary. Copyright JasperFx Software LLC.