# Highlight MCP

> Highlight MCP sends raw text logs, structured OTLP JSON logs, and detailed traces directly into your Highlight dashboard. Use this MCP to centralize all observability data—from backend service activity to user interaction paths—for deep performance monitoring.

## Overview
- **Category:** developer-tools
- **Price:** Free
- **Tags:** session-replay, ux-monitoring, observability, otlp, logging

## Description

Need to figure out why a feature is slow or why an error popped up? This MCP lets you feed complex system signals—raw text, structured JSON logs, and full request traces—right into your Highlight project. You don't have to jump between five different dashboards just to correlate a user session with the backend failure. Instead, your agent manages all that data ingestion for you.

The process is straightforward: send the data using natural conversation, and it lands in Highlight. Whether you’re debugging a specific API call or trying to understand general system health, this MCP gives your AI client access to every signal type needed. When you find observability tools on Vinkius, this one handles the messiest part—getting all the varied logs into a single source of truth for root cause analysis.

## Tools

### ingest_otlp_logs
This sends structured OTLP JSON logs into Highlight for deep context and metadata tracking.

### ingest_otlp_traces
Use this to send full OTLP JSON traces, allowing you to visualize complete request paths.

### ingest_raw_log
This sends simple, unformatted text log messages directly into Highlight.

## Prompt Examples

**Prompt:** 
```
Ingest a raw log message 'Server started' for the 'backend-api' service.
```

**Response:** 
```
I've sent the raw log 'Server started' for 'backend-api' to your Highlight project. You can now view it in your dashboard.
```

**Prompt:** 
```
Send this OTLP JSON log payload to Highlight: {"resourceLogs": [...]}.
```

**Response:** 
```
Processing the OTLP logs... The structured payload has been successfully ingested into Highlight via `ingest_otlp_logs`.
```

**Prompt:** 
```
Use ingest_otlp_traces to send these resource spans to Highlight.
```

**Response:** 
```
The OTLP traces have been sent. You can now analyze the request spans and performance metrics in your Highlight project.
```

## Capabilities

### Send raw text log messages
You can send simple, unstructured text logs from your backend services to Highlight.

### Ingest structured OTLP logs
The MCP accepts and processes complex, structured logs formatted in the OpenTelemetry Protocol (OTLP) JSON standard.

### Track request performance traces
You can send full OTLP traces to visualize entire request flows and pinpoint exactly where latency occurs.

### Correlate logs with user sessions
The data lands in Highlight, allowing you to tie backend failures back to specific monitored user experiences.

## Use Cases

### The checkout process fails intermittently
A Product Manager notices high drop-off rates during payment. They ask their agent to use the MCP to send `ingest_otlp_traces` and `ingest_raw_log`. The resulting data shows that a specific third-party payment API call is failing sporadically, leading to session loss.

### System performance degrades at peak hours
An SRE suspects database contention. They use the MCP with `ingest_otlp_logs` and `ingest_raw_log`. The structured logs show a sudden spike in connection pool usage, while the raw logs point to specific slow query IDs that need tuning.

### Debugging an obscure API error
A backend developer encounters a unique runtime exception. They use `ingest_raw_log` with the exact stack trace and service name, instantly making it visible in Highlight for review, eliminating hours of manual log searching.

### Analyzing user flow across services
A team wants to see how a full user journey impacts performance. They use `ingest_otlp_traces` to map the entire call graph from the frontend through three separate microservices, identifying which handoff is adding unnecessary delay.

## Benefits

- You capture the messy context. By using `ingest_raw_log`, you ensure that simple, unstructured messages—like unique stack traces or session IDs—don't get dropped just because they aren't JSON-formatted.
- Pinpoint latency with precision. Sending OTLP traces via `ingest_otlp_traces` lets you map out the exact sequence of function calls and identify which microservice is causing a bottleneck.
- Maintain structured context. Use `ingest_otlp_logs` to ingest rich, standardized JSON data. This makes querying easier because all your metadata stays organized and searchable.
- Connect the dots for product teams. You can correlate general user session behavior with specific backend failures by feeding logs into Highlight.
- Speed up debugging cycles. Instead of manually pulling log snippets from ten different services, you send them all here to get a unified view.

## How It Works

The bottom line is that you send three different kinds of signals—text, structured JSON, and traces—and they all appear together in one place.

1. First, subscribe to this MCP and provide your unique Highlight Project ID.
2. Next, tell your agent or development environment which type of data you're sending (raw log, OTLP log, or trace).
3. The system ingests the payload, making it immediately viewable for analysis inside your Highlight dashboard.

## Frequently Asked Questions

**How does ingest_raw_log differ from ingest_otlp_logs in Highlight?**
It's about structure. `ingest_raw_log` handles plain text, which is great for debugging stack traces or simple messages. However, `ingest_otlp_logs` forces a structured JSON format, making the data searchable and filterable by resource type.

**Do I need all three tools to monitor performance?**
Yeah, you should. While OTLP traces (`ingest_otlp_traces`) show the path of a request, raw logs are often where the specific failure message lives, and structured logs (`ingest_otlp_logs`) provide the metadata needed to find that failure across thousands of records.

**Can I use this MCP for non-API logging?**
Yep. If you're capturing user behavior or console messages that don't come from a standard API endpoint, you can still funnel them using `ingest_raw_log` to keep the context visible in Highlight.

**Is ingest_otlp_traces only for microservices?**
Nah. While it's built for complex service calls, you can use it anytime you want to map a sequence of actions—even within a single application process—to track performance.

**What specific parameters do I need to provide when using ingest_otlp_logs?**
You must include the `highlight.project_id` in the payload. This attribute tells your agent exactly which project within Highlight should receive the structured OTLP logs.

**If I use ingest_raw_log, how do I handle sensitive user data?**
You are responsible for sanitizing any PII before calling this tool. While you can send raw text, always scrub names, emails, or IDs first to maintain privacy and security.

**If I run ingest_otlp_traces many times in a row, is there a rate limit?**
The system handles large data volumes, but rapid-fire calls may hit API limits. It's best practice to batch your trace payloads or implement a small delay between ingestion runs.

**What happens if the JSON I pass to ingest_otlp_logs is malformed?**
The agent will return an error message detailing the schema failure. It won't process incomplete data, requiring you to fix your payload before making a successful call.

**How can I send a basic text log message to my dashboard?**
You can use the `ingest_raw_log` tool. Simply provide the service name and the message content, and it will be sent directly to Highlight.

**Does this server support structured OpenTelemetry logs?**
Yes! Use the `ingest_otlp_logs` tool to send structured logs in OTLP JSON format. Ensure your payload includes the project ID attribute.

**Can I visualize request traces using this integration?**
Absolutely. The `ingest_otlp_traces` tool allows you to send OTLP JSON traces to Highlight, helping you track request spans and performance.