Tempo MCP Server 🤖 - #5212
Conversation
123a5d7 to
9fe9f78
Compare
Signed-off-by: Joe Elliott <number101010@gmail.com>
Signed-off-by: Joe Elliott <number101010@gmail.com>
Signed-off-by: Joe Elliott <number101010@gmail.com>
Signed-off-by: Joe Elliott <number101010@gmail.com>
|
@joe-elliott In a few days I will be having a Hackathon where I will be exploring the Grafana MCP to see how it can help to do analysis on problems in a software stack. |
|
For databases willing to support their own MCP server mcp-grafana should simply read tools, append them to its internal list and proxy them back to the caller. By supporting this protocol directly Tempo can more easily update and test new tools as we add new endpoints and capabilities. |
Signed-off-by: Joe Elliott <number101010@gmail.com>
Signed-off-by: Joe Elliott <number101010@gmail.com>
| | [Compactor ring status](#compactor-ring-status) | Compactor | HTTP | `GET /compactor/ring` | | ||
| | [Status](#status) | Status | HTTP | `GET /status` | | ||
| | [List build information](#list-build-information) | Status | HTTP | `GET /api/status/buildinfo` | | ||
| | [MCP Server](https://grafana.com/docs/tempo/<TEMPO_VERSION>/api_docs/mcp-server) (*) | MCP | | `/api/mcp` | |
There was a problem hiding this comment.
Question/nit: should we have a section in docs page for MCP endpoint like we do for others? or it doesn't make sense?
There was a problem hiding this comment.
I don't know. I wasn't sure what to say about it b/c I didn't intend to document parameters or request/response bodies and I thought it needed more space than just a simple section like the rest of our endpoints.
Signed-off-by: Joe Elliott <number101010@gmail.com>
* MCP Server Signed-off-by: Joe Elliott <number101010@gmail.com> * docs Signed-off-by: Joe Elliott <number101010@gmail.com> * tests Signed-off-by: Joe Elliott <number101010@gmail.com> * logs Signed-off-by: Joe Elliott <number101010@gmail.com> * changelog Signed-off-by: Joe Elliott <number101010@gmail.com> * manifest Signed-off-by: Joe Elliott <number101010@gmail.com> * lint Signed-off-by: Joe Elliott <number101010@gmail.com> * lint Signed-off-by: Joe Elliott <number101010@gmail.com> * use tools error return Signed-off-by: Joe Elliott <number101010@gmail.com> * add meta info about response types Signed-off-by: Joe Elliott <number101010@gmail.com> * made constants and split the metrics meta types Signed-off-by: Joe Elliott <number101010@gmail.com> * update path from /mcp to /api/mcp Signed-off-by: Joe Elliott <number101010@gmail.com> * mcp integration tset Signed-off-by: Joe Elliott <number101010@gmail.com> * review Signed-off-by: Joe Elliott <number101010@gmail.com> * Removed httptest.Recorder Signed-off-by: Joe Elliott <number101010@gmail.com> * Use new jaeger client Signed-off-by: Joe Elliott <number101010@gmail.com> --------- Signed-off-by: Joe Elliott <number101010@gmail.com>
6 participants
What this PR does:
Adds an MCP server shim in the query frontend using mcp-go. This API layer allows LLMs and other agents access to tracing data. Due to privacy/security concerns it is disabled by default and warns the user if enabled.
Also, I reorganized the TraceQL docs to serve them directly from MCP. As seen in the screenshot it can give up to date information to an LLM to correct syntax errors in its queries. Unsure if what I did is brittle and awful or dynamic and powerful. You decide!
Allows for fun interactions like:
To test locally:
This can be tested with local test data using Claude code and our docker examples. Refer to the documentation in PR
Checklist
CHANGELOG.mdupdated - the order of entries should be[CHANGE],[FEATURE],[ENHANCEMENT],[BUGFIX]