langfuse-mcp

Overview Schema Source Related Servers Discussions Admin

fetch_traces

Search Langfuse traces using optional filters like age, name, tags, user ID, session, and metadata. Retrieve paginated results to debug LLM applications or analyze trace history.

Instructions

Find traces based on filters. All filter parameters are optional.

On Observations API v2, each trace is built from its root observation; traces without a root observation do not appear.

Input Schema

TableJSON Schema

Name	Required	Description	Default
`age`	Yes	Minutes ago to start looking (e.g., 1440 for 24 hours)
`name`	No	Name of the trace to filter by
`page`	No	Page number for pagination (starts at 1)
`tags`	No	Tag or comma-separated list of tags to filter traces by
`limit`	No	Maximum number of traces to return per page
`user_id`	No	User ID to filter traces by
`metadata`	No	Metadata fields to filter by
`session_id`	No	Session ID to filter traces by
`output_mode`	No	Controls the output format: 'compact' (default) returns summarized JSON, 'full_json_string' returns complete raw JSON as string, 'full_json_file' saves complete data to file and returns summary with path.	compact
`include_observations`	No	If True, fetch and include the full observation objects instead of just IDs. Use this when you need access to system prompts, model parameters, or other details stored within observations. Significantly increases response time but provides complete data.

Output Schema

TableJSON Schema

Name	Required	Description	Default
`result`	Yes

Schema Changelog

Changes observed during successful MCP inspections.

Changed2 schema fields changedv0.9.0May 5, 2026
- addedInput schema / properties / age / exclusiveMinimum
```
Added value: +0
```
- addedInput schema / properties / age / maximum
```
Added value: +10080
```
First observedJan 24, 2026

TDQS

B3.2/5.0

Behavior4/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations provided, the description carries the behavioral burden. It discloses a useful nuance: traces without a root observation do not appear on API v2, which is critical for interpreting missing data. Without annotations, this is a meaningful addition, though it doesn't cover pagination, rate limits, or authentication.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Two concise sentences with zero filler. The first states the action, the second adds a critical behavioral caveat. Information is front-loaded and every word earns its place.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness3/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given 10 parameters and an output schema, the description doesn't need to repeat parameter details, but it fails to compensate for the required-parameter contradiction. The note about root observations is useful, but overall the description is not complete enough because the agent cannot trust the 'all optional' claim, and there is no guidance on pagination or ordering.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters1/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The description claims 'All filter parameters are optional,' but the schema lists 'age' as required. This directly contradicts the schema and misleads an agent about required inputs. Since schema coverage is 100%, the baseline is 3, but the contradiction and lack of added meaning reduce it to 1.

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?

The description states a clear verb ('Find') and resource ('traces') with a plural noun that implies a list operation, distinguishing it from the singular 'fetch_trace'. It doesn't explicitly name sibling alternatives, but the verb+resource is specific enough for an agent to infer the purpose.

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?

The description gives no guidance on when to use this tool versus its siblings like fetch_trace, fetch_sessions, or fetch_observations. It doesn't mention what makes this tool preferable, such as filtering capabilities or bulk retrieval. The only hint is 'based on filters,' but no exclusions or alternatives are stated.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Deploy Server