Parseable MCP Server Is Live

Most incident work does not get hard because there is no data. It gets hard because the data is spread across enough places that every next question costs another context switch.

When a service starts failing, the alert is only the opening clue. Someone still has to ask which route is noisy, which customer path is affected, whether latency moved first, whether traces and logs agree, and whether the problem started after a deploy. Each question is small on its own, but during an incident they stack up fast.

Observability systems have become very good at storing signals. The slower part is often translating an operational question into the right dataset, schema, query, time window, and follow-up query. That is the kind of work an MCP client can help with when it has safe, explicit tools for the system it is querying.

With our 3.0 release, we are bringing the Parseable MCP Server to make that loop shorter. It connects Claude, Cursor, VS Code, Codex, and other MCP-compatible clients to the telemetry already stored in Parseable. You ask the operational question, the client discovers the relevant data and calls the Parseable tools needed to inspect it. It works with Parseable Cloud and self-hosted deployments through the hosted HTTP endpoint or the open-source server over stdio.

What the server exposes

The server covers more than log search. An MCP client can inspect datasets and schemas, run SQL over logs and events, run PromQL against metrics, inspect alerts, check cluster health, and review users and roles.

The tools follow the usual shape of an investigation:

• list_datasets, get_dataset_schema, get_dataset_info, get_dataset_stats, and sample_events show what data is available and how it is structured.
• query_sql runs analytical queries over a required time window. It accepts SELECT statements only and adds a default row limit when the query does not include one.
• query_promql runs instant and range queries against metrics datasets.
• Alert tools inspect, create, enable, disable, or evaluate alerts and notification targets.
• Diagnostic tools check connectivity, explain SQL queries, and return cluster ingest, query, and storage metrics.
• RBAC and retention tools provide read-only access to users, roles, privileges, and dataset retention.

These tools can be chained as the investigation narrows. A broad report of 5xx errors can become a route-level query, then a trace-ID search, then a check against latency metrics without starting again.

Here are a few workflows that show what that looks like.

1. A 5xx alert fires

Suppose the checkout service crosses its error-rate threshold. The alert tells you that something is wrong, but it does not tell you whether one route is responsible or whether several failures are being counted together.

You can ask:

Investigate 5xx errors from the checkout service during the last 30 minutes. Group them by route and status code, show the most common error messages, and retrieve representative events with trace IDs.

Schema inspection comes first. It reveals the actual service, route, status, message, and trace fields instead of guessing how your telemetry is named.

From there, query_sql counts failures by route, groups the repeated messages, and retrieves a small set of events from the largest group. Any returned trace IDs become the next filter for the surrounding request activity.

The original alert is now reduced to one route, one error signature, and a few representative traces.

If the generated SQL looks expensive or unclear, the client can call explain_query before it runs. The time window remains explicit on every query, so the investigation does not quietly expand across the full retention period.

2. Follow one trace across the logs

A trace ID is often the cleanest lead you have. The awkward part is that related events may sit in different datasets, and each service may use a different field name for the same trace attribute.

Ask:

Show me all log events for trace ID abc-123-xyz. Order them by time, group them by service, and highlight errors or unusually slow operations.

The likely datasets are inspected for trace ID and timestamp fields. Time-bounded SQL queries retrieve the matching records, which are then ordered into a single timeline.

Now you can see where the request entered the system, which services handled it, and what happened immediately before the failure. If the payment service logged an error after a slow database call, that sequence stays visible. You do not have to reconstruct it from separate tabs.

Schema discovery matters here. One dataset may use trace_id, another may follow the OpenTelemetry trace.id convention, and a third may carry the value inside a nested field. The returned schemas show where to look in each service.

3. Take a production error back to the code

An AI coding client already knows the repository. What it usually lacks is the production behavior of that code.

With Parseable connected, ask the coding client to find ERROR and WARN events from the inventory service in the last hour, group repeated messages, and show representative stack traces. It can then identify which source files or functions may emit them.

The Parseable tools handle the production side of the question. Schema inspection locates the severity, message, stack-trace, and source fields. A SQL query groups the repeated errors and retrieves a few examples. The repository search then starts from a real logger, function, or stack frame.

The coding assistant now has the error frequency, surrounding fields, and examples from the period in which the problem occurred, rather than one isolated message.

The proposed code change still needs review. Run the relevant tests, deploy it through the normal path, and query the same error group again. The second query is what tells you whether the change affected production behavior.

4. Explain a latency regression

A latency chart tells you when a service became slower. It rarely tells you what changed at the same time.

For example:

Compare p95 request latency for the payments service during the 30 minutes before and after the latest deployment. Identify the operations with the largest increase, then check for matching errors or warnings in that period.

query_promql compares the two windows and breaks the result down by operation or endpoint when those labels are available. Once the slower operation is clear, query_sql checks the related events over the same period.

The p95 increase may line up with one route, a repeated timeout, or a warning that started after the deployment. It may also have no matching error at all. That absence is useful evidence and avoids overstating the connection between the deployment and the regression.

5. Review an alert before changing it

Alert configuration is easy to change and harder to reason about during an incident. The safer order is to inspect the current alert, understand the query and target, and then decide whether the alert should change.

Start with a read-only request for all alerts tagged payments. Ask for the checkout error-rate alert's query, current threshold, severity, notification target, and enabled state.

list_alerts, get_alert, and get_alert_target provide the current configuration. The underlying query can then be explained or run over a bounded time window to show what the condition matches in recent data.

After that, you can ask it to enable or disable the alert, create a new target, or build a replacement alert through the guided flow. These are real configuration changes, so they remain visible tool calls for you to approve. evaluate_alert may send a real notification as well.

Connect your MCP client

The quickest setup is the interactive installer:

npx -y @parseable/parseable-mcp-server@latest init

It detects supported clients, asks whether you use Parseable Cloud or a self-hosted instance, and writes the client configuration. Restart the client after setup and the Parseable tools will appear in its MCP tool list.

You can also connect directly to the hosted Streamable HTTP endpoint. For Parseable Cloud with Claude Code:

claude mcp add --transport http parseable https://mcp.parseable.com/mcp \
  --scope user \
  --header "X-Parseable-Mode: cloud" \
  --header "X-API-Key: your-parseable-api-key"

For a self-hosted Parseable instance:

claude mcp add --transport http parseable https://mcp.parseable.com/mcp \
  --scope user \
  --header "X-Parseable-URL: https://your-parseable.example.com" \
  --header "X-API-Key: your-parseable-api-key"

If you prefer to keep the MCP process on your machine, run the open-source npm package over stdio.

Use a dedicated API key with the permissions needed for the workflow, and treat it like any other production credential. Read-only access is a good starting point when the client only needs to investigate data.

Available now

The Parseable MCP Server is available for Parseable Cloud and self-hosted users.

• Open the MCP setup page
• Read the source and configuration guide
• Install the npm package
• Try Parseable Cloud

Once connected, start with the alert already in front of you: ask which route is producing the 5xx errors and inspect the query Parseable runs to answer it.