MCP Server for langfuse
Servidor MCP para langfuse
Una implementación de servidor de Protocolo de Contexto de Modelo (MCP) para integrar asistentes de IA con espacios de trabajo de Langfuse.
Descripción general
Este paquete proporciona un servidor MCP que permite a los asistentes de IA interactuar con los espacios de trabajo de Langfuse. Permite a los modelos de IA:
Consultar métricas LLM por rango de tiempo
Related MCP server: langfuse-mcp-extended
Instalación
# Install from npm
npm install shouting-mcp-langfuse
# Or install globally
npm install -g shouting-mcp-langfusePuedes encontrar el paquete en npm: shouting-mcp-langfuse
Prerrequisitos
Antes de usar el servidor, debe crear un proyecto de Langfuse y obtener las claves pública y privada. Puede encontrar estas claves en el panel de control de Langfuse.
configurar un proyecto Langfuse
obtener las claves públicas y privadas
establecer las variables de entorno
Configuración
El servidor requiere las siguientes variables de entorno:
LANGFUSE_DOMAIN: El dominio Langfuse (predeterminado:https://api.langfuse.com)LANGFUSE_PUBLIC_KEY: La clave pública de su proyecto LangfuseLANGFUSE_PRIVATE_KEY: Su clave privada del proyecto Langfuse
Uso
Ejecutarse como una herramienta CLI
# Set environment variables
export LANGFUSE_DOMAIN="https://api.langfuse.com"
export LANGFUSE_PUBLIC_KEY="your-public-key"
export LANGFUSE_PRIVATE_KEY="your-private
# Run the server
mcp-server-langfuseUsando en tu código
import { Server } from "@modelcontextprotocol/sdk/server/index.js";
import { langfuseClient } from "shouting-mcp-langfuse";
// Initialize the server and client
const server = new Server({...});
const langfuseClient = new LangfuseClient(process.env.LANGFUSE_DOMAIN, process.env.LANGFUSE_PUBLIC_KEY, process.env.LANGFUSE_PRIVATE_KEY);
// Register your custom handlers
// ...Herramientas disponibles
El servidor proporciona las siguientes herramientas de integración de langfuse:
getLLMMetricsByTimeRange: Obtener métricas LLM por rango de tiempo
Licencia
ISC
Autor
Repositorio
Available Tools
1 toolquery_llm_metricsC
Query LLM metrics
| Name | Required | Description | Default |
|---|---|---|---|
| fromTimestamp | No | Start timestamp in ISO 8601 format | |
| toTimestamp | No | End timestamp in ISO 8601 format | |
| page | No | Page number (default 1) | |
| limit | No | limit (default 100) | |
| traceName | No | Trace name | |
| userId | No | User ID, it's can filter by user | |
| tags | No | Tags | |
| environment | No | Environment |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations exist, and the description does not disclose any behavioral traits such as side effects, permissions, rate limits, or data scope. It merely describes a query, which implies a read-only operation but does not explicitly confirm safety or other constraints.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely short (3 words) but underspecified for a tool with 8 parameters. It lacks necessary detail and is not front-loaded with critical information. Conciseness should not sacrifice completeness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity of 8 parameters, no annotations, and no output schema, the description is insufficient. It does not explain what the metrics represent, how results are returned, or any context for interpreting the data. The agent is left without enough information to effectively use the tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the baseline is 3. The description adds no meaning beyond the schema's parameter descriptions. It does not explain how to use parameters together or provide context that helps the agent understand parameter relationships.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Description states 'Query LLM metrics' which clearly identifies the verb and resource. It is a simple, direct statement of the tool's purpose, though it lacks specificity about which metrics. It is not a tautology and distinguishes the tool as a query operation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance provided on when to use this tool, what scenarios it is suited for, or any alternatives. The description gives no context for appropriate usage, leaving the agent without decision-making information.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Tool Schema Changelog
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
1 tool update
- First observed
query_llm_metrics
TDQS
Scored across 1 tool
With only one tool, there is no possibility of confusion or overlap with other tools. The tool's purpose is clear and unambiguous.
The single tool uses a clear snake_case naming convention. Although there are no other tools to compare, the naming is consistent within itself.
A server named 'MCP Server for langfuse' with only one tool is severely undersized. Langfuse is a comprehensive LLM observability platform expecting tools for traces, scores, sessions, etc., not just metrics queries.
The server lacks any tools for creating, updating, or deleting resources, and does not cover common operations like managing traces or observations. It is severely incomplete for its stated domain.
Maintenance
Related MCP Connectors
MCP server for building and testing AI agents with multi-model experimentation and insights.
Query application logs, traces, and metrics from your AI coding assistant via Foam's MCP server.
MCP server for AI agents to plan, verify, and deploy Cloudflare-native apps.
MCP server that lets AI assistants use all OneSchema features exposed via the public API.
Related MCP Servers
- AlicenseNot gradedqualityDmaintenanceAn MCP server that enables AI assistants to interact with Signoz observability platform, providing tools to query dashboards, metrics, traces, logs, and APM data with time range support.14MIT
- AlicenseAqualityCmaintenanceComprehensive MCP server for Langfuse, enabling AI assistants to access and manage traces, observations, scores, datasets, and sessions for observability.2420 npm1MIT
- AlicenseNot gradedqualityDmaintenanceA Model Context Protocol (MCP) server for comprehensive monitoring and observability of systems using Langfuse.1MIT
- AlicenseNot gradedqualityCmaintenanceMCP server for Langfuse providing 50 tools for prompt management, observability, instance/organization management, and metrics tracking via natural language.9 npmMIT