# OpenTelemetry Trace Latency Analyzer MCP for AI Agents MCP

> OpenTelemetry Trace Latency Analyzer helps you find the exact spots in your distributed traces where performance drops. Instead of guessing which microservice is dragging down your response times, you can feed your agent raw span data to get a breakdown of critical paths, self-time metrics, and service-specific bottlenecks.

## Overview
- **Category:** observability
- **Price:** Free
- **Endpoint:** https://edge.vinkius.com/vk_preview_agOS3XqPfYKQCHw4us6xxbEWEsZ0GDWuybsYlRLe/mcp
- **Tags:** opentelemetry, tracing, latency, bottleneck, microservices

## Description

Dealing with distributed systems means spending hours digging through logs and dashboards just to figure out why a request took five seconds instead of five hundred milliseconds. It is a headache when you can't tell if a service is actually slow or if it's just sitting there waiting on a downstream dependency. This MCP changes that by letting your AI client act as a specialized performance engineer. You can hand off raw OpenTelemetry traces and get a clear breakdown of the critical path. It calculates how much time each service actually spends on its own work versus waiting on other tasks. It also identifies the specific spans that cross your latency thresholds and shows you the distribution of time across your entire architecture. Because it's part of the Vinkius catalog, you can plug this diagnostic engine directly into your existing workflow to move from a vague feeling of slowness to knowing the exact service causing the delay in seconds.

## Tools

### get_service_distribution
Calculates the average latency for every service or span name in your trace. It helps you see which part of your stack is the heaviest.

### analyze_trace_latency
Breaks down the trace to show high-level metrics like total duration and span counts. It gives you a bird's-eye view of the request flow.

### identify_bottlenecks
Flags specific spans that exceed a time threshold you set. This points you directly at the noisy neighbors or slow queries.

## Prompt Examples

**Prompt:** 
```
The checkout API is taking 3 seconds. Here's the trace: [JSON]. Where is the delay coming from?
```

**Response:** 
```
### Trace Analysis Results

Based on the trace provided, here is the breakdown of the latency:

| Service | Span Name | Total Time | Self-Time | Status |
| :--- | :--- | :--- | :--- | :--- |
| **gateway** | entry | 3000ms | 10ms | ✅ |
| **auth-svc** | validate | 450ms | 440ms | ⚠️ **Bottleneck** |
| **db-proxy** | query | 2000ms | 2000ms | 🚨 **Critical Path** |

**Key Findings:**
*   **Primary Bottleneck:** The `db-proxy` service is taking 2000ms of the total 3000ms.
*   **Self-Time Analysis:** The `auth-svc` is actually doing significant work (440ms), while the `gateway` is mostly waiting.
*   **Critical Path:** The path through `db-proxy` is the primary driver of your 3s delay.
```

**Prompt:** 
```
Give me a breakdown of how much time each service spends on this request: [JSON].
```

**Response:** 
```
### Service Latency Distribution

Here is how the total request time is distributed across your services:

*   **auth-service**: 45ms (12%)
*   **payment-service**: 120ms (30%)
*   **inventory-service**: 15ms (4%)
*   **shipping-service**: 300ms (75%)
*   **gateway**: 10ms (3%)

**Summary:** The `shipping-service` is the heaviest component, accounting for 75% of the total request duration.
```

**Prompt:** 
```
Are there any spans in this trace that are taking longer than 100ms? [JSON]
```

**Response:** 
```
### Latency Violations

I found 2 spans that exceeded your 100ms threshold:

*   **Service:** `payment-service` | **Span:** `process_card` | **Duration:** 145ms
*   **Service:** `shipping-service` | **Span:** `calculate_rates` | **Duration:** 310ms

All other spans completed within the expected timeframe.
```

## Capabilities

### Calculate per-service latency distributions
Get a clear breakdown of how much time each unique service or span name contributes to the total request duration.

### Identify specific high-latency spans
Flag every span that exceeds a specific time threshold to pinpoint the exact source of a delay.

### Compute critical path durations
Determine the actual length of the longest chain of dependent operations in a trace.

### Extract per-span self-time
See how much time a service spent on its own work by stripping away the time spent waiting on child spans.

### Map trace depth and span counts
Get a count of all spans and the total depth of the trace to identify overly complex request flows.

### Highlight longest-chain bottlenecks
Automatically find the deepest and slowest path within a complex web of microservice calls.

## Use Cases

### A slow checkout flow
An engineer sees a 5s checkout. They ask the agent to find the bottleneck. The agent uses identify_bottlenecks to show the DB query is the culprit.

### Cost optimization
A lead wants to see where to scale. They use get_service_distribution to see that the auth service is taking 40% of the total time.

### Debug a ghost lag
A dev thinks a service is slow, but it's just waiting on a slow downstream API. The agent calculates self-time to prove the service is actually fast.

### Trace auditing
A team wants to see the average depth of their requests. They use analyze_trace_latency to check for excessive span nesting.

## Benefits

- Stop guessing which service is slow by using identify_bottlenecks to isolate specific high-latency spans instantly.
- Understand your architecture better with get_service_distribution showing exactly how much time each service consumes.
- Save hours of manual trace digging by having your agent automatically calculate critical path durations for every request.
- Differentiate between waiting time and working time using per-span self-time metrics to find the real culprits.
- Get a clear view of trace depth and span counts to spot unnecessary complexity in your request flow.
- Move from high-level alerts to specific code fixes by identifying the longest-chain bottlenecks in complex traces.

## How It Works

The bottom line is you get a surgical breakdown of where your request time is actually going.

1. Provide your agent with a JSON array of OpenTelemetry spans containing start and end timestamps.
2. The MCP parses the parent-child relationships and calculates the duration of every operation.
3. You get a summary of bottlenecks, self-time metrics, and a distribution of latency across your services.

## Frequently Asked Questions

**Can the OpenTelemetry Trace Latency Analyzer help with microservices?**
Yes, it is specifically designed for distributed traces. It helps you see how requests move between different services and where the time is being lost.

**How do I find the slowest part of a trace using this MCP?**
The MCP automatically identifies bottlenecks by looking for spans that exceed your time limits and highlighting the longest chains of dependencies.

**Does it show how much time a service spends on its own work?**
Yes, it calculates per-span self-time. This allows you to see if a service is actually slow or just waiting for a downstream response.

**Can it help me find out why my API is slow?**
Absolutely. By analyzing the trace spans, it identifies the critical path and provides a distribution of latency across your entire architecture.

**What kind of data does the OpenTelemetry Trace Latency Analyzer need?**
It requires OpenTelemetry-style trace data, specifically spans that include start and end timestamps along with parent-child IDs.

**Does it work with multiple services at once?**
Yes, it can analyze traces involving dozens of different services and give you a percentage-based breakdown of where the time is going.

**What kind of trace data does this tool support?**
It supports OpenTelemetry-style traces where each span includes a unique identifier, parent ID, service name, span name, and start/end timestamps.

**How can I identify the slowest parts of my request?**
By using `identify_bottlenecks`, you can find spans that exceed a specific latency threshold within your trace data.

**Can I see how much time each service contributes to the total trace?**
Yes, using `get_service_distribution` allows you to see an aggregation of average latency per service or span name.