René's URL Explorer Experiment

{"@context":"https://schema.org","@type":"DiscussionForumPosting","headline":"API Defined and/or Client-Defined Session IDs","articleBody":"**Is your feature request related to a problem? Please describe.**\nThe latest specification for **stateful** HTTP connections mandates that the server issue a Session ID in the InitializeResponse. The implication of this is: \n1. In the event that the MCP server fronts a service which already has a notion of sessions, the client will need to keep track of two different session IDs (one provided by MCP server and the other provided in a subsequent response payload from the service itself) which effectively represent the same session. \n2. The session ID can never be customized by the client, meaning client may need to maintain a mapping between its session identifier (e.g. user-xyz-chat-abcd) and the MCP server session identifier(s) (note the two sessions may not even be 1-1 depending on the application definition of sessions) \n\nSecondly, clients don't have a good way to know whether a tool uses SSE / statefulness. This means that clients can't know ahead of time whether a tool will\n1. require them to keep track of a session ID\n2. potentially upgrade the connection to SSE and stream back a bunch of data\n\n**Describe the solution you'd like**\nTo be honest, I'm not yet sure the best way to deal with this. \n\nOption 1: Maybe there is some good reason for this rigidity. In which case, probably folks can implement nice client-side abstractions backed by cloud dbs or caches to deal with this tracking.\n\nOption 2: TBH this is more to get ideas flowing -- not yet convinced this is the right approach. \n1. If MCP Server could issue a session ID post-initialization it would enable it to issue the service session ID as its session ID, resolving the duplication. \n2. Introduce a capabilities key within tool specification. Example:\n```\n{\n  \"jsonrpc\": \"2.0\",\n  \"id\": 1,\n  \"result\": {\n    \"tools\": [\n      {\n        \"name\": \"get_weather\",\n        \"description\": \"Get current weather information for a location\",\n        \"inputSchema\": {\n          \"type\": \"object\",\n          \"properties\": {\n            \"location\": {\n              \"type\": \"string\",\n              \"description\": \"City name or zip code\"\n            }\n          },\n          \"required\": [\"location\"],\n// [New] Note I thought this makes more sense here than capability negotiation because it seems tool-specific\n          \"capabilities\": {\n              \"transport\": {\n                  \"sse\": true/false,\n                  \"stateful\": true/false,\n                  \"customizableSessionIds\": true/false\n               }   \n          }\n        }\n      }\n    ],\n    \"nextCursor\": \"next-page-cursor\"\n  }\n}\n```\n3. Enable clients to set session ID IFF customizableSessionIds == true\n\nOne thing I see as an issue in long run is: Clients + Servers can make more informed decisions if metadata given during capability negotiation and (potentially) tool discovery is thorough. On the other hand, to avoid breaking consumers, new keys we introduce in these metadata documents must be optional. This means that it will be a best effort thing for servers to implement these fields and likely many servers will not. This makes these metadata less valuable to consumers. \n\n","author":{"url":"https://github.com/000-000-000-000-000","@type":"Person","name":"000-000-000-000-000"},"datePublished":"2025-03-26T12:54:32.000Z","interactionStatistic":{"@type":"InteractionCounter","interactionType":"https://schema.org/CommentAction","userInteractionCount":2},"url":"https://github.com/231/modelcontextprotocol/issues/231"}