[Feature] Allow MCP servers to opt in to caller session identity #4714

What feature would you like to see?

Problem

Multiple conversations in one Kimi Code workspace can share an MCP client connection. Each tools/call currently carries the tool name and arguments, but not the conversation that initiated it. A server that hosts tools for several conversations therefore cannot authorize an operation for the correct conversation.

For example, a local multi-conversation orchestrator may need to let one conversation read its own messages or post an update, without giving the same permission to every other conversation using that MCP server. Static headers, a shared token, or model-supplied arguments cannot establish this caller identity.

Proposed capability

Add an opt-in sendSessionId boolean to each MCP server entry. When it is true, the Kimi runtime writes the current conversation id to _meta["kimi/sessionId"] on every tool call. The value must come from the runtime's session context and must not be overridable by model-controlled arguments.

The default is false. Existing configurations and servers that do not need this information behave exactly as before. HTTP, SSE, and stdio servers should use the same contract.

Why opt in

A session id is a correlation identifier, not a credential, but third-party MCP servers should not receive it by default. Only a server whose operator explicitly enables the option receives it.

Acceptance criteria

• An existing server entry without sendSessionId sends no new metadata.
• Two conversations sharing a workspace server send their own ids, even when their tool names and arguments are identical.
• A model-controlled argument named sessionId does not replace the runtime value.
• Reconnects and retries keep the same caller id.
• HTTP, SSE, and stdio transports implement the same behavior.
• The option and its default are documented.

Open question

MCP servers can come from user-level configuration, project-level .mcp.json, or plugin manifests, and they likely share one schema. Should sendSessionId be allowed from all of these sources, or only from user-level configuration? Allowing it from a repository's .mcp.json or a plugin means opening a project or installing a plugin could start sending session ids to a server the user did not configure themselves. I'd lean toward user-level only (or requiring explicit user approval for project/plugin entries), but I'm happy to follow your preference.

Additional information

No response