Collapse navigation tree

Collapse

Monitor MCP Server Activity

After creating an MCP server, you can monitor its activity using the execution log.

After reading this page, you will be able to:

  • Consume traces from the execution log

  • Track tool invocations and measure performance

  • Debug tool failures using trace data

For conceptual background on traces, spans, and the trace data structure, see Execution log and observability.

Prerequisites

You must have an existing MCP server. If you do not have one, see Remote MCP Server Quickstart.

Consume traces from the execution log

MCP servers emit OpenTelemetry traces to the redpanda.otel_traces topic. You can consume these traces using any Kafka-compatible client or the Redpanda Cloud Console.

  • Cloud Console

  • rpk

  • Data Plane API

  1. In the Redpanda Cloud Console, navigate to Topics.

  2. Select redpanda.otel_traces.

  3. Click Messages to view recent traces.

  4. Use filters to search for specific trace IDs, span names, or time ranges.

Consume the most recent traces:

rpk topic consume redpanda.otel_traces --offset end -n 10

Filter for specific MCP server activity by examining the span attributes.

Use the Data Plane API to programmatically consume traces and integrate with your monitoring pipeline.

Track tool invocations

Monitor which tools are being called and how often:

  1. Consume traces from redpanda.otel_traces.

  2. Filter spans where instrumentationScope.name is rpcn-mcp.

  3. Examine the name field to see which tools are being invoked.

  4. Calculate frequency by counting spans per tool name over time windows.

Example: To find all invocations of a specific tool, filter for spans where name matches your tool name (for example, weather, http_processor).

Measure performance

Analyze tool execution times:

  1. Find spans with instrumentationScope.name set to rpcn-mcp.

  2. Calculate duration: (endTimeUnixNano - startTimeUnixNano) / 1000000 (milliseconds).

  3. Track percentiles (p50, p95, p99) to identify performance issues.

  4. Set alerts for durations exceeding acceptable thresholds.

Example: A span with startTimeUnixNano: "1765198415253280028" and endTimeUnixNano: "1765198424660663434" has a duration of 9407ms.

Debug failures

Investigate errors and failures:

  1. Filter spans where status.code is 2 (error).

  2. Examine status.message for error details.

  3. Check the events array for error events with timestamps.

  4. Use traceId to correlate related spans and understand the full error context.

  5. Follow parentSpanId relationships to trace the error back to the originating tool.

Example: A span with status.code: 2 and status.message: "connection timeout" indicates the operation failed due to a timeout.

Correlate distributed operations

Link MCP server activity to downstream effects:

  1. Extract traceId from tool invocation spans.

  2. Search for the same traceId in other application logs or traces.

  3. Follow parentSpanId relationships to build complete operation timelines.

  4. Identify bottlenecks across your entire system.

Integrate with observability platforms

The redpanda.otel_traces topic stores trace data in OpenTelemetry format. Redpanda does not support direct export to platforms like Grafana Cloud and Datadog due to format compatibility limitations. Redpanda produces one span per topic message, whereas these platforms expect traces in batch format.

You can consume traces directly from the redpanda.otel_traces topic using any Kafka-compatible consumer for custom analysis and processing.

Next steps