MCP server support

[tconley1428]

What was changed

Added two mechanisms for supporting MCPServer. One is a stateless model which has the best durability guarantees but is not able to maintain call state if required. The other is stateful, but requires the user to handle cases where it fails, since all the calls need to happen on the same worker, which could potentially fail.

Why?

Users would like to use MCP servers without hosting them accessible to openai's servers

Checklist

1. Closes

2. How was this tested:
   A whole set of new tests

3. Any docs updates needed?
   Yes, readme updates should be made once review has progressed.

[jssmith]

I commented on the need to register MCP servers with the plugin.

Is there a way for us to support the context manager pattern as in the samples?

[dandavison]

Regarding the implementation, it looks like one approach would be to do what the OpenAI Agents SDK does when defining servers, e.g.

class MCPServerStdio(_MCPServerWithClientSession)

https://github.com/openai/openai-agents-python/blob/f903ad0ac44e1c5c959301bd3c8721fbd4cd4e5b/src/agents/mcp/server.py#L354

and then supply an mcp.ClientSession connected to a custom transport that routes to the activity / nexus operation. That will allow code sharing with non-OpenAI in-workflow MCP initiatives. But if this is all non-user facing implementation detail then there's no hurry.

Would that also give you some nice things that _MCPServerWithClientSession has and that still make sense in your use case? (E.g. tool list caching)

[tconley1428]

Talked to Dan offline about the forked mcp client transport alternative. It's a good one, and something we should follow up on, but doesn't work for all mcp servers, which this PR is designed to support.

[cretz]

Nothing blocking

[dandavison]

The docstrings in this PR are placing too much emphasis on connection overhead, and not quite being clear enough about when one would/would not use stateful/stateless.

It's not clear how often connection overhead matters given the round-trips to activity workers.

On the other hand, suppose a user is using an MCP server that must be used statefully, such as https://github.com/modelcontextprotocol/servers/tree/main/src/sequentialthinking. For that user we would want our docstrings to communicate that
(a) they must use the stateful version for correctness reasons, regardless of performance
(b) Temporal simply cannot make it "durable" since the MCP server stores state in volatile memory in an OS process.

To list out the cases:

1. MCP server retains state between calls in the same session and this is required for the server's functionality. In this case, using StatelessTemporalServer would be incorrect.

2. MCP server retains state between calls, but this is not required for correct server functionality, and so user might choose not to make use of this and use StatelessTemporalServer. But how common is this -- do we have any examples where this makes sense?

3. MCP server does not retain any state between calls. In this case they could use either of our server wrapper classes, and we recommend that they use StatelessTemporalServer.

Maybe some of the above is helpful for docstring content.

[tconley1428]

I don't want to frame things in some of this way because some of it will only make sense with the current duality of server, but not necessarily be accurate in future. I'll go back over the docstrings, but I want the servers to state their limitations, not the scenarios in which they must be used.