OTEL - Add return value tracing to tool execution spans (ret attribute on #[tracing::instrument])

[vishnuasp]

Summary

The tool execution functions (introspect, execute, search, validate) capture input parameters in OpenTelemetry spans but not return values, making it difficult to observe tool outputs in tracing systems like Arize, Jaeger, or any OpenTelemetry-compatible backend.

Current Behavior

The tool functions use #[tracing::instrument(skip(self))] which captures the input parameter as a span attribute, but the CallToolResult return value is not captured:

// crates/apollo-mcp-server/src/introspection/tools/introspect.rs
#[tracing::instrument(skip(self))]
pub async fn execute(&self, input: Input) -> Result<CallToolResult, McpError> {

NOTE: Execute tool, doesn't have any sort of instrumentation at all

Result in traces:

• input span attribute visible
• output/result not visible as span attribute

Proposed Solution

Add ret to the #[tracing::instrument] macro to capture return values:

#[tracing::instrument(skip(self), ret)]
pub async fn execute(&self, input: Input) -> Result<CallToolResult, McpError> {

This should be applied to:

• introspect.rs - Introspect::execute()
• execute.rs - Execute::execute()
• search.rs - Search::execute()
• validate.rs - Validate::execute()

Benefit

This would make Apollo MCP Server telemetry compatible with OpenInference semantic conventions and observability platforms that expect both input and output on tool spans. Currently, users routing traces to platforms like Arize can see what was requested but not what was returned.

[vishnuasp]

Should be trivial change

[gocamille]

Thanks for the detailed issue report @vishnuasp -- this is a great suggestion to improve observability, and we appreciate you raising it!

Since tool outputs can contain sensitive data (such as PII or private schema details), we want to ensure we address this in a way that maintains a secure-by-default posture. We're exploring different approaches but don't have a concrete implementation or timeline to share yet.

We're going to keep this issue open to track progress. Feel free to subscribe if you'd like to stay updated — we'll post here as our plans take shape or when we're ready to move forward.

Thanks again for the thoughtful suggestion!

[vishnuasp]

Thanks for the update! This enhancement would really level up the observability for us. Enabling us to do RCA, issue tracking, evals