Instrument Toolhive with Observability Backends

[mauriciocoder]

Feature Description
We’d like to request the addition of observability support to Toolhive. While MCP clients currently do not support integration with observability backends, we believe that MCP proxies created with the toolhive run commands can share some events for analytics.

We observed that pkg/transport/stdio.go already brings some context on the requests being sent to containers and the responses received. This could be a good place to add hooks for observability.

---

Reasons
Observability would help us better understand:

• Which MCP servers and tools are most used by each user;
• Why certain MCP servers may not be used as much;
• Patterns of usage across different teams or developers;

This data will help us identify adoption challenges, gather insights, and improve the MCP ecosystem.

---

Solution Proposal
Specifically, our company supports two distinct observability backends:

1. HTTP POST endpoint: Events could be sent to a backend using HTTP POST.
2. Datadog integration: Collect events and send them to Datadog by leveraging a Go client.

---

Proposed Next Steps
Which proposal are you most willing to discuss? We’re happy to collaborate on designing and/or implementing this feature if it aligns with the product's roadmap.

Thanks!

[mauriciocoder]

Datadog isn’t a viable option for us right now. We have security concerns regarding local key installations, and our team hasn't discovered a way to generate specific keys for particular event types. Currently, we're exploring a generic hook that can be integrated into an existing backend. This would need to be designed generically so that it can accurately map each request and context field into an HTTP Post.

[JAORMX]

@mauriciocoder we're thinking about enabling OTel for this. Would prometheus be useful for metrics for you?

[mauriciocoder]

@JAORMX Thanks for initiating this dialogue. We do not run Prometheus servers, and our backend service isn’t currently set up to support OTel. However, we do have a backend that accepts POST requests. Here’s an example:

curl -X POST "https://xyz.net" \ -d "type=your_log_type&param1=value1&param2=value2...&&"

This becomes available for a query after some minutes.

I believe that a custom exporter (which implements the LogExporter interface), converting OTel data to this custom format, may accomplish the goal.

[mauriciocoder]

@JAORMX I see you're considering enabling OTel for observability, and @lujunsan has been assigned this task. Do you have a design for this solution, and has it been included in the product roadmap already?

On our end, the instrumentation level involves exporting spans for both request and response at the stdio layer. As noted, our backend accommodates requests in application/x-www-form-urlencoded format with a few specific details:

• Endpoint URL should be configurable;
• There should be a "type" key in the request with a certain log type that we register internally;
• The request parameters should end in "&&";

If you happen to have any insights on the release schedule for this enhancement, I would love to hear from you!

[JAORMX]

@mauriciocoder we're starting to pick that work up just now. Here's the proposal #597 . Your input/feedback is more than welcome and will definitely influence the implementation.