Goose 1.55 Threads One Trace Across ACP and MCP

Goose 1.55 adds a missing join in agent observability: a trace arriving with an Agent Client Protocol prompt can now continue through Goose and into the Model Context Protocol tool call it triggers. The same release also preserves model-provider request IDs on responses and errors. Together, those changes make a composed run easier to reconstruct without pretending that correlation metadata is authorization.

The protocol handoff

ACP, the agent-facing side, and MCP, the tool-facing side, are separate protocol boundaries. Before this change, each layer could emit telemetry while still leaving operators with disconnected traces. In 1.55, Goose reads lowercase traceparent and tracestate values from an ACP session/prompt _meta object, attaches a valid remote context to the agent turn, and injects the current context into an MCP tools/call request.

This follows MCP SEP-414's convention for carrying W3C trace context in _meta. It is deliberately narrow: source inspection at the v1.55.0 tag shows that Goose reads only traceparent and tracestate, rejects absent or invalid contexts, and injects trace metadata only for tool calls rather than every MCP request. The pull request says the path works without an OTLP exporter, but the implementation remains behind Goose's existing otel feature.

The repository's integration test describes the intended end-to-end invariant precisely: the invoke_agent span adopts the incoming remote span as its parent, while the outgoing MCP call carries the execute_tool span as its parent. That is a useful design target because it preserves causality rather than merely copying one static identifier through every layer.

A second handle for provider failures

Distributed traces do not replace the identifier a model provider needs when investigating a failed request. Goose 1.55 also surfaces provider request IDs in successful response metadata and error text. In the tagged source, extraction accepts Anthropic-style request-id first and falls back to x-request-id; blank values are ignored and retained values are capped at 128 characters. The included tests cover ordinary errors, rate-limit errors, header precedence, blank values, and oversized values.

The distinction matters operationally:

• the W3C trace context connects the client, agent runtime, and MCP tool execution;
• the provider request ID identifies the separate upstream model call;
• a session ID identifies longer-lived agent state.

Treating those as different identifiers avoids an increasingly common failure mode in agent systems: logs contain plenty of IDs, but none expresses what relationship each ID proves.

What I verified

I cloned the v1.55.0 tag, which resolved locally to commit 2bcb8583a18a0623eb78c9ed845d597ed99fae48, and inspected the trace extraction/injection code, the ACP-to-MCP integration test, and provider request-ID handling. I also downloaded the official Windows CLI asset and executed it: goose.exe --version reported 1.55.0, and goose.exe info completed against an unconfigured local profile.

I did not run the Rust test suite because this host had no Cargo toolchain, and I did not configure a live ACP client, MCP server, OTLP exporter, or model provider. The test behavior above is therefore repository evidence, not a locally reproduced result. I also did not verify a signed tag.

Field note

This is an observability improvement, not a trust boundary. Incoming trace metadata is supplied by a caller; it can help correlate work but does not authenticate that caller, attest to tool output, or establish provenance by itself. Deployments should still constrain who can send ACP prompts and invoke MCP tools, and should avoid treating trace IDs as secrets.

The practical gain is narrower and valuable: when an agent turn crosses protocol and provider boundaries, operators now have a standards-aligned route for following the work and a provider-native handle for escalating the failures.