Call for Feedback: Langfuse MCP Server

[FroeMic]

Describe the feature or potential improvement

Help us improve the Langfuse MCP server

We recently launched a MCP Server built directly into Langfuse. It works with Claude Code, Cursor, and other MCP clients and currently provides tools for prompt management. We plan to add additional tools to cover our public api soon.

We want to take it further, and we'd love your input.

What we'd love to learn from you

• Missing pieces: What MCP tools or capabilities do you wish existed? Additional resources beyond prompts? Other Langfuse features you'd like to access via MCP?
• Double-downs: What already works great that we should invest in more? Which tools are most valuable to your workflow?
• Fix-me's: What's clunky, confusing, or getting in your way? Authentication issues, tool behavior, error messages, or documentation gaps?
• Nitpicks: Small workflow hurdles, unclear responses, or missing details that slow you down.

Thanks for helping shape the future of AI-assisted workflows in Langfuse! 🙌

Additional information

If helpful, please include:

• Your MCP client (Claude Code, Cursor, etc.)
• Your workflow or use case
• Quick examples or screenshots where things work well or break down

[gamojica]

Hi team,

Thanks for asking for feedback! We've been using the new MCP tools with Cursor and really liking them so far.

One workflow we use heavily is prompt stacking/dependencies for creating shared components (like system instructions or formatting templates) and referencing them in other prompts. The MCP integration handles creating these dependencies perfectly, which is great.

The main thing missing for us right now:

When we pull a prompt using getPrompt, it always returns the fully resolved version (with all dependencies expanded). This makes it tricky when we want to update just one part of a stacked prompt, because we can't easily see which text belongs to which dependency.

It would be super helpful if getPrompt had an optional flag (like the toggle in the UI) to return the "tagged" version instead. seeing the original @@@langfusePrompt... tags would make it much easier to understand the prompt's structure and know exactly what to edit.

Other than that, the validation and overall flow have been working really smoothly for us. Thanks for building this!

[FroeMic]

@gamojica Thanks for the initiative!

Let's me make sure to understand your use case correctly. Could you elaborated, maybe with and example, what you mean by "resolved" and "expanded"?

What would be the minimal change we'd need to ship to enable this?

Best
Michael

[gamojica]

Sure, happy to clarify.

When I call the getPrompt() MCP tool right now, it always returns the fully expanded version of the prompt. For example, if the prompt in Langfuse looks like:

@@@langfusePrompt(system_instructions)
@@@langfusePrompt(shared_formatting)
Write a response to the user…

the getPrompt() tool returns something like this (simplified example):

Current output (fully resolved):

You are an AI assistant. Follow these system rules...
---
All responses must follow this formatting template:
- Bullet 1
- Bullet 2
---
Write a response to the user…

Everything is merged into one block of text, which works for execution but makes it harder to edit because it is not obvious which part came from which dependency.

What we would like is the option to retrieve the unresolved version, basically the version that still contains the @@@langfusePrompt(...) tags, similar to what the UI toggle shows.

Expected output with resolveDependencies: false:

@@@langfusePrompt(system_instructions)
@@@langfusePrompt(shared_formatting)
Write a response to the user…

Having the tags preserved would make it easier to update only the pieces we need without guessing which text came from where.

From an API standpoint, adding an optional parameter to the getPrompt() MCP tool, such as resolveDependencies: false, would fully support this workflow.

[gamojica]

One more note related to my previous message about needing the tagged/unresolved version from getPrompt().

There is also a bug that comes from the same issue. When I update a prompt through the MCP tool, and that prompt includes dependencies, the update replaces those dependencies with raw text in the new version. This happens because the LLM only sees the fully resolved text that getPrompt() returns, so it has no way to know which parts were originally @@@langfusePrompt(...) references. Once the updated version is saved, those tags are gone and the dependency links are lost.

Having access to the tagged or unresolved version in the MCP response would prevent this, because the LLM would be able to see which parts of the prompt are actual text and which parts are dependency references.

[FroeMic]

@gamojica I have shipped an update yesterday that adds the functionality to both our public API and the MCP (I wanted to keep them in sync, so it took a day longer). See #10951

Let me know whether this solves your use case :)

[gamojica]

I've already been using it to update some our nested/stacked prompts & migrate others that we didn't have in Langfuse yet. It's been super helpful! Thanks @FroeMic for the quick turnaround

[DevLuuk]

Hi guys,

We're building an LLM-powered item prediction system and push failed predictions (no_match, validation failures, category mismatches) to Langfuse datasets for prompt improvement analysis. Being able to access and analyze this data through the MCP server would significantly improve our iteration workflow.

Requested Tools

Tool	Description
listDatasets	List available datasets with metadata (item count, last updated)
getDatasetItems	Retrieve items from a dataset with filtering options (by status, date range, metadata)
getDatasetItem	Get a single dataset item with full details (input, expected output, metadata)
getDatasetRuns	List experiment runs for a dataset to compare prompt versions

Why This Matters

Currently, analyzing failure patterns requires switching to the Langfuse web UI. Having MCP access would let us:

• Query failure patterns directly while iterating on prompts in Claude Code/Codex CLI
• Cross-reference dataset items with prompt versions without context switching
• Build a tighter feedback loop between failed predictions and prompt improvements

This would complement the existing prompt management tools nicely. We could analyze what's failing in datasets and immediately update prompts in the same workflow.

[FroeMic]

@DevLuuk I am having a look – need to check a few downstream implications of shipping this and will let you know.

[laziest-coder]

@FroeMic having these tools indeed would be helpful!

[marcusze]

Agreed - valuable also for the @predlico team

[jchauncey]

Im having issues getting claude code to work with the MCP server. I tried following these docs - https://langfuse.com/docs/api-and-data-platform/features/mcp-server but I'm consistently getting a 404 with the url - https://us.cloud.langfuse.com/api/public/mcp

Connection failed: HTTP 404: Invalid OAuth error response: SyntaxError: JSON Parse error:
Unrecognized token

The docs mention using

claude mcp add --transport http langfuse https://us.langfuse.com/api/public/mcp --header "Authorization: Basic {your-base64-token}"

But that domain doesnt seem to resolve at all?

[FroeMic]

@jchauncey thanks for flagging this – the correct host is us.cloud.langfuse.com . Our copy-and-paste code in the docs had us.langfuse.com (without the cloud). Fixing the docs now.

Could you try again with

claude mcp add --transport http langfuse https://us.cloud.langfuse.com/api/public/mcp --header "Authorization: Basic {your-base64-token}"

and let me know whether it worked?

[jchauncey]

@FroeMic that still isnt working. Here is what I see the the Claude mcp logs - https://gist.github.com/jchauncey/7c3c26e468c9a6f6e4547b9101f0b037

For the base64 token I'm following the instructions of -

echo -n "pk-lf-your-public-key:sk-lf-your-secret-key" | base64

[changye-chen]

if I have two projetcts called A and B, the mcp servers for A and B can't tell any meaningful difference

[FroeMic]

Yes, this is a current limitation. The authentication is scoped to one specific projects. Could you help us understand why your agent needs access across multiple projects?

[changye-chen]

@FroeMic
@FroeMic Thank you for your reply!

Here's my workflow:

1. In Project A, I have three meta prompts that generate development prompts in Project B
2. I have a Langflow pipeline to actually use these meta prompts
3. I need to check the generated prompts to determine whether I should:
   • Optimize my meta prompts (in Project A)
   • Or just modify the generated prompts slightly (in Project B)
4. Most importantly, I need to show my AI agent what the meta prompts really are, so it can understand conceptually and produce good requirements

Therefore, I need to be able to access both Project A (to view meta prompts) and Project B (to view generated prompts) for this cross-project analysis and optimization.
(sorry for edit this several times)

[nimarb]

hi @changye-chen , thank you for the workflow explanation ! makes sense here, but unfortunately it's currently not supported. it could work if you create prompts in different environments instead of projects, but it kind of would require you to restructure your workflow. We will keep multi project support in mind going forward.

[changye-chen]

@nimarb I understand now, thank you for your explaination and suggestion

[AkshatSoni26]

any plan to also add traces/ sessions in mcp ?
this also very helpful.

[RichardKruemmel]

I would also love to see this feature in the langfuse mcp. The main goal would be to speed up debugging processes. Currently have a user reporting issues with prompt adherence. I would like to provide the user id and some context to the Agent and ask Claude to find the relevant trace and the context loaded into the Input, so that I can debug the support ticket even faster.
Currently working around it by calling the API, but having it supported in the mcp would be even better.

While looking for this feature I found https://github.com/avivsinai/langfuse-mcp. Is this mcp recommended by langfuse?

[AkshatSoni26]

Hi @nimarb , it needed for faster debugging as @RichardKruemmel said,

[alexey-neyman-lmnd]

I found it very useful when working on some LLM-powered agentic system, so the coding agent (Claude Code in my case) can have access to its traces, so it can do the whole loop:

1. Run the system.
2. See how it worked: the results, app logs, LLM traces.
3. Improve the code/prompt.
4. Goto 1.

Currently, I just wrapped the TS Langfuse client into a script, that CC knows how to deal with. Would be truly great if trace access was part of the MCP!

[RittikaJ]

Yes we need it too!
We run tracing of our agentic workflows on Langfuse, at present we download the traces manually and pass it to claude code to help in debugging.
@FroeMic there is this community MCP we tried, not sure if you have seen this but it does the job - https://github.com/avivsinai/langfuse-mcp

[nimarb]

Hi @AkshatSoni26 , @RichardKruemmel , @alexey-neyman-lmnd , @RittikaJ thank you for the feedback and the suggestion of the alternative MCP server - looks good to be honest!
we just released the langfuse-cli : https://github.com/langfuse/langfuse-cli
It's a wrapper around our API and thus allows getting traces and can easily be used by agents.

Would really hope to get further feedback on this!

[samvass]

It would be useful to have a way to track prompt usage via the MCP server (e.g., seeing that prompt X was invoked 20 times) to help monitor usage.

[ZenWayne]

Is self-hosted server support this feature? i access the url and it says 404

[nimarb]

hi @ZenWayne , it can be run self hosted, did you follow the docs here for the self-hosted setup? https://langfuse.com/docs/api-and-data-platform/features/mcp-server
thanks !

[ZenWayne]

Yes, i follow the docs, i am using docker image with localhost, i cannot access it even with a clean image, the following is the command i test for mcp server, it returned 404

curl -vv -u pk-lf-...:sk-lf-...-H "Content-Type: application/json" http://localhost:3000/api/public/mcp

[mrtil35]

Two feature requests:

Tracing MCP (High priority): It seems like every other company is releasing an MCP to let Claude/Cursor agentically look at logs to understand what's happening and why. For example, Chrome's DevTools MCP is unbelievable for this–it can look at network logs, console, and navigate the screen to test full flows. Right now, there's no easy way for the Claude Code / Cursor to get Langfuse traces though. It'd be game changing if it can read through traces, understand where repeated errors happen, and then push prompt changes using the prompt MCP. You can hack pieces of this together, but it's quite inefficient today. This would get us to move all prompts to Langfuse vs other tools we're testing out.

Return tagged prompt by default (Medium priority): In the Prompt Management MCP, there's a way to tell the AI to pull the unresolved "@@@langfusePrompt..." version, but in my testing even with custom instructions the AI (Opus 4.5 and 5.2 High) repeatedly struggle with this. So any plan review / feedback AI will call out a bug or DRY violation with prompts containing repeated information and not using the shared prompts we have. I think better MCP design would be to return what the user sees on default in Langfuse UI–the unresolved prompt. The AI is very good at understanding this and looking up its content, but when you start resolved by default it creates many more issues.

[marcusze]

I think it would be great to have a response object gets the metadata contents of traceTab=log and the observations
https://cloud.langfuse.com/project/{project_id}/traces?peek={trace_id}&timestamp={timestamp}&observation=trace-{trace_id}&traceTab=log

[DevLuuk]

Does the current Langfuse prompt-management MCP support fetching prompts on a per-project basis?
As I need to switch between multiple Langfuse projects within a single Claude Code session.

[nimarb]

hi @DevLuuk , currently, the MCP server only works with one project as the authentication is project based. perhaps you can ask claude to modify it's config with different auth vars, not sure if that works.