{"version":"2.1.309","anchor":"mcp-authenticate-gains-livereply","canonical_anchor":"mcp-authenticate-gains-livereply","heading":"MCP status and sign-in requests can ask for a live-only reply","tier":"use","area":"SDK","scope":"individual","heads_up":false,"url":"https:\/\/changelogs.core-directive.com\/v\/2.1.309\/e\/mcp-authenticate-gains-livereply","release_url":"https:\/\/changelogs.core-directive.com\/v\/2.1.309","markdown":"### MCP status and sign-in requests can ask for a live-only reply\n\nThe mcp_status and mcp_authenticate requests gain a liveReply option that sends the answer only to clients attached right now, without saving it\n\n**Unclear.** It is not clear how the separate reply differs from the usual one.\n\n**What**\n\nMCP servers are outside programs that give Claude Code extra tools. Programs that control Claude Code, such as the SDK or a remote client, can send it requests. Two of these requests now accept a new `liveReply` option:\n\n- `mcp_status` (which reports the state of each MCP server) took no options before. With `liveReply` set, and when Claude Code is writing through a cloud session, the answer goes only to the clients attached at that moment. It is sent as a `control_response` marked `live_only: true` and is not stored in the session history. On cloud workers this answer includes each server's configuration, such as URLs, headers and OAuth (sign-in) settings. In headless mode, a successful `mcp_status` with `liveReply` is answered through this separate path.\n\n- `mcp_authenticate` (which starts signing in to an MCP server) with `liveReply` set sends the sign-in URL through a different reply path than the usual final answer.\n\n- The remote-session client keeps track of these live-only requests separately from other requests.\n\nThe MCP connection check also now treats a new `replaced` server state as finished, and takes into account whether a request was relayed.\n\n**Why**\n\nA program can ask for MCP status, which may include server URLs and headers, without that answer being saved in the session history. It can also receive a sign-in link before the sign-in flow completes.\n\n- Area: SDK\n- Names: `liveReply`\n- Tier: Use it now\n- Useful: 3\/5\n- Signal: 3\/5\n- Scope: individual\n- Heads-up: no"}