{"version":"2.1.271","anchor":"mcp-set-servers-sdk-control-command-gains-new-restrictions-a","canonical_anchor":"mcp-set-servers-sdk-control-command-gains-new-restrictions-a","heading":"mcp_set_servers SDK control command gains new restrictions and error messages","tier":"internal","area":"SDK","scope":null,"heads_up":null,"url":"https:\/\/changelogs.core-directive.com\/v\/2.1.271\/e\/mcp-set-servers-sdk-control-command-gains-new-restrictions-a","release_url":"https:\/\/changelogs.core-directive.com\/v\/2.1.271","markdown":"### mcp_set_servers SDK control command gains new restrictions and error messages\n\nSDK-managed MCP servers pushed at runtime now face stricter rules on type, names, and how they can be toggled\n\n**What**\n\nThe SDK's dynamic MCP server management, used to add or change MCP (Model Context Protocol, a way to connect external tools) servers at runtime, now enforces new restrictions:\n\n- A server pushed while a session is running must be an http server on that session's own MCP proxy route.\n\n- Certain server names are reserved for first-party servers and can only be set when the session starts, not pushed later.\n\n- Servers can only be turned on or off by replacing the entire server set at once, not by toggling one individually.\n\n- A configuration change to a server that's already running is held and applied on the next re-dispatch, rather than immediately.\n\n**Why**\n\nThese restrictions add guardrails around runtime MCP server management, preventing conflicts with built-in servers and making changes to a running server's configuration more predictable.\n\n- Area: SDK\n- Tier: Under the hood\n- Useful: 2\/5\n- Signal: 2\/5"}