docs(SEP-2575): clarify stdio process lifetime in lifecycle spec#2770
Conversation
| - The stdio process **SHOULD** have approximately the same lifetime as the host | ||
| application instance that launched it. Clients **SHOULD** attempt to restart | ||
| the stdio process if the server terminates unexpectedly. |
There was a problem hiding this comment.
I'm not sure I agree with this. Responded similarly to NickC's proposal: https://github.com/modelcontextprotocol/modelcontextprotocol/pull/2692/changes#r3276075388
tl;dr: I agree with not spawning it per conversation, but I'd like to potentially go further in future and avoiding spawning it at all if possible, and tear it down early if not needed.
There was a problem hiding this comment.
I think spinning up and down more frequently than needed would be more helpful than hurtful -- there are many optimizations like connection pooling or caching that would be lost.
There was a problem hiding this comment.
I assume you mean internal connection pooling and caching right? Not MCP stuff?
I'm not arguing that we should start-up and tear-down a server per tool call or anything like that, but it does seem reasonable to me to do something like (a) by default, defer an stdio server spin up until needed, relying on cached server/discover and tools/list where possible, and (b) once the server is started, keep it around with a keepalive for perhaps 30 minutes, and then shut it down.
Connection pools typically don't live inactive forever anyway, so should not impact them if the server is inactive. You could wipe in memory caches, but those should be out-of-process anyway (otherwise every LLM process has to cache separately).
Setting aside the specifics of what an optimal setup may or may not look like, my main objection here is that we are being overly prescriptive. It's not obvious to me that tying all stdio server lifecycles to the host lifecycle is the optimal approach, so I don't see why we should be prescriptive here? What is wrong with just leaving this as a host choice?
Add prescriptive guidance that the stdio process should track the host application lifetime and serve multiple tasks, threads, or conversations, rather than being scoped to any single one.
9eaf3d2 to
442d803
Compare
3 participants
Add prescriptive guidance that the stdio process should track the host application lifetime and serve multiple tasks, threads, or conversations, rather than being scoped to any single one.