A
licenseNot graded
qualityD
maintenanceAn 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.
14
MIT
MCP Server for langfuse
by z9905080
Provides a package that can be installed from npm to set up the MCP server for Langfuse integration.
Displays npm version badge for the package using Shields.io.
Click on "Deploy Server".
Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state.
In the chat, type
@followed by the MCP server name and your instructions, e.g., "@MCP Server for langfuseshow me LLM metrics from last week"
That's it! The server will respond to your query, and you can continue using it as needed.
Here is a step-by-step guide with screenshots.
MCP Server for langfuse
A Model Context Protocol (MCP) server implementation for integrating AI assistants with Langfuse workspaces.
Overview
This package provides an MCP server that enables AI assistants to interact with Langfuse workspaces. It allows AI models to:
Query LLM Metrics by Time Range
Related MCP server: langfuse-mcp-extended
Installation
# Install from npm
npm install shouting-mcp-langfuse
# Or install globally
npm install -g shouting-mcp-langfuseYou can find the package on npm: shouting-mcp-langfuse
Prerequisites
Before using the server, you need to create a Langfuse project and obtain your project's public and private keys. You can find these keys in the Langfuse dashboard.
set up a Langfuse project
get the public and private keys
set the environment variables
Configuration
The server requires the following environment variables:
LANGFUSE_DOMAIN: The Langfuse domain (default:https://api.langfuse.com)LANGFUSE_PUBLIC_KEY: Your Langfuse Project Public KeyLANGFUSE_PRIVATE_KEY: Your Langfuse Project Private Key
Usage
Running as a CLI Tool
# 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-langfuseUsing in Your Code
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
// ...Available Tools
The server provides the following langfuse integration tools:
getLLMMetricsByTimeRange: Get LLM Metrics by Time Range
License
ISC
Author
Repository
Available Tools
1 toolquery_llm_metricsC
Query LLM metrics
ParametersJSON Schema
| 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
C2.7/5.0
Behavior2/5
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.
Conciseness2/5
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.
Completeness2/5
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.
Parameters3/5
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.
Purpose4/5
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.
Usage Guidelines2/5
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
C2.8/5.0
Scored across 1 tool
Disambiguation5/5
With only one tool, there is no possibility of confusion or overlap with other tools. The tool's purpose is clear and unambiguous.
Naming Consistency5/5
The single tool uses a clear snake_case naming convention. Although there are no other tools to compare, the naming is consistent within itself.
Tool Count1/5
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.
Completeness1/5
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
ActivityInactive
ResponsivenessNo issues
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
- AlicenseAqualityCmaintenanceComprehensive MCP server for Langfuse, enabling AI assistants to access and manage traces, observations, scores, datasets, and sessions for observability.248 npm1MIT
- AlicenseNot gradedqualityDmaintenanceA Model Context Protocol (MCP) server for comprehensive monitoring and observability of systems using Langfuse.1MIT
- AlicenseNot gradedqualityBmaintenanceMCP server for Langfuse providing 50 tools for prompt management, observability, instance/organization management, and metrics tracking via natural language.19 npmMIT