Repository navigation
Conversation
| **TL;DR:** There is no standard field to correlate the requests of one logical | ||
| unit of work in logs and audit trails; every deployment invents its own. | ||
|
|
||
| _Mentioned by @javapro108 ([comment][javapro108-observability])._ |
| The server exposes a tool the client must call first (`init_conversation() -> | ||
| handle`); the handle is passed on every subsequent call and, via | ||
| [SEP-2243][sep-2243]'s `x-mcp-header` annotation, mirrored into an | ||
| `Mcp-Param-{name}` header a gateway can route on without parsing bodies: |
There was a problem hiding this comment.
FWIW this means gateways need to reshape the tools behind them to add a handle field that the upstream server doesn't declare (the upstream server isn't aware of the gateway). That's likely to conflict with servers that actually already use a handle for their own state independently of the gateway itself. In the general case, this seems difficult to get right.
| in `_meta`, on every transport including stdio. Assembled, a host could carry a | ||
| conversation ID in W3C Baggage via `_meta`, and servers could record it as | ||
| `gen_ai.conversation.id`: |
There was a problem hiding this comment.
Feels like this runs into all the host divergence questions of sessions (e.g. what is a conversation ID in Anthropic's remote MCP API?)
| The limits: nothing standardizes the header name, so every host/gateway pair | ||
| needs bespoke configuration; off-the-shelf host applications won't set or | ||
| forward nonstandard headers; and it only works when one party owns both ends of | ||
| the wire, which MCP customers generally don't. |
There was a problem hiding this comment.
This is itself a nonstarter - any sort of association ID can't be a bespoke negotiation, or it only works if you explicitly build a host application to support a specific gateway.
|
There is possibly an additional category here for identifier misattribution and loss. The existing categories address what the identifier is for, but don't address what happens if it's wrong. A relayed identifier that is absent, stale, or belonging to a peer conversation produces no error and no server-side signal, and (handle, auth_context) cannot detect it when both conversations belong to the same principal. Does the WG consider this a use case, or an implementation concern? |
1c5a232 to
e4f9adb
Compare
Summarizes the discussion from #36 into some clear questions and use cases.