Mezmo MCP - Mezmo Docs

Mezmo MCP Server (Model Context Protocol)

Mezmo MCP is a remote Model Context Protocol (MCP) server that lets AI assistants and IDE chat agents interact with the Mezmo observability platform via the Model Context Protocol. Use it for streamlined observability, log analysis, and root-cause analysis in your favorite tools. Add Mezmo MCP and you can:

🕵️ Run advanced Root-cause analysis over recent logs
📦 List, describe, create, and edit Pipelines
🔌 Tap live pipeline traffic for inspection
📤 Export and filter Logs with powerful query syntax
🔎 Review AI Investigations for your account

Overview

Mezmo MCP is a remote MCP server that connects AI assistants and IDE chat to Mezmo so you can run advanced root-cause analysis, discover and build pipelines, and export logs without hosting anything yourself. It’s built for observability use cases and works across many popular MCP clients, including AURA, Mezmo’s own agentic SRE harness.

Available Tools & Examples

1. Log Analysis & Root Cause Detection

`analyze_logs_for_root_cause_relative_time`

Fetches, processes (deduplicates, clusters), and analyzes logs to determine potential root causes for incidents within a relative time range. Use cases:

Investigating recent incidents
Finding root causes of system failures
Analyzing error patterns

Example: “Analyze the logs from the last 30 minutes to find the root cause of API service returning 500 errors”

`analyze_logs_for_root_cause_time_range`

Similar to the relative time version but uses absolute time ranges. Example: “What caused the database connection pool to be exhausted between 10 AM and 11 AM today in the backend app?“

2. Log Deduplication

`deduplicate_logs_relative_time`

Removes duplicate log entries within a relative time range. Example: “Deduplicate the error logs from the payment service in the last 15 minutes”

`deduplicate_logs_time_range`

Deduplicates logs within an absolute time range. Example: “Remove duplicate exception logs from the web frontend between 2 PM and 3 PM yesterday”

3. Log Grouping & Aggregation

`group_logs_by_field`

Groups logs by a specific field and returns distribution of values with optional metric aggregation. Use cases:

“Which apps generate the most errors?”
“What is the p95 latency per host?”
“Which pods are producing the most logs?”

Examples: “Which apps are generating the most errors? Show me the top 10” “What’s the p95 latency for each host between 9 AM and 10 AM today?” “Show me the average memory usage by pod in the production namespace”

4. Log Visualization

`get_log_histogram`

Returns a time-series histogram of log volume over time. Use cases:

Visualizing log activity patterns
Identifying spikes or anomalies
Understanding when incidents occurred

Examples: “Show me a histogram of error logs over the last hour” “Create a histogram of API 500 errors from 8 AM to 12 PM today with 5-minute buckets” “Visualize warning logs from the production namespace over the last hour with 30-second granularity”

5. Field Discovery

`list_log_fields`

Lists available structured fields that can be used in log queries. Use cases:

Discovering available fields for queries
Finding field names like “app”, “host”, “level”, “namespace”, “pod”, “node”

Examples: “What log fields are available?” “Show me all fields that contain ‘kubernetes’” “List all fields that start with ‘http’” “Find all fields ending with _ms (timing metrics)” “Is there an ‘app’ field in the logs?” “Show me fields that start with ‘request’ and end with ‘time‘“

6. Pipeline Management

`list_pipelines`

Lists available Mezmo v3 pipelines. Example: “Show me all the Mezmo pipelines” “What pipelines are configured?”

`get_pipeline`

Gets details for a specific Mezmo v3 pipeline, including root-level DAG/configuration fields such as sources, transforms, and sinks when returned by the Pipeline API. Parameters:

pipeline_id (required): UUID of the pipeline

Example: “Show me the details for pipeline 123e4567-e89b-12d3-a456-426614174000” “What’s the configuration of the production-logs pipeline?”

`create_pipeline`

Creates an empty draft Mezmo pipeline. Sources, transforms, and destinations are added separately, and this tool does not publish the pipeline. Parameters:

title (required): Pipeline title
deploy_type (optional): Pipeline deploy type. Defaults to saas
deployment_groups (optional): Deployment groups for the pipeline

Example: “Create a new pipeline called ‘checkout-service-logs‘“

Pipeline node discovery

Use these tools to discover and inspect the source, transform/processor, and destination/sink schemas available from the Pipeline API before building a pipeline:

get_node_catalog: Returns the raw GET /pipeline/node catalog.
search_pipeline_node_schemas: Searches source, transform/processor, and destination/sink node schemas by kind and/or a free-text query, without surfacing nested JSON Schema fragments as selectable nodes.
get_pipeline_node_schema: Inspects a single node schema (node_type, optional kind) before constructing a Pipeline API body.

Example: “What source node types are available for HTTP ingestion?” “Show me the schema for the datadog-agent destination”

Building and editing pipelines

add_pipeline_source: Adds a source node to an existing pipeline from catalog/schema-backed payload fields (pipeline_id, node_type, optional title, description, user_config, extra_fields).
add_pipeline_transform: Adds a transform/processor node, wired to upstream nodes via raw UUIDs or aliases (pipeline_id, node_type, inputs, optional title, description, user_config, extra_fields).
add_pipeline_destination: Adds a destination node, mapped to the Pipeline API sink endpoint (same parameters as add_pipeline_transform).
create_pipeline_access_key: Creates a source gateway access key (gateway_route_id, title, optional key_type, extra_fields). Generated secret values are redacted from the MCP response.
update_pipeline_component: Updates an existing source, transform/processor, or destination/sink with a raw PUT payload (pipeline_id, component_id, kind, payload). Inspect get_pipeline and the relevant node schema first.
delete_pipeline_component: Deletes an existing source, transform/processor, or destination/sink (pipeline_id, component_id, kind). Use explicit confirmation before calling this, since it’s destructive.

Example: “Add an HTTP source to pipeline 123e4567-e89b-12d3-a456-426614174000” “Delete the old-syslog-source component from that pipeline”

`create_pipeline_from_manifest`

Creates a pipeline end to end from a manifest: creates the pipeline, adds sources, optionally creates generated access keys, adds transforms/processors, adds destinations/sinks, and publishes only when publish is explicitly true. Parameters:

title (required): Pipeline title
deploy_type, deployment_groups, config (optional): Same as create_pipeline
sources, transforms, destinations (optional): Arrays of node specs, each with an alias, type, optional title, description, user_config, inputs, and access_key
publish (optional): Publish the pipeline once created. Defaults to false

Node inputs can reference other nodes by alias (for example alias.Default or alias.outputs[0]) or by raw UUID, letting the agent wire the whole DAG in one call. Example: “Create a pipeline named ‘payments-pipeline’ with an HTTP source feeding a JSON parser transform and a Datadog destination, and publish it”

`tap_pipeline_component`

Taps live events from a deployed pipeline component via /pipeline/{pipeline_id}/tap/{component_id}. Parameters:

pipeline_id (required): UUID of the pipeline
component_id (required): UUID of the source or processor component to tap
timeout (optional): Seconds to wait for events. Defaults to 2
limit (optional): Maximum events to return, capped at 100 to keep agent context bounded. Defaults to 100

Use get_pipeline first to identify a source or processor component ID, and treat returned event data as potentially sensitive. Example: “Tap the http-source component on pipeline 123e4567-e89b-12d3-a456-426614174000 and show me a sample of live events”

`pause_pipeline` / `unpause_pipeline`

Sets a pipeline’s processing_status to disabled or enabled respectively. Neither tool publishes or edits the pipeline DAG. Parameters:

pipeline_id (required): UUID of the pipeline

Example: “Pause pipeline 123e4567-e89b-12d3-a456-426614174000” “Unpause the checkout-service-logs pipeline”

`publish_pipeline`

Publishes a pipeline’s current draft configuration. Parameters:

pipeline_id (required): UUID of the pipeline

publish_pipeline is never called automatically by create_pipeline_from_manifest unless publish is explicitly set to true, so draft pipelines stay unpublished until you confirm.

7. Time Utilities

`get_current_time`

Returns the current server time in various formats. Example: “What time is it right now?” “Get the current timestamp” Use cases:

Determining time ranges for log analysis
Converting between time formats

`relative_time_to_time_range`

Converts relative time expressions to absolute time ranges in milliseconds. Examples: “Convert ‘last 5 minutes’ to an absolute time range” “What’s the timestamp range for ‘2 hours ago’?“

8. Trace Analysis

These tools analyze OpenTelemetry trace data across your entire account, so you don’t need to specify a source or component. Trace, span, and failure data lags behind real time by roughly a couple of minutes. The degraded-edge and latency-summary tools (find_degraded_service_edges and list_service_latency_summaries) draw on latency summaries that can lag further, sometimes by hours, and fill in windows retroactively as backlogs drain, so very recent activity may not appear immediately.

These trace tools appear in the tool list, and are callable, only when Mezmo has analyzed trace data from your account within roughly the last 24 hours (the default look-back window). If your account has no recent analyzed trace data, the tools are hidden and do not appear. Mezmo evaluates availability automatically, and there is no feature flag to turn on. If an agent calls one of these tools while it is unavailable, the server responds with a tool not found error, the same as for an unknown tool.

get_service_graph: Gets the service graph showing service-to-service calls by operation. Takes no arguments. The graph is built from completed traces, so a missing edge does not prove that the call never happens.
list_failed_traces: Lists failed traces within a time range, optionally filtered by service. Supports an optional limit (1 to 500, default 100). Only traces with at least one failed span are indexed, so an empty result means no failures, not no traffic.
get_trace_spans: Gets the spans for a given trace_id. Obtain the trace_id from list_failed_traces or get_service_failures (both described in this section). Supports optional limit (1 to 500, default 250), failed_only (default false, returns only failing spans), and include_attributes (default false, includes span attributes).
find_degraded_service_edges: Detects service-call edges with degraded latency by comparing a current period to a baseline period, and surfaces newly appearing edges. Returns edges where the selected percentile metric increased beyond the threshold you set. Use it to spot service-to-service calls that are changing behavior. Parameters:
- current_from_time (required): Start of the current window, as an RFC3339 timestamp (for example, 2023-01-01T00:00:00Z).
- current_to_time (required): End of the current window, as an RFC3339 timestamp.
- baseline_from_time (required): Start of the baseline window, as an RFC3339 timestamp.
- baseline_to_time (required): End of the baseline window, as an RFC3339 timestamp.
- metric (optional): Percentile to compare. One of p50, p90, p95, or p99. Defaults to p99.
- threshold (optional): Minimum ratio of current to baseline latency that counts as degraded, so 2.0 means current latency is at least twice the baseline. Defaults to 2.0.
- limit (optional): Maximum number of edges to return, from 1 to 100. Defaults to 20.
- min_sample_count (optional): Edges with fewer samples are treated as low confidence and suppressed. Defaults to 30.
- include_low_confidence (optional): Include low-confidence rows. Defaults to false.
list_service_latency_summaries: Fetches bucketed latency summaries for operations between a service and its target. Each result is a timestamped bucket with latency metrics like p50, p95, and p99, plus a mean.
get_service_failure_rates: Gets service failure rates as a histogram over the window you provide, optionally grouped by service, edge, or operation.
get_service_failures: Fetches individual service failure records, optionally filtered by service, edge, or operation.

Examples: “Show me the service graph for my account” “Which services have degraded latency compared to last week?” “List failed traces for the checkout-service in the last hour”

9. Correlated Timeline

`get_correlated_timeline_relative_time`

Builds a correlated timeline of logs across multiple sources within a relative time range. Groups logs by a source field (like app, host, or any custom field) to help with root cause investigation. Use cases:

Investigating incidents across multiple services or hosts
Understanding the sequence of events leading to a failure
Correlating errors across apps in a distributed system

Example: “Show me a correlated timeline of error logs from all apps in the last 30 minutes”

`get_correlated_timeline_time_range`

Same as above, but uses absolute time ranges. Example: “Build a timeline of all warnings and errors between 10 AM and 11 AM today, grouped by host”

Key options

Grouping field: Logs are grouped by _app by default. You can also group by _host, level, or any custom field
Deduplication mode: Use template mode (default) to show one example per unique log pattern, or none for raw chronological order
Limits: Control how many logs per source and total timeline events to return

10. AI Investigations

An AI investigation is an AI-generated root-cause and analysis record for your account. Mezmo triggers investigations internally, for example from a Pipeline Node Alert. These two tools read and list existing investigations; they do not create them. Your account needs the appropriate investigation permission to use these tools; this is managed through your account’s roles and permissions.

`list_ai_investigations`

Lists AI-generated investigations for your account. Parameters:

state (optional): filter by investigation state; one of triggered, investigating, or completed
last_id (optional): pagination cursor; the id of the last investigation from the previous page
updated_since (optional): an RFC3339 date-time; returns only investigations updated since then
limit (optional): maximum number of results, from 1 to 1000. Defaults to 1000

To fetch the next page, pass the last returned investigation’s id as last_id. Example: “List my completed AI investigations from the last day” “Show me AI investigations that are still investigating”

`get_ai_investigation`

Gets details for a specific AI investigation by id. A returned investigation includes its state and the AI’s root-cause findings, such as a confidence score and suggested resolution. Parameters:

investigation_id (required): the id of the investigation to retrieve

Example: “Show me the details for investigation 66f1a2b3c4d5e6f7a8b9c0d1”

Query Syntax

Many MCP tools accept a query parameter that filters logs. You can combine text search with fielded queries to find specific logs.

Text Search

For basic searches, provide keywords. The query matches any logs containing those terms (case-insensitive, with automatic prefix-matching):

connection timeout

Prefix-matching is automatic. For example, timeout matches timeout, timeouts, and timeout_error without needing a wildcard.

Fielded Search

Use field:value syntax to search specific structured fields:

app:payment-service
level:error
host:prod-api-01

Common Fields

These fields are available in most log data:

Field	Description
`app`	Application or service name
`host`	Hostname or server identifier
`level`	Log level (error, warn, info, debug)
`env`	Environment (production, staging, dev)
`source`	Log source identifier
`tag`	Tags applied to the log
`namespace`	Kubernetes namespace
`pod`	Kubernetes pod name
`node`	Kubernetes node name

Nested Fields

For nested or JSON fields, use dotted paths:

user.id:12345
request.body.status:failed
kubernetes.labels.app:frontend

Numeric Comparisons

Query numeric fields using comparison operators:

status:>=400
latency_ms:<100
response_time:>500

Field Existence

Use field:* to match logs where a specific field is present:

error_code:*
user.id:*

This is useful for finding logs that have a particular field, regardless of its value.

The * character is only valid for field existence checks (field:*). Do not use wildcards in query terms or field values (for example, pod:vector-* or host:prod-*). Prefix-matching is automatic, so pod:vector already matches vector-gen14-abc, vector-prod-01, and similar values.

Combining Queries

Combine multiple conditions to narrow your search:

level:error app:checkout-service status:>=500

Query Protection for Large Log Volumes

Mezmo MCP protects against queries that would process too much data. This keeps performance fast and ensures queries finish quickly.

How It Works

When you run a tool that processes logs, Mezmo MCP checks how many entries match your query:

Confirmation prompt: If your query matches a large number of logs, the server asks you to confirm before proceeding. You can narrow your query or confirm to continue.
Query rejection: If your query matches an extremely large number of logs, the request is rejected. Try narrowing your time range or adding more specific filters.

Affected Tools

These tools have query protection:

analyze_logs_for_root_cause_relative_time / analyze_logs_for_root_cause_time_range
deduplicate_logs_relative_time / deduplicate_logs_time_range
get_correlated_timeline_relative_time / get_correlated_timeline_time_range
get_log_histogram
group_logs_by_field

Tips for Working with Large Datasets

If you see a confirmation prompt or rejection:

Narrow your time range. Try “last 1 hour” instead of “last 24 hours”.
Add filters. Use fielded search to target specific logs (for example, app, host, level, namespace, or pod). See Query Syntax for the full list.
Confirm when appropriate. If you’ve reviewed the log count and want to proceed, confirm the prompt.

Retention Window Limits

Queries must fall within your account’s retention window. If you query logs outside this window, you’ll receive an error showing the valid time range. For example, querying logs from 6 months ago on a 7-day retention account will fail.

Use relative time ranges like last 15 minutes or last 1 hour to ensure your queries stay within retention.

Best Practices

Start broad for root-cause analysis
If the query is too narrow, our RCA can’t do its thing. Cast a wide net, and if needed, specify app/service/level in subsequent queries.
Prefer analyze_logs_for_root_cause or deduplicate_log tools for insights
These tools deduplicate and groups similar logs for better summaries, allowing the results to fit into finite LLM context windows.
Use relative time ranges
Prefer values like last_15_minutes, last_hour when supported.
Keep prompts simple; add filters gradually
Add filters step by step. See Query Syntax for available fields.
Use export_logs for raw data only
For dashboards or offline analysis, use export_logs; otherwise prefer RCA.

Installation

Requirements

A Mezmo Service Key (generate one in your Mezmo dashboard under Settings > API Keys; see Mezmo docs for details)
Node.js ≥ 18 (only needed for clients that use the mcp-remote bridge)
One of the supported MCP clients below

For every client we follow a simple rule:

Supports remote URL? → configure it with a url that points to https://mcp.mezmo.com/mcp and include the Authorization header.
StdIO-only client? → use the mcp-remote bridge:

AUTH_HEADER="Bearer <SERVICE KEY>" npx mcp-remote https://mcp.mezmo.com/mcp \
  --header "Authorization:${AUTH_HEADER}"

Client Configurations

AURA

AURA is Mezmo’s open-source agentic SRE harness. It’s MCP-native, so you can point an AURA agent at the Mezmo MCP server and its tools become available at runtime for root-cause analysis, log queries, and pipeline management. Add a [mcp.servers.mezmo] block to your AURA config (config.toml or a file in your configs/ directory):

[mcp.servers.mezmo]
transport = "http_streamable"
url = "https://mcp.mezmo.com/mcp"
description = "Mezmo root-cause analysis, log analysis, export, and pipeline management"

[mcp.servers.mezmo.headers]
Authorization = "Bearer <SERVICE KEY>"

AURA renders header values as Liquid templates, so you can keep your Service Key out of the config file and read it from the environment instead: Authorization = "Bearer {{ env.MEZMO_SERVICE_KEY | default: '' }}".

See the AURA quickstart and the bundled incident-response-mezmo.toml example for a full agent that pairs Mezmo with other MCP servers.

Cursor

Cursor natively supports remote MCP servers, so you only need a remote configuration. Install Mezmo MCP Server in Cursor Clicking the Install MCP Server badge opens Cursor and automatically adds the mezmo entry to your ~/.cursor/mcp.json with a placeholder for the Service Key. After it’s created, edit the file and replace <SERVICE KEY> with your actual Mezmo service key. Restart Cursor for changes to take effect. The final configuration should look like the example below.

{
  "mcpServers": {
    "mezmo": {
      "url": "https://mcp.mezmo.com/mcp",
      "headers": {
        "Authorization": "Bearer <SERVICE KEY>"
      }
    }
  }
}

Windsurf

Windsurf also supports remote servers via the serverUrl field.

{
  "mcpServers": {
    "mezmo": {
      "serverUrl": "https://mcp.mezmo.com/mcp",
      "headers": {
        "Authorization": "Bearer <SERVICE KEY>"
      }
    }
  }
}

Trae

{
  "mcpServers": {
    "mezmo": {
      "url": "https://mcp.mezmo.com/mcp",
      "headers": {
        "Authorization": "Bearer <SERVICE KEY>"
      }
    }
  }
}

VS Code’s Copilot Chat or Visual Studio 2022

"mcp": {
  "servers": {
    "mezmo": {
      "type": "http",
      "url": "https://mcp.mezmo.com/mcp",
      "headers": {
        "Authorization": "Bearer <SERVICE KEY>"
      }
    }
  }
}

Zed

{
  "context_servers": {
    "mezmo": {
      "url": "https://mcp.mezmo.com/mcp",
      "headers": {
        "Authorization": "Bearer <SERVICE KEY>"
      }
    }
  }
}

Gemini CLI

{
  "mcpServers": {
    "mezmo": {
      "command": "npx",
      "args": [
        "mcp-remote",
        "https://mcp.mezmo.com/mcp",
        "--header",
        "Authorization:${AUTH_HEADER}"
      ],
      "env": {
        "AUTH_HEADER": "Bearer <SERVICE KEY>"
      }
    }
  }
}

Claude Code

claude mcp add --transport http mezmo https://mcp.mezmo.com/mcp \
  --header "Authorization: Bearer <SERVICE KEY>"

Claude Desktop

{
  "mcpServers": {
    "Mezmo": {
      "command": "npx",
      "args": [
        "mcp-remote",
        "https://mcp.mezmo.com/mcp",
        "--header",
        "Authorization:${AUTH_HEADER}"
      ],
      "env": {
        "AUTH_HEADER": "Bearer <SERVICE KEY>"
      }
    }
  }
}

BoltAI

{
  "mcpServers": {
    "mezmo": {
      "command": "npx",
      "args": [
        "mcp-remote",
        "https://mcp.mezmo.com/mcp",
        "--header",
        "Authorization:${AUTH_HEADER}"
      ],
      "env": {
        "AUTH_HEADER": "Bearer <SERVICE KEY>"
      }
    }
  }
}

Windows (CMD)

{
  "mcpServers": {
    "mezmo": {
      "command": "cmd",
      "args": [
        "/c",
        "npx",
        "mcp-remote",
        "https://mcp.mezmo.com/mcp",
        "--header",
        "Authorization:${AUTH_HEADER}"
      ],
      "env": {
        "AUTH_HEADER": "Bearer <SERVICE KEY>"
      }
    }
  }
}

Augment Code

Add a new MCP and enter:

AUTH_HEADER="Bearer <SERVICE KEY>" npx mcp-remote https://mcp.mezmo.com/mcp \
  --header "Authorization:${AUTH_HEADER}"

Roo Code

Roo Code supports remote URLs:

{
  "mcpServers": {
    "mezmo": {
      "type": "streamable-http",
      "url": "https://mcp.mezmo.com/mcp",
      "headers": {
        "Authorization": "Bearer <SERVICE KEY>"
      }
    }
  }
}

ZenCoder

{
  "command": "npx",
  "args": [
    "mcp-remote",
    "https://mcp.mezmo.com/mcp",
    "--header",
    "Authorization:${AUTH_HEADER}"
  ],
  "env": {
    "AUTH_HEADER": "Bearer <SERVICE KEY>"
  }
}

Amazon Q Developer CLI

{
  "mcpServers": {
    "mezmo": {
      "command": "npx",
      "args": [
        "mcp-remote",
        "https://mcp.mezmo.com/mcp",
        "--header",
        "Authorization:${AUTH_HEADER}"
      ],
      "env": {
        "AUTH_HEADER": "Bearer <SERVICE KEY>"
      }
    }
  }
}

Qodo Gen

{
  "mcpServers": {
    "mezmo": {
      "url": "https://mcp.mezmo.com/mcp",
      "headers": {
        "Authorization": "Bearer <SERVICE KEY>"
      }
    }
  }
}

JetBrains AI Assistant

{
  "mcpServers": {
    "mezmo": {
      "command": "npx",
      "args": [
        "mcp-remote",
        "https://mcp.mezmo.com/mcp",
        "--header",
        "Authorization:${AUTH_HEADER}"
      ],
      "env": {
        "AUTH_HEADER": "Bearer <SERVICE KEY>"
      }
    }
  }
}

Warp

{
  "Mezmo": {
    "command": "npx",
    "args": [
      "mcp-remote",
      "https://mcp.mezmo.com/mcp",
      "--header",
      "Authorization:${AUTH_HEADER}"
    ],
    "env": {
      "AUTH_HEADER": "Bearer <SERVICE KEY>"
    },
    "working_directory": null,
    "start_on_launch": true
  }
}

OpenCode

"mcp": {
  "mezmo": {
    "type": "remote",
    "url": "https://mcp.mezmo.com/mcp",
    "headers": {
      "Authorization": "Bearer <SERVICE KEY>"
    },
    "enabled": true
  }
}

Codex CLI

Add to ~/.codex/config.toml:

[mcp_servers.mezmo]
command = "npx"
args = [
  "mcp-remote",
  "https://mcp.mezmo.com/mcp",
  "--header",
  "Authorization:${AUTH_HEADER}",
]
env = { AUTH_HEADER = "Bearer <SERVICE KEY>" }

Codex defaults to being sandboxed, so you’ll also need to give it network access. If you want to run in a sandbox mode of workspace-write for example, add this:

[sandbox_workspace_write]
network_access = true

You can either start with a flag like codex --sandbox workspace-write or set a default mode with:

sandbox_mode = "workspace-write"

Troubleshooting

1. `npx` argument-escaping bug

Some clients pass command-line arguments to npx without quoting spaces. This can split the Authorization header (e.g. Bearer and the token become separate arguments) and cause authentication failures. Work-around: store the header in an environment variable and pass it without spaces:

{
  "command": "npx",
  "args": [
    "mcp-remote",
    "https://mcp.mezmo.com/mcp",
    "--header",
    "Authorization:${AUTH_HEADER}"
  ],
  "env": {
    "AUTH_HEADER": "Bearer <SERVICE KEY>"
  }
}

2. Lost connection to the Mezmo MCP server

If your client shows an error such as “server disconnected” or stops responding to MCP commands:

Disable or remove the Mezmo MCP entry in your client settings.
Re-enable (or re-add) the same entry, or simply restart the client.

This forces the client to establish a fresh connection to the Mezmo MCP backend.

3. 401/403 authentication errors

Verify the Authorization header is present and formatted as Bearer <SERVICE KEY>.
If using npx mcp-remote, prefer the environment variable approach to avoid splitting the header.
Regenerate your Service Key in Mezmo and try again if issues persist.

Next Steps

Once your client is configured you can immediately run natural-language commands such as

analyze my logs from the last 30 minutes and determine root cause for any issues that you find
list all my pipelines
show me details for pipeline <pipeline title>
deduplicate error logs from the last 30 minutes for app "my-app-frontend"
create a pipeline that ingests from HTTP, drops unnecessary data, and stores the rest in Log Analysis
tap the source component on <pipeline title> and show me a sample of live events

Enjoy streamlined observability with Mezmo + AI! 🎉

​Mezmo MCP Server (Model Context Protocol)

​Overview

​Available Tools & Examples

​1. Log Analysis & Root Cause Detection

​analyze_logs_for_root_cause_relative_time

​analyze_logs_for_root_cause_time_range

​2. Log Deduplication

​deduplicate_logs_relative_time

​deduplicate_logs_time_range

​3. Log Grouping & Aggregation

​group_logs_by_field

​4. Log Visualization

​get_log_histogram

​5. Field Discovery

​list_log_fields

​6. Pipeline Management

​list_pipelines

​get_pipeline

​create_pipeline

​Pipeline node discovery

​Building and editing pipelines

​create_pipeline_from_manifest

​tap_pipeline_component

​pause_pipeline / unpause_pipeline

​publish_pipeline

​7. Time Utilities

​get_current_time

​relative_time_to_time_range

​8. Trace Analysis

​9. Correlated Timeline

​get_correlated_timeline_relative_time

​get_correlated_timeline_time_range

​Key options

​10. AI Investigations

​list_ai_investigations

​get_ai_investigation

​Query Syntax

​Text Search

​Fielded Search

​Common Fields

​Nested Fields

​Numeric Comparisons

​Field Existence

​Combining Queries

​Query Protection for Large Log Volumes

​How It Works

​Affected Tools

​Tips for Working with Large Datasets

​Retention Window Limits

​Best Practices

​Installation

​Requirements

​Client Configurations

​AURA

​Cursor

​Windsurf

​Trae

​VS Code’s Copilot Chat or Visual Studio 2022

​Zed

​Gemini CLI

​Claude Code

​Claude Desktop

​BoltAI

​Windows (CMD)

​Augment Code

​Roo Code

​ZenCoder

​Amazon Q Developer CLI

​Qodo Gen

​JetBrains AI Assistant

​Warp

​OpenCode

​Codex CLI

​Troubleshooting

​1. npx argument-escaping bug

​2. Lost connection to the Mezmo MCP server

​3. 401/403 authentication errors

​Next Steps

Mezmo MCP Server (Model Context Protocol)

Overview

Available Tools & Examples

1. Log Analysis & Root Cause Detection

`analyze_logs_for_root_cause_relative_time`

`analyze_logs_for_root_cause_time_range`

2. Log Deduplication

`deduplicate_logs_relative_time`

`deduplicate_logs_time_range`

3. Log Grouping & Aggregation

`group_logs_by_field`

4. Log Visualization

`get_log_histogram`

5. Field Discovery

`list_log_fields`

6. Pipeline Management

`list_pipelines`

`get_pipeline`

`create_pipeline`

Pipeline node discovery

Building and editing pipelines

`create_pipeline_from_manifest`

`tap_pipeline_component`

`pause_pipeline` / `unpause_pipeline`

`publish_pipeline`

7. Time Utilities

`get_current_time`

`relative_time_to_time_range`

8. Trace Analysis

9. Correlated Timeline

`get_correlated_timeline_relative_time`

`get_correlated_timeline_time_range`

Key options

10. AI Investigations

`list_ai_investigations`

`get_ai_investigation`

Query Syntax

Text Search

Fielded Search

Common Fields

Nested Fields

Numeric Comparisons

Field Existence

Combining Queries

Query Protection for Large Log Volumes

How It Works

Affected Tools

Tips for Working with Large Datasets

Retention Window Limits

Best Practices

Installation

Requirements

Client Configurations

AURA

Cursor

Windsurf

Trae

VS Code’s Copilot Chat or Visual Studio 2022

Zed

Gemini CLI

Claude Code

Claude Desktop

BoltAI

Windows (CMD)

Augment Code

Roo Code

ZenCoder

Amazon Q Developer CLI

Qodo Gen

JetBrains AI Assistant

Warp

OpenCode

Codex CLI

Troubleshooting

1. `npx` argument-escaping bug

2. Lost connection to the Mezmo MCP server

3. 401/403 authentication errors

Next Steps