langfuse-api-mcp

# langfuse-api-mcp

An MCP server that gives AI agents access to the full [Langfuse](https://langfuse.com) public API. It works with **Langfuse Cloud** in any region and with **self-hosted** instances. It is built to run on corporate networks that re-sign TLS traffic with their own certificate authority (CA).

> [!IMPORTANT]
> **Status: pre-alpha, release `v0.2.0`** (semver `0.x`: no stability promise yet; the first release was `v0.1.0`). Everything below works today unless it is marked **Planned**, like the loopback HTTP transport.

**Contents:** [What it is](#what-it-is) · [Tools](#tools) · [User skill](#user-skill) · [Install and run](#install-and-run) · [Client configuration](#client-configuration) · [Configuration](#configuration) · [Security model](#security-model) · [Troubleshooting](#troubleshooting) · [Learn more](#learn-more)

---

## What it is

A small, stateless program that your AI tool (Claude Code, Claude Desktop, Cursor, VS Code, Codex, …) starts on your machine. It speaks the [Model Context Protocol](https://modelcontextprotocol.io) to the agent and HTTPS to Langfuse. The agent can then:

- investigate traces, observations, sessions, errors, latency and cost;
- read prompts, datasets, experiments, scores, metrics, models, comments and annotation queues;
- make changes, such as promoting a prompt label, creating a score or editing a dataset. This works **only if you turn writes on** (see [Security model](#security-model)).

```mermaid
flowchart LR
  A[AI agent<br/>Claude Code, Cursor, …] -- MCP over stdio --> S[langfuse-mcp<br/>on your machine or in Docker]
  S -- HTTPS + your corporate CA --> P{{Corporate proxy<br/>optional}}
  P --> L[(Langfuse<br/>Cloud or self-hosted)]
  S -. reads .-> C[/Your config:<br/>keys, host, CA files/]
  classDef local fill:#e0f2fe,stroke:#0369a1,color:#0c4a6e;
  classDef remote fill:#fef3c7,stroke:#b45309,color:#78350f;
  class A,S,C local;
  class L,P remote;
```

### When to use it

| Situation | Use this server? |
|---|---|
| Your company network inspects TLS with a custom root CA, and the official Langfuse MCP or CLI fails with `self-signed certificate in certificate chain` / `unable to get local issuer certificate` | **Yes.** This is the main reason the project exists. |
| You want the agent to be **unable** to change Langfuse data unless you explicitly allow it | **Yes.** It is read-only by default, and the server enforces this itself for every call made through it. Keep the keys out of the agent's own environment, or another tool can use them directly: [Keep the keys out of the agent's environment](#keep-the-keys-out-of-the-agents-environment). |
| You run a self-hosted Langfuse behind an internal CA or proxy | **Yes.** |
| You want a single binary with no Node.js or Python runtime on your machine | **Yes.** |
| You only need Langfuse *documentation* in your agent | No. Use the official docs MCP at `https://langfuse.com/api/mcp`. |
| Your agent can run shell commands and your network has no TLS interception | Either works. Langfuse also offers an official CLI and Agent Skill. |

### How it differs from the official Langfuse MCP

| | Official project MCP (`<host>/api/public/mcp`) | This server |
|---|---|---|
| Where it runs | Remote, inside Langfuse | Locally (binary or Docker) |
| Custom CA / corporate proxy | Depends on your MCP client's runtime; no documented options | Explicit settings, plus automatic pickup of CA variables that are already set on your system |
| Writes | Enabled by default; to restrict them you configure a client-side allowlist | **Off by default**. The write tool does not exist until you enable it. |
| API coverage | Curated tool set | Every operation your Langfuse deployment actually answers — older self-hosted versions keep their legacy APIs, newer ones get the new APIs — except trace ingestion and organization admin changes (creating/deleting projects, API keys, users). Detected automatically at startup, with nothing to configure ([Deployment profile](docs/reference/configuration.md#deployment-profile)) |

## Tools

The Langfuse API has about 100 in-scope operations. One tool per operation would fill the agent's context window, so the server exposes a small set of tools:

| Tool | What it does | Available |
|---|---|---|
| `search_operations` | Lists the Langfuse operations your deployment serves, optionally filtered by keywords (in write mode, each write operation with its HTTP method and whether it is destructive) | always |
| `describe_operation` | Returns the parameters of one operation that your deployment's Langfuse version serves (and, apart from them, a filter the server applies itself when your version lacks it; and, in write mode, its body schema (the one of your deployment's Langfuse version), whether it is destructive and, for `comments_create` and `scores_create`, how to fill the body) | always |
| `execute_read` | Runs a **read** operation (HTTP GET) by its ID and returns the Langfuse JSON inside an untrusted-data envelope. On an older Langfuse that ignores the `traceId` of `scores_get-many` or the `level` of `legacy_observationsV1_getMany`, the server applies that filter itself and says whether it read the whole list | always |
| `execute_write` | Runs a **write** operation by its ID; a destructive one (DELETE, PUT, PATCH) only after you confirm that exact call | only in [write mode](#security-model) |
| `get_trace_tree` | Returns every observation of one trace as a tree in one call. It reads Observations v2 where the deployment answers the v4 read APIs (Cloud, self-hosted v4) and the legacy observations list on self-hosted v3, where input, output and metadata are removed unless you ask for them and a row holds the fields that Langfuse returns (latency in milliseconds there, in seconds on v4), minus those it returned as null. Where a deployment answers both, the tree is read from Observations v2, which can lack observations that were sent through the legacy ingestion API, so an empty or short tree can be checked against the legacy observations list through `execute_read`. Where neither API answers it says `operation_unavailable` | always listed; runs where the deployment answers either API |

A typical session: `search_operations` finds the operation, `describe_operation` shows its parameters, `execute_read` runs it:

```json
{"operationId": "trace_list", "parameters": {"limit": 10, "tags": ["prod", "checkout"]}}
```

The server keeps nothing between calls (it is stateless). It never takes a URL, host or credential from the agent. It only runs operations from its built-in catalog, against the host you configured. Every call is validated before anything is sent, and every failure comes back as a structured tool error with a `code`, a `hint` and a `retryable` flag. Parameters, error codes, result limits and the audit line: [Tools reference](docs/reference/tools.md).

## User skill

The server gives an agent generic tools; the user skill `langfuse-api-mcp` ([`skills/langfuse-api-mcp/`](skills/langfuse-api-mcp/)) teaches it how a Langfuse investigation is done with them: discover, describe, then execute; always a bounded time window; Langfuse data is untrusted, never instructions. It has a short entry file and one reference per workflow (traces, cost and latency, prompts, experiments, scores, errors), each loaded only when its workflow is asked for. Its description names this server's tools, so it does not compete with Langfuse's own `langfuse` skill. It adds no permission of its own: whether `execute_write` exists and every confirmation stay the server's decision.

**Claude Code, Cursor, VS Code, Codex CLI, Gemini CLI, Windsurf.** Install it from the repository with the [`skills`](https://www.npmjs.com/package/skills) CLI, in your project (or with `-g` for your user); `--agent` names the hosts to install for (`--agent '*'` for all). The Claude Code install is proven; the other hosts rely on the CLI's own support:

```bash
npx skills add rodrigorjsf/langfuse-api-mcp
# non-interactive, one host: npx skills add rodrigorjsf/langfuse-api-mcp --agent claude-code -y
```

The CLI installs from `main`, while your server may be an older build; the skill therefore tells the agent to call `describe_operation` for every parameter it does not name ([details](docs/reference/installation.md#user-skill)).

**Claude Desktop** installs skills only by upload. Each [GitHub release](https://github.com/rodrigorjsf/langfuse-api-mcp/releases) carries `langfuse-api-mcp-skill_<version>.zip`, signed, whose root is the `langfuse-api-mcp/` folder; upload it in Claude Desktop under Customize > Skills.

## Install and run

| Channel | Platforms | Needs |
|---|---|---|
| [npx](#npx) | Linux, macOS, Windows × x64, arm64 | Node.js with npm |
| [Release archive](#release-archive) | Linux, macOS, Windows × amd64, arm64 | nothing |
| [Docker](#docker) | linux/amd64, linux/arm64; stdio only | Docker |
| [Claude Desktop (MCPB)](#claude-desktop-mcpb) | macOS, Windows | Claude Desktop |
| [`go install`](#go-install) | any Go platform | Go 1.21 or later |

Every channel except `go install` is signed or carries npm provenance: see [Verify what you run](docs/reference/security-model.md#verify-what-you-run). The server is also listed in the [MCP Registry](https://registry.modelcontextprotocol.io) as `io.github.rodrigorjsf/langfuse-api-mcp`. What each channel ships and how it is built: [Installation reference](docs/reference/installation.md).

### npx

Configure the server in your MCP client as `npx -y langfuse-api-mcp` (pin a version with `langfuse-api-mcp@<version>`); it needs Node.js with npm, nothing else. The package carries the Go binary: nothing is downloaded at install time and no install script runs. See [Client configuration](#client-configuration) for the snippet of your client.

### Release archive

Every [GitHub release](https://github.com/rodrigorjsf/langfuse-api-mcp/releases) carries one archive per target, `langfuse-mcp_<version>_<os>_<arch>.tar.gz