---
title: "What the server exposes"
description: "Nine tools that read, seven tools that change the lint rules, one tool that marks a finding fixed, and one resource, all served from the data on your Mac."
source: "https://getloggerhead.com/docs/mcp-server/what-the-server-exposes/"
---

# What the server exposes

> Nine tools that read, seven tools that change the lint rules, one tool that marks a finding fixed, and one resource, all served from the data on your Mac.

The Loggerhead MCP server is a small program, `loggerhead-mcp`. It speaks the Model Context Protocol over stdio to your coding tool, and it reads data from the Loggerhead engine over the local HTTP API. It never opens the database file itself.

## Tools

| Tool | Purpose |
| --- | --- |
| `query_logs` | Search and filter log records by text, severity, and time. |
| `query_metrics` | Read time-series metrics by name pattern and time. |
| `query_traces` | Search traces by service, operation, duration, and time. |
| `get_trace` | Read every span of one trace by trace ID. |
| `get_receiver_info` | Report the effective OTLP ports of the root receiver, the conflict flags, and the addresses to send to. |
| `query_improvements` | List the telemetry-quality findings from the Linting page, with filters for impact, source, and kind. A folded group carries its members. The result also lists the findings that resolved in the last 24 hours, with the reason. |
| `list_environments` | List every workspace with its environments, their `deployment.environment.name` tags, the receiver ports per workspace, and the pair the app reads now. |
| `list_lint_rules` | List the lint rules behind the Linting page: each rule's state, its thresholds with the value in force and the default, its exceptions, the ignored findings, and the recent changes with their source and reason. |
| `query_ai_findings` | List the findings of the last AI analysis run on the AI analysis page, with the status, the time, the window, and the model of the run. It does not start a run. |
| `set_lint_rule_enabled` | Switch a lint rule on or off for a workspace. |
| `set_lint_threshold` | Set one threshold of a lint rule. |
| `reset_lint_threshold` | Put one threshold back to its default. |
| `add_lint_exception` | Hide the findings of one rule that match a service, a metric, an attribute key, an operation, or a log message. |
| `remove_lint_exception` | Remove one exception. |
| `ignore_finding` | Ignore one finding by its id. |
| `unignore_finding` | Stop the ignore of one finding. |
| `mark_finding_fixed` | Mark one finding fixed after a code change, so Loggerhead judges it by the telemetry after the fix. |

The seven tools that change the lint rules need a reason. The rule settings belong to the workspace, so every environment of it uses a change. The Rules tab of the Linting page shows each change with its source (MCP or the app), its time, and its reason, and you can undo it there.

## Workspaces and environments

The app reads one environment at a time, and so does every tool. Each tool takes two optional arguments,
`workspace` and `environment`. Omitted, they mean the workspace and the environment the app shows. Name a
workspace by its name or its slug, and an environment by its name, its slug, or its `deployment.environment.name` tag.
Call `list_environments` first when you need the names. See
[Workspaces and environments](/docs/getting-started/workspaces-and-environments/).

## Resource

| Resource | Content |
| --- | --- |
| `loggerhead://stats` | Total counts of logs, metrics, and spans in the database. |

## What it cannot do

- It cannot delete data or send telemetry. The only settings it changes are the lint rules of a workspace, and each change has a reason that you can see and undo on the Rules tab of the Linting page.
- It cannot start an AI analysis. A run can send telemetry to a cloud model, so only the user starts it, in the app. `query_ai_findings` reads the last run.
- It cannot reach another machine. It talks to `127.0.0.1` only.
- It cannot see data that is not in Loggerhead. If a service does not send to the root, the tool cannot find it.

## Why it goes through the engine

DuckDB allows one process to hold the file. The engine holds it. The MCP server, the app, and any script all read through the engine's API. That is what lets the app and your coding tool work at the same time.