The Model Context Protocol, commonly known as MCP, gives AI applications a standardized way to connect with external tools, APIs, databases, files, and other data sources.

A typical MCP interaction looks simple:

User
  → AI application or agent
    → MCP client
      → MCP server
        → Tool or resource
          → Database, API, file system, or cloud service

For example, a user may ask an AI assistant:

Show me the delayed orders for customer 4821.

The AI application can use an MCP client to discover an appropriate tool, invoke that tool on an MCP server, retrieve information from an order database, and use the result to answer the user.

During local development, this may involve only one MCP client, one MCP server, and a few tools. In production, however, the architecture can grow to include:

• Multiple AI applications
• Several MCP clients
• Many MCP servers
• Hundreds of tools and resources
• External APIs and databases
• Authentication and authorization systems
• Rate limits
• Retries and timeouts
• Long-running agent workflows

When something fails, the visible symptom may simply be:

The AI assistant is slow.

The real cause could be almost anywhere in the request path:

• The MCP client could not initialize the session.
• Tool discovery returned an excessively large registry.
• The model took too long to select a tool.
• The client retried the request several times.
• The server waited for an available worker.
• A database query was slow.
• A downstream API reached its rate limit.
• The tool returned an unnecessarily large result.
• The client timed out before the server completed its work.

This is why reliable MCP monitoring must cover both the client and server, as well as the tools, resources, transports, dependencies, and agent workflows surrounding them.

What This Article Covers

This article explains how to monitor:

• MCP protocol activity
• Client connections and initialization
• Tool discovery and execution
• Resource access
• Retries, cancellations, and timeouts
• Server runtime health
• Agent efficiency
• End-to-end request latency

It also provides:

• Example Prometheus metrics
• PromQL queries
• OpenTelemetry span examples
• Structured logging examples
• Dashboard recommendations
• Alerting guidance
• Privacy and security considerations

Two Meanings of MCP Monitoring

The phrase MCP monitoring can describe two related but different use cases.

1. Using MCP to Access Monitoring Data

An MCP server can give an AI assistant access to an existing monitoring platform.

For example, the AWS Prometheus MCP Server allows an AI application to work with Amazon Managed Service for Prometheus.

An operator could ask:

What was the HTTP 5xx error rate for the checkout service during the last hour?

The MCP server could translate that request into a PromQL query:

sum(
  rate(
    http_requests_total{
      service="checkout",
      status=~"5.."
    }[5m]
  )
)

In this use case, MCP acts as an interface to the monitoring system.

2. Monitoring the MCP Architecture Itself

The second use case is monitoring the actual MCP ecosystem:

• MCP clients
• MCP servers
• Sessions
• Protocol messages
• Tools
• Resources
• Prompts
• Transports
• Dependencies
• Agent workflows

This article primarily focuses on this second use case.

The two approaches can eventually work together. Your MCP application can export telemetry to Prometheus, while a Prometheus-focused MCP server allows engineers to investigate that telemetry using natural-language questions.

Why Traditional API Monitoring Is Not Enough

Traditional API monitoring usually begins with four signals:

1. Request rate
2. Error rate
3. Request duration
4. Resource utilization

These signals remain important, but MCP introduces additional behavior.

An MCP workflow may include:

1. Establishing a connection
2. Initializing a session
3. Negotiating a protocol version
4. Negotiating capabilities
5. Listing tools or resources
6. Selecting a tool
7. Calling the tool
8. Processing the result
9. Closing or maintaining the session

A traditional HTTP dashboard may report that every request returned HTTP 200. However, the JSON-RPC response inside the HTTP response could still contain an MCP error.

Similarly, a tools/list request may complete in 100 milliseconds but return 200 tool definitions. The server request is fast, while the AI model may take several seconds to evaluate the large tool registry.

MCP observability must therefore measure transport health, protocol health, tool execution, client behavior, and AI workflow behavior.

Designing MCP Metrics

Before defining individual metrics, it helps to follow several general rules.

Use Counters for Events

A counter only increases.

Counters are appropriate for:

• Tool calls
• Errors
• Retries
• Timeouts
• Reconnects
• Access-denied events

Example:

mcp_tool_calls_total

Use Histograms for Durations and Sizes

A histogram records observations in buckets and allows percentile calculations.

Histograms are appropriate for:

• Request duration
• Tool duration
• Message size
• Result size
• Session duration
• Dependency duration

Example:

mcp_tool_duration_seconds

Histograms allow you to calculate:

• p50: Typical experience
• p95: Slower requests experienced by five percent of operations
• p99: The slowest one percent of operations

Use Gauges for Current State

A gauge can increase or decrease.

Gauges are appropriate for:

• Active sessions
• Active connections
• Queue depth
• Registry item count
• Memory usage
• Connection-pool usage

Example:

mcp_server_active_sessions

Avoid High-Cardinality Labels

Prometheus labels should contain a limited and predictable set of values.

Good labels include:

tool="search_orders"
status="success"
error_type="dependency_timeout"
transport="streamable_http"

Avoid labels such as:

customer_id="4821"
session_id="b91e2b40-..."
resource_uri="file:///customers/4821/private-notes.txt"
error_message="Database timeout for customer 4821"

Unique IDs, raw paths, prompts, and exception messages can create extremely high metric cardinality and may expose sensitive information.

Store detailed values in sanitized logs or traces, not metric labels.

MCP Server Metrics

MCP server monitoring should cover four major areas:

1. Protocol activity
2. Tool execution
3. Resource access
4. Runtime and dependency health

1. Protocol Metrics

Protocol metrics describe how clients communicate with the MCP server.

A useful starting set is:

mcp_server_messages_total
mcp_server_request_duration_seconds
mcp_server_message_size_bytes
mcp_server_protocol_errors_total
mcp_server_active_sessions
mcp_server_session_duration_seconds

mcp_server_messages_total

This counter records the number of MCP messages processed by the server.

Recommended labels include:

• method
• direction
• status
• transport

Example:

mcp_server_messages_total{
  method="tools/call",
  direction="incoming",
  status="success",
  transport="streamable_http"
} 18420

This means that the server has successfully processed 18,420 incoming tools/call messages over Streamable HTTP.

This metric can answer questions such as:

• Which MCP operations are used most frequently?
• Did tool traffic increase after a release?
• Are clients repeatedly calling tools/list?
• Did activity suddenly fall to zero?
• Is one transport receiving more traffic than another?

Example interpretation

Suppose the following rate suddenly increases:

method="initialize"

A large increase in initialization requests may indicate:

• Clients are frequently reconnecting.
• The server is restarting.
• A proxy is closing idle connections.
• Authentication sessions are expiring.
• Clients are creating unnecessary short-lived sessions.

mcp_server_request_duration_seconds

This histogram measures how long the server takes to process an MCP operation.

Example:

mcp_server_request_duration_seconds{
  method="tools/list"
}

For tools/list, the duration may include:

• Loading tool definitions
• Applying access controls
• Building input schemas
• Serializing the registry

For tools/call, it may include:

• Validating arguments
• Executing the tool
• Waiting for dependencies
• Serializing the result

Example percentile values:

tools/call p50:  400 ms
tools/call p95:  2.8 seconds
tools/call p99:  8.5 seconds

The average might appear acceptable while the p99 value reveals that some users experience severe delays.

mcp_server_message_size_bytes

This histogram records the size of incoming and outgoing MCP messages.

Example:

mcp_server_message_size_bytes{
  method="tools/call",
  direction="outgoing"
}

MCP responses may contain:

• Search results
• Documents
• Source code
• Logs
• Database records
• File contents
• Monitoring data

A tool may work correctly but return significantly more information than the client needs.

Example

A search_logs tool returns 50 MB of logs, while the user only needs the latest 20 errors.

Large messages increase:

• Network transfer time
• Serialization time
• Client memory usage
• Model context usage
• Token consumption
• End-to-end latency

Monitoring response sizes can help identify tools that need pagination, limits, filtering, or summarization.

mcp_server_protocol_errors_total

This counter records MCP or JSON-RPC protocol errors.

Example:

mcp_server_protocol_errors_total{
  method="tools/call",
  error_type="invalid_parameters"
} 23

Useful error categories include:

invalid_request
invalid_parameters
method_not_found
unsupported_protocol_version
capability_not_supported
internal_error

Example interpretation

A rise in invalid_parameters errors may indicate:

• The tool schema changed.
• A client is sending an outdated argument format.
• Tool descriptions do not clearly explain required fields.
• The agent is generating invalid arguments.

A rise in unsupported_protocol_version may indicate that older clients are still connecting after a server upgrade.

mcp_server_active_sessions

This gauge records the number of currently active MCP sessions.

Example:

mcp_server_active_sessions{
  transport="streamable_http"
} 138

A sudden decrease to zero may indicate an outage.

A rapid increase may indicate:

• A traffic spike
• A reconnection storm
• Sessions not being closed correctly
• Clients unnecessarily opening multiple connections

mcp_server_session_duration_seconds

This histogram measures how long MCP sessions remain active.

Short sessions may be expected for command-line clients. Desktop applications may keep sessions open for several hours.

Unexpectedly short sessions may indicate:

• Connection instability
• Authentication expiration
• Server restarts
• Transport failures

Unexpectedly long sessions may indicate:

• Connection leaks
• Idle clients
• Unreleased session resources
• Missing session cleanup

2. Tool Execution Metrics

Tools are usually the most important operational component of an MCP server.

A server may appear healthy while one specific tool is consistently slow or unreliable.

Recommended metrics include:

mcp_tool_calls_total
mcp_tool_duration_seconds
mcp_tool_errors_total
mcp_tool_timeouts_total
mcp_tool_cancellations_total
mcp_tool_result_size_bytes
mcp_tool_dependency_duration_seconds

mcp_tool_calls_total

This counter records how often each tool is called and whether the call succeeded.

Example:

mcp_tool_calls_total{
  tool="search_orders",
  status="success"
} 4832

A corresponding error series could be:

mcp_tool_calls_total{
  tool="search_orders",
  status="error"
} 168

The success ratio is:

4832 / (4832 + 168) = 96.64%

This metric helps answer:

• Which tools are used most frequently?
• Which tools are no longer used?
• Did traffic change after a release?
• Is one tool receiving unexpected load?
• Which tools have the lowest success ratio?

Example

An order MCP server exposes four tools:

search_orders
get_customer
create_refund
update_shipping_address

If search_orders handles 80% of all tool calls, it deserves additional load testing, capacity planning, and performance optimization.

mcp_tool_duration_seconds

This histogram measures tool execution duration.

Example:

mcp_tool_duration_seconds{
  tool="search_orders"
}

Suppose the dashboard reports:

search_orders p50:  300 ms
search_orders p95:  1.8 seconds
search_orders p99:  5.4 seconds

Most calls are fast, but the slowest one percent take more than five seconds.

You can compare tool duration with dependency duration:

Total tool duration:       5.4 seconds
Database query duration:   4.9 seconds
Result serialization:      0.2 seconds
Other processing:          0.3 seconds

This shows that the database, rather than the MCP framework, is responsible for most of the delay.

mcp_tool_errors_total

This counter records tool failures by category.

Example:

mcp_tool_errors_total{
  tool="create_refund",
  error_type="permission_denied"
} 41

Recommended bounded error types include:

invalid_parameters
authentication_failed
permission_denied
rate_limited
dependency_timeout
dependency_error
internal_error
cancelled

Example interpretation

Suppose create_refund reports:

permission_denied:    120
invalid_parameters:    18
dependency_timeout:     4
internal_error:         2

Most failures are authorization-related.

The correct response may involve reviewing permissions and improving user-facing error messages—not scaling the MCP server.

mcp_tool_timeouts_total

This counter records tool calls that exceeded their allowed execution time.

Example:

mcp_tool_timeouts_total{
  tool="generate_report"
} 27

Timeouts may be caused by:

• Slow databases
• Slow third-party APIs
• Queue congestion
• Expensive computation
• Network instability
• Incorrect timeout configuration

Example

The generate_report tool has a 30-second timeout.

Trace data shows:

Database query:       29 seconds
Result processing:     2 seconds
Total server time:    31 seconds

The correct solution is probably query optimization or asynchronous report generation, rather than simply increasing the timeout.

mcp_tool_cancellations_total

This counter records tool operations cancelled before completion.

Example:

mcp_tool_cancellations_total{
  tool="search_repository",
  reason="client_cancelled"
} 85

A cancellation may occur when:

• The user stops the request.
• The client reaches a deadline.
• The model changes its plan.
• A parent agent workflow is cancelled.
• The connection closes.

Example

search_repository calls:          1,000
search_repository cancellations:    240

A 24% cancellation ratio suggests that the tool may be too slow to remain useful.

mcp_tool_result_size_bytes

This histogram records tool result sizes.

Example:

mcp_tool_result_size_bytes{
  tool="search_repository"
}

Suppose the metrics show:

get_weather p95 result size:          4 KB
search_repository p95 result size:    3 MB

The repository tool may need:

• Pagination
• Result limits
• Filtering
• Summarization
• Metadata-only responses
• A separate resource-read operation for complete files

mcp_tool_dependency_duration_seconds

This histogram records time spent communicating with downstream services.

Example:

mcp_tool_dependency_duration_seconds{
  tool="search_orders",
  dependency="orders_database"
}

Suppose:

Total tool duration:        2.6 seconds
Database dependency time:  2.2 seconds
MCP server processing:      0.4 seconds

The tool implementation itself is relatively efficient. The database dependency is responsible for most of the latency.

3. Resource Metrics

MCP resources may represent:

• Files
• Documents
• Repository content
• Database records
• API responses
• Configuration
• Knowledge-base entries

Recommended metrics include:

mcp_resource_reads_total
mcp_resource_read_duration_seconds
mcp_resource_response_size_bytes
mcp_resource_access_denied_total

mcp_resource_reads_total

This counter records how often a category of resource is accessed.

Example:

mcp_resource_reads_total{
  resource_type="documentation",
  status="success"
} 9240

This metric helps identify:

• Popular resource categories
• Unused integrations
• Access failures
• Unexpected usage changes

Avoid storing complete URIs as labels.

Avoid:

resource_uri="file:///customers/4821/private-notes.txt"

Prefer:

resource_type="customer_document"

mcp_resource_read_duration_seconds

This histogram measures resource retrieval time.

Example:

mcp_resource_read_duration_seconds{
  resource_type="repository_file"
}

A local file may take only a few milliseconds to read, while a file retrieved from a remote document platform may take several seconds.

Comparing resource types helps identify where caching, indexing, or replication may improve performance.

mcp_resource_response_size_bytes

This histogram measures the size of resource responses.

Example:

mcp_resource_response_size_bytes{
  resource_type="log_file"
}

Suppose the p95 values are:

repository_file:   80 KB
log_file:          10 MB

The log integration may need:

• Line limits
• Time-range filtering
• Search expressions
• Tail operations
• Pagination

mcp_resource_access_denied_total

This counter records rejected resource-access attempts.

Example:

mcp_resource_access_denied_total{
  resource_type="customer_record",
  reason="insufficient_scope"
} 54

A sudden increase may indicate:

• Expired credentials
• Incorrect client permissions
• A deployment error
• Misconfigured authorization rules
• Unusual or potentially unsafe access behavior

4. Server Runtime Metrics

An MCP server is still an application process, so standard runtime metrics remain essential.

Important signals include:

process_cpu_seconds_total
process_resident_memory_bytes
process_open_fds
runtime_gc_duration_seconds
http_server_requests_total
http_server_request_duration_seconds

Additional application metrics may include:

mcp_server_queue_depth
mcp_server_worker_utilization
mcp_server_event_loop_delay_seconds
database_pool_connections
dependency_requests_total
dependency_request_duration_seconds
dependency_rate_limits_total

CPU Usage

High CPU usage may indicate:

• Expensive tool computation
• Large JSON serialization operations
• Excessive response processing
• Traffic spikes
• Inefficient loops
• Insufficient server capacity

Memory Usage

Memory growth may be caused by:

• Large tool results
• Large registries
• Session state
• Cached resources
• Memory leaks
• Unclosed streams

A continuously increasing memory graph is usually more concerning than a temporary spike.

Queue Depth

A queue-depth metric records operations waiting to be processed.

mcp_server_queue_depth{
  queue="tool_execution"
} 87

If queue depth rises while CPU is near 100%, the server may need additional capacity.

If the queue rises while CPU remains low, the bottleneck may be:

• A limited worker pool
• A database connection pool
• A concurrency limit
• A downstream API

Database Connection-Pool Usage

Example:

database_pool_connections{
  pool="orders",
  state="active"
} 48

database_pool_connections{
  pool="orders",
  state="max"
} 50

The database pool is almost exhausted. Tool calls may spend significant time waiting for a connection before their queries begin.

Why MCP Client Monitoring Also Matters

Monitoring the MCP server is necessary, but it is not enough.

The client is responsible for:

• Establishing the connection
• Initializing the session
• Negotiating capabilities
• Discovering tools and resources
• Sending tool calls
• Applying timeouts
• Retrying failures
• Processing responses
• Returning results to the agent

Some failures may only be visible from the client:

• Authentication fails before the request reaches the server.
• The client cannot connect to a healthy server.
• The client rejects the negotiated protocol version.
• The client times out before the server responds.
• The client repeatedly retries the same tool.
• A transport connection is interrupted while receiving a response.
• The tool registry is too large for efficient selection.

Client-side telemetry completes the end-to-end monitoring picture.

1. Client Initialization Metrics

Recommended metrics include:

mcp_client_initializations_total
mcp_client_initialization_duration_seconds
mcp_client_connections_active
mcp_client_reconnections_total
mcp_client_capability_mismatches_total
mcp_client_protocol_version_total

mcp_client_initializations_total

This counter records initialization attempts.

mcp_client_initializations_total{
  server="orders-mcp",
  status="success"
} 3490

mcp_client_initializations_total{
  server="orders-mcp",
  status="error"
} 210

The success ratio is:

3490 / (3490 + 210) = 94.32%

A drop in the success ratio may indicate:

• Server unavailability
• Authentication errors
• Transport configuration problems
• Protocol incompatibility
• Capability negotiation failures

mcp_client_initialization_duration_seconds

This histogram measures how long it takes to establish and initialize a session.

Initialization may include:

• DNS lookup
• Process startup
• Network connection
• TLS negotiation
• Authentication
• Protocol negotiation
• Capability exchange

Example:

Initialization p50:  400 ms
Initialization p95:  3.2 seconds
Initialization p99:  9.1 seconds

Slow initialization may explain why the first MCP interaction is much slower than later operations.

mcp_client_reconnections_total

This counter records reconnection attempts.

mcp_client_reconnections_total{
  server="orders-mcp",
  reason="connection_reset"
} 320

A reconnection spike may indicate:

• Server restarts
• Network instability
• Proxy timeouts
• Authentication expiration
• Transport errors

2. Tool Registry Metrics

Before calling a tool, the client normally retrieves the available tool registry.

Recommended metrics include:

mcp_client_registry_requests_total
mcp_client_registry_duration_seconds
mcp_client_registry_items
mcp_client_registry_size_bytes

mcp_client_registry_items

This gauge records the number of tools or resources returned.

mcp_client_registry_items{
  server="enterprise-mcp",
  registry_type="tools"
} 186

A large tool registry can affect:

• Model context size
• Tool-selection accuracy
• Selection duration
• Discovery latency
• Maintenance complexity

Example

Tool count:                25
Tool-selection p95:       450 ms

After expanding the server:

Tool count:               180
Tool-selection p95:       2.8 seconds

The MCP server may still respond quickly, but the AI application takes longer to select a tool.

mcp_client_registry_size_bytes

This metric records the serialized size of a registry response.

mcp_client_registry_size_bytes{
  server="enterprise-mcp",
  registry_type="tools"
} 924000

A 924 KB registry may contain:

• Long tool descriptions
• Large input schemas
• Repeated instructions
• Unnecessary examples
• Overlapping tools

Reducing registry size can improve network performance and model efficiency.

3. Client Tool-Call Metrics

Recommended metrics include:

mcp_client_tool_calls_total
mcp_client_tool_call_duration_seconds
mcp_client_tool_retries_total
mcp_client_tool_timeouts_total
mcp_client_tool_cancellations_total

mcp_client_tool_call_duration_seconds

This histogram records the complete duration experienced by the client.

mcp_client_tool_call_duration_seconds{
  server="orders-mcp",
  tool="search_orders"
}

Compare client and server durations:

Client-observed duration:  2.4 seconds
Server tool duration:      1.6 seconds
Database duration:         1.2 seconds

The remaining 800 milliseconds may include:

• Network transfer
• Client-side queueing
• Serialization
• Deserialization
• Response processing

Without client telemetry, the server might incorrectly be blamed for the full 2.4 seconds.

mcp_client_tool_retries_total

This counter records retry attempts.

mcp_client_tool_retries_total{
  server="orders-mcp",
  tool="search_orders",
  reason="timeout"
} 430

Suppose:

Logical client requests:   1,000
Retry attempts:              430
Server executions:         1,430

Retries can improve reliability, but they also increase:

• Server load
• API costs
• Rate-limit usage
• Workflow duration
• Risk of duplicate side effects

Retries are especially important for non-idempotent tools such as:

create_refund
send_email
submit_order
create_ticket

These operations should use idempotency keys or equivalent duplicate-prevention mechanisms.

mcp_client_tool_timeouts_total

This counter records calls that exceeded the client timeout.

mcp_client_tool_timeouts_total{
  server="analytics-mcp",
  tool="generate_report"
} 94

A client timeout does not guarantee that the server stopped processing.

Example:

Client timeout:       30 seconds
Server completion:    34 seconds

The client reports failure, but the server may still complete the operation. A retry could then execute the same action twice.

Agent and Workflow Metrics

MCP protocol metrics do not fully explain how effectively the AI agent uses MCP.

Where the AI platform exposes the necessary information, consider measuring:

mcp_agent_tool_selection_duration_seconds
mcp_agent_tool_calls_per_request
mcp_agent_repeated_tool_calls_total
mcp_agent_unused_tool_results_total
mcp_agent_workflow_duration_seconds
mcp_agent_workflows_total

Tool Calls per User Request

Suppose the user asks:

What is the current status of order 12345?

The expected workflow may require one tool call.

Expected tool calls:   1
Observed tool calls:   7

This may indicate that the agent is:

• Selecting the wrong tool
• Repeating failed calls
• Ignoring previous results
• Calling overlapping tools
• Entering a planning loop

Repeated Tool Calls

A repeated-call metric identifies equivalent calls within one workflow.

Tool: search_orders
Arguments: customer_id=4821
Calls in one workflow: 5

Repeated calls may indicate:

• The result schema is unclear.
• The response omitted important context.
• The model did not understand the result.
• The agent is stuck in a loop.

Complete Workflow Duration

This histogram measures the complete time from the user request to the final response.

Example:

Complete workflow:          12.0 seconds
Model reasoning:             4.0 seconds
Tool selection:              1.5 seconds
MCP operations:              5.5 seconds
Final response generation:   1.0 second

This breakdown is more useful than MCP server latency alone.

PromQL Examples

The metric names in this article are examples. MCP does not currently require one universal Prometheus naming scheme, so your organization should document its chosen schema.

Tool Request Rate

sum by (tool) (
  rate(mcp_tool_calls_total[5m])
)

This calculates the average number of calls per second for each tool during the last five minutes.

It helps identify:

• Popular tools
• Traffic spikes
• Sudden usage drops
• Load distribution

Tool Error Ratio

sum by (tool) (
  rate(mcp_tool_calls_total{status="error"}[5m])
)
/
sum by (tool) (
  rate(mcp_tool_calls_total[5m])
)

Example results:

search_orders:  0.012
create_refund:  0.084
get_customer:   0.004

These values represent:

search_orders error ratio:  1.2%
create_refund error ratio:  8.4%
get_customer error ratio:   0.4%

The create_refund tool clearly requires investigation.

p95 Tool Duration

histogram_quantile(
  0.95,
  sum by (le, tool) (
    rate(mcp_tool_duration_seconds_bucket[5m])
  )
)

A p95 value of three seconds means approximately 95% of recorded operations completed within three seconds.

Initialization Failure Ratio

sum by (server) (
  rate(
    mcp_client_initializations_total{
      status="error"
    }[10m]
  )
)
/
sum by (server) (
  rate(mcp_client_initializations_total[10m])
)

This detects clients that cannot establish usable MCP sessions, even when the server process appears healthy.

p95 Tool Result Size

histogram_quantile(
  0.95,
  sum by (le, tool) (
    rate(mcp_tool_result_size_bytes_bucket[15m])
  )
)

This query identifies tools that regularly return large responses.

Retry Increase

sum by (server, tool, reason) (
  increase(mcp_client_tool_retries_total[10m])
)

A retry spike can be an early warning of a dependency or transport issue.

Distributed Tracing

Metrics reveal that a problem exists. Traces explain where it occurred.

A complete MCP trace may look like:

agent.request
├── llm.inference
├── mcp.initialize
├── mcp.tools.list
├── agent.tool_selection
├── mcp.tools.call search_orders
│   ├── server.tool.execute search_orders
│   │   ├── database.connection.wait
│   │   ├── database.query
│   │   └── result.serialize
│   └── client.result.process
└── llm.inference

Useful span attributes include:

mcp.operation.name
mcp.server.name
mcp.server.version
mcp.client.name
mcp.client.version
mcp.protocol.version
mcp.transport
mcp.tool.name
mcp.resource.type
mcp.status
error.type
rpc.jsonrpc.error_code
deployment.environment
deployment.version

Example:

mcp.operation.name = "tools/call"
mcp.server.name = "orders-mcp"
mcp.tool.name = "search_orders"
mcp.transport = "streamable_http"
mcp.status = "error"
error.type = "dependency_timeout"
deployment.version = "2.4.1"

OpenTelemetry is useful because it can connect MCP operations with:

• HTTP requests
• Database queries
• Queue operations
• Cloud APIs
• LLM calls
• Agent workflows

Structured Logging

Metrics should use bounded labels. Logs can provide more detailed operational context.

A structured tool-failure log might look like:

{
  "timestamp": "2026-07-19T15:42:01Z",
  "level": "error",
  "event": "mcp_tool_call_failed",
  "server": "orders-mcp",
  "tool": "search_orders",
  "status": "error",
  "error_type": "dependency_timeout",
  "duration_ms": 5021,
  "trace_id": "8af2c31e7d",
  "deployment_version": "2.4.1"
}

Useful correlation fields include:

trace_id
span_id
request_id
workflow_id

Avoid logging complete prompts, credentials, or tool results unless there is a reviewed and secure requirement to do so.

Building an MCP Dashboard

An effective dashboard should guide an operator from a broad symptom to a specific cause.

A useful starting point is the community MCP Server Observability dashboard for Grafana.

The dashboard includes visibility into areas such as:

• Transport health
• Protocol operations
• Tool execution
• Sessions
• Resources
• Agentic activity
• Runtime and system health

It can be used as a reference implementation, although metric names and labels may need to be adapted to match your instrumentation.

Protocol and Connection Health

This dashboard section should explain whether clients can establish and maintain valid sessions.

Include:

• Initialization success ratio
• Initialization duration
• Active sessions
• Reconnection rate
• Protocol errors
• Capability mismatches
• Protocol-version distribution
• Message volume by method

Example interpretation

Server availability:             99.99%
Initialization success ratio:    91%
Reconnection rate:               8× normal
Unsupported-version errors:      Increasing

The server process is available, but clients are not consistently establishing valid sessions.

Tool Reliability and Performance

This section should explain how tools are used, how long they take, and why they fail.

Include:

• Calls by tool
• Success ratio
• Errors by type
• p50, p95, and p99 duration
• Timeout count
• Cancellation ratio
• Result-size percentiles
• Dependency duration

Example

search_orders p95:              1.2 seconds
generate_report p95:           28.0 seconds
generate_report timeout ratio: 14%

The problem is isolated to generate_report, not the complete MCP server.

Client Behavior

This section should explain how clients interact with the server.

Include:

• Registry discovery duration
• Registry item count
• Registry response size
• Client-observed duration
• Retries
• Client timeouts
• Reconnects
• Calls that fail before reaching the server

Example

Server-side tool p95:   1.5 seconds
Client-observed p95:    4.2 seconds

The 2.7-second difference suggests transport, network, queueing, or client-processing overhead.

Agent Efficiency

This section should explain whether the AI application uses tools effectively.

Include:

• Tool-selection duration
• Calls per user request
• Repeated calls
• Unused results
• Complete workflow duration
• Workflow success ratio

Example

Average tool calls per request last week:  2.1
Average tool calls per request today:      7.8

The increase may have been caused by:

• A prompt change
• A model change
• New tool descriptions
• Tool schema changes
• Poor-quality tool results

Alerting

Alerts should represent conditions that require action.

An isolated error usually does not require paging an engineer. A sustained error-ratio increase probably does.

Tool Error-Ratio Alert

The error ratio for a production tool exceeds 5%
for at least 10 minutes.

Possible causes include:

• A failed deployment
• Dependency failure
• Authentication problems
• Schema incompatibility

Tool-Latency Alert

The p95 duration of search_orders exceeds
3 seconds for at least 15 minutes.

The alert should include:

• Tool name
• Server name
• Environment
• Deployment version
• Related dependency
• Dashboard link
• Runbook link
• Trace-search link

Initialization-Failure Alert

More than 10% of client initialization attempts
fail for at least 10 minutes.

This detects connection and negotiation problems that ordinary server-health checks may miss.

Retry-Storm Alert

Client retries increase to more than
three times the historical baseline.

Retry storms can increase load and make an existing incident worse.

Registry-Growth Alert

The tool count or registry size increases by
more than 30% following a deployment.

Registry growth may be intentional, so this could initially be a warning rather than a critical alert.

Privacy and Security

MCP tools may handle sensitive information such as:

• Source code
• Customer records
• Internal documents
• Database results
• Cloud configuration
• Authentication data
• Financial records
• Personal information

Observability must not become another channel through which sensitive data is exposed.

Avoid collecting:

• API keys
• Authentication tokens
• Cookies
• Full prompts by default
• Complete conversations
• Raw database results
• Complete tool responses
• Secret environment variables
• Sensitive file contents

Prefer metadata:

tool.name = "search_orders"
tool.status = "success"
result.count = 17
result.size_bytes = 4280
error.type = "dependency_timeout"

Avoid:

authorization = "Bearer eyJ..."
customer_email = "[email protected]"
database_result = "{complete customer records}"
prompt = "Find all private orders belonging to..."

Telemetry behavior should be documented clearly. For distributed or locally installed MCP servers, external telemetry may need to be disabled by default and enabled explicitly by the operator.

A Practical Rollout Plan

A complete observability implementation does not need to be delivered all at once.

Phase 1: Basic Reliability

Implement:

• Client initialization success
• Initialization duration
• Tool call count
• Tool duration
• Tool errors
• Tool timeouts
• Server CPU and memory
• Structured error logs

This phase should answer:

Is the service available, and are its tools working?

Phase 2: Protocol and Client Visibility

Add:

• Protocol message counts
• Protocol errors
• Active sessions
• Reconnection counts
• Capability mismatches
• Registry discovery duration
• Registry size
• Client retries

This phase should answer:

Is the problem occurring in the client, protocol, transport, or server?

Phase 3: End-to-End Tracing

Connect:

• Agent request spans
• LLM inference spans
• MCP client spans
• MCP server spans
• Tool execution spans
• Database and API spans

This phase should answer:

Where did an individual request spend its time?

Phase 4: Agent Efficiency

Add:

• Tool-selection duration
• Calls per request
• Repeated tool calls
• Unused results
• Complete workflow duration

This phase should answer:

Is the agent using MCP tools effectively?

Phase 5: Security and Anomaly Detection

Add:

• Authentication failures
• Access-denied events
• Rate-limit events
• Unusual tool sequences
• Unexpected resource access
• Abnormal session behavior

This phase should answer:

Is the observed activity expected and authorized?

Final Thoughts

Monitoring an MCP server is not the same as monitoring a conventional HTTP endpoint.

The server is only one component of a larger AI workflow.

Reliable MCP observability should cover:

• Client connections
• Session initialization
• Protocol negotiation
• Tool and resource discovery
• Tool execution
• Resource access
• Retries and timeouts
• Runtime infrastructure
• Downstream dependencies
• Agent behavior
• Complete workflow duration

Each telemetry type serves a different purpose:

• Prometheus metrics reveal trends and support alerts.
• Structured logs provide detailed failure context.
• Distributed traces connect clients, servers, tools, and dependencies.
• Client metrics reveal connection, discovery, retry, and timeout problems.
• Agent metrics reveal inefficient tool selection and repeated operations.

The most useful monitoring system is not the one that collects the largest number of metrics.

It is the one that allows an engineer to move quickly from:

The AI assistant is slow.

To:

The search_orders tool is waiting for a saturated database connection pool. This increased its p95 duration from 1.2 seconds to 5.6 seconds and caused MCP clients to retry requests.

That level of visibility turns MCP from an opaque integration layer into a system that can be measured, understood, and operated reliably.