Thanks for this update!

Would suggest one other clarification / exposition here: the situation where not all headers are in both but only some of them are, such as where traceparent is not in _meta but tracestate is in both headers and in _meta or where traceparent is in _meta but baggage is only in headers.

Recommended behavior:

• If traceparent is both present and valid in params._meta:
  • Discard traceparent, tracestate, baggage from headers
  • Use only the subset of valid values (traceparent, tracestate, baggage) from params._meta
• Otherwise:
  • Use traceparent, tracestate, baggage from headers

Agreed, generally, that _meta should override. But if there is a mix, there can be connections between them (e.g. tracestate may assume a particular trace ID implicitly from traceparent), and so I think it should be an all-or-nothing replacement.

Great refinement, @michaelsafyan! The "all-or-nothing" approach makes a lot of sense.

You're right that traceparent, tracestate, and baggage are semantically linked—mixing traceparent from _meta with tracestate from auto-instrumentation would create an inconsistent/invalid trace context.

I've updated Section 6 to adopt this approach:

### 6. Conflict Resolution

When `_meta` contains W3C Trace Context fields and the outbound HTTP request already has corresponding headers set (e.g., via auto-instrumentation):

1. If `traceparent` is present and valid in `_meta`, SDKs MUST use an **all-or-nothing** approach:
   - Discard ALL existing W3C Trace Context headers (`traceparent`, `tracestate`, `baggage`) from the outbound request
   - Forward ONLY the W3C fields present in `_meta`
2. SDKs SHOULD log a debug-level message when overriding existing headers
3. No error should be raised—this is expected behavior when integrating with existing observability infrastructure

**Rationale**: W3C Trace Context fields are semantically linked—`tracestate` contains vendor-specific data keyed to the `traceparent`, and `baggage` may contain context relevant to that specific trace. Mixing fields from different sources would create inconsistent trace context. The all-or-nothing approach ensures trace coherence across the MCP boundary.

This ensures that when _meta provides trace context, it's used as a complete, coherent unit rather than being merged with potentially incompatible auto-instrumented headers.

Pushing the update now.

"Overwrite that specific header" is a surprising behavior given the name "merge".

I would expect "key: value1" and "key: value2" to merge into "key: value1,value2" following standard HTTP behavior for repeating a header line with different values:

https://httpwg.org/http-core/draft-ietf-httpbis-semantics-latest.html#field.lines

Thanks for the thorough review @michaelsafyan! Addressing your points:

1. Validation Order

You're right that validation must precede conflict resolution. Section 3 states "SDKs MUST validate _meta fields before forwarding" — I'll make the ordering more explicit in the processing flow.

2. tracestate without traceparent

Great catch! The current wording has a gap. Rather than hardcoding this for trace-context only, I'll add a generic required attribute to header group configuration:

headerGroups: {
  // Predefined group - traceparent is required, tracestate is optional
  "trace-context": {
    headers: ["traceparent", "tracestate"],
    policy: "clear-and-use-meta",
    required: ["traceparent"]  // Group skipped if traceparent missing
  },

  // Custom group example - can specify their own required headers
  "datadog": {
    headers: ["x-datadog-trace-id", "x-datadog-parent-id", "x-datadog-sampling-priority"],
    policy: "clear-and-use-meta",
    required: ["x-datadog-trace-id"]
  }
}

Behavior with required: ["traceparent"]:

This correctly models W3C Trace Context semantics (tracestate is optional but requires traceparent) while allowing custom groups to define their own requirements.

3. "merge" Terminology

Agreed that "merge" is misleading given HTTP semantics. I'll rename to prefer-meta — clearer that _meta takes precedence when present, without implying value concatenation.

Updated policies:

• clear-and-use-meta — All-or-nothing replacement for coupled headers
• prefer-meta (née merge-with-meta) — Per-header: _meta wins if present, else keep existing
• ignore-meta — Always keep existing, never forward from _meta

4. Vendor Implementations

This is spec-first — no production implementations yet. The reference implementation will be in the TypeScript SDK after acceptance. However, the design aligns with:

• OpenTelemetry's MCP context propagation guidance
• Standard W3C Trace Context propagation patterns

Happy to coordinate with other SDK maintainers once the spec direction is agreed.

I'll update the SEP with these changes. Let me know if you have any concerns with the required array approach!

I guess I'm confused regarding "clear-and-use-meta" vs "prefer-meta" ... couldn't one be implemented in terms of the other based on listing a single header at a time (groups of 1 header) vs multiple headers?

The "required" policy makes sense. A "validator" option may also be necessary.

In terms of vendor implementations, that is assuming that all clients are open source. What I'm saying is that I know of at least one vendor implementation that does what was proposed in my earlier comment . In particular, an all-or-nothing keyed on traceparent for traceparent, tracestate, and baggage. (Yes, baggage is a separate spec and can be carried independent of W3C tracing context; however, this vendor solution considers baggage as logically similar to trace context propagation and often confused by users interchangeable with tracestate as a carrier of extra data piggybacking over tracing instrumentation). That doesn't mean that it has to land that way in OSS, but it may be worth some ground truth research to inform the spec (and to determine where divergences from private vendor solutions may hinder adoptability or create friction points).

Thanks so much for listening and for driving this work forward!

Good points @michaelsafyan!

On policy distinction: The difference is meaningful for multi-header groups:

• clear-and-use-meta: If _meta has traceparent but not tracestate, existing tracestate is cleared (prevents orphaned state)
• prefer-meta: Existing tracestate would be preserved (could cause trace coherence issues)

For single-header groups like baggage, they behave identically.

On validator: I like this idea. The required array handles presence checks, but a validator function could handle format validation:

"trace-context": {
  headers: ["traceparent", "tracestate"],
  policy: "clear-and-use-meta",
  required: ["traceparent"],
  validator: (headers) => isValidTraceparent(headers.traceparent)
}

Should I add this to the spec, or keep it as an SDK implementation detail?

On vendor research: This is a great point. You seem to have good visibility into existing implementations — would you be interested in contributing this research? Specifically:

1. Documenting how existing OSS propagators (OpenTelemetry, Jaeger, Zipkin) handle W3C Trace Context
2. Identifying any proprietary implementations that treat traceparent/tracestate/baggage as a coupled unit
3. Flagging potential friction points between this spec and existing approaches

If you'd like to contribute, I'd be happy to add you as a co-author on the SEP. Otherwise, I can do the research — just wanted to offer since you raised the concern and may already have context here.

+1 to making it default for tracing.

Suggestion: allow separate validators per header as in:

  validators: {
     # Will drop/scrub/ignore if invalid
     "traceparent": isValidTraceparent,
      # Will drop/scrub/ignore if invalid
     "tracestate": isValidTracestate,
   }
   # Presence evaluated after validation
   required: ["traceparent"],

Thanks for the review and the suggestion!

Both changes incorporated:

1. Per-header validators - replaced the group-level validator with validators (per-header), so individual headers can be validated/dropped independently:

"trace-context": {
  policy: "clear-and-use-meta",
  validators: {
    traceparent: isValidTraceparent,
    tracestate: isValidTracestate,
  },
  required: ["traceparent"],
},

2. Processing order updated - per-header validation now runs before required presence checks:

   1. Validation (field-level: string type, ASCII, size limits)
   2. Per-header validation (drop individual headers that fail)
   3. Required check (if a required header was dropped by validation, group is skipped)
   4. Policy application