MCP traceparent in _meta: tracing a Sume tool call end to end

Sume's docs do not say whether a traceparent in MCP _meta is read or passed on, so do not rely on your trace id surviving the hop. What the docs do document is the Sume request id, sent as the x-sume-request-id header and as request_id in errors and receipts, plus the job id. Log those next to your own trace id.

The _meta convention is from the MCP 2026-07-28 changelog, read 2026-09-30. I searched the Sume docs content for traceparent and found no mention. Request-id behavior is from Sume's Errors and Errors and credits pages.

What did MCP add for trace context?

Minor change 2 in the spec changelog documents OpenTelemetry trace context propagation conventions for _meta keys: traceparent, tracestate and baggage (SEP-414). It is a convention for carrying context, so a server that does not read those keys simply never links its work to your trace.

What identifiers does Sume give me?

The Formats errors page says every response carries x-sume-request-id and every receipt carries request_id. Error bodies repeat it, with the note to quote it to support. The API exposes it in both body and headers. Separately, the job id from submit is the durable handle: store it so you can recover work after a restart.

What should I log to follow one call?

Per tool call, log your own trace id, the MCP request ID, the Sume job id and the x-sume-request-id when your client exposes response headers. A join on those lines gives you the path even though no shared trace id crosses the boundary. Do not log API keys, signed URLs or raw media URLs.

Can I get real trace propagation?

Not from what the docs promise. If you need it, put the trace id in your own log record next to the Sume ids, as above. For what else Sume records, see API audit log: what you can trace.