{"version":"2.1.219","anchor":"sdk-init-message-reports-skipped-mcp-server-configs","canonical_anchor":"sdk-init-message-reports-skipped-mcp-server-configs","heading":"SDK init message reports skipped MCP server configs","tier":"use","area":"SDK","scope":null,"heads_up":null,"url":"https:\/\/changelogs.core-directive.com\/v\/2.1.219\/e\/sdk-init-message-reports-skipped-mcp-server-configs","release_url":"https:\/\/changelogs.core-directive.com\/v\/2.1.219","markdown":"### SDK init message reports skipped MCP server configs\n\nSDK callers get an mcp_server_errors array naming rejected MCP configs, so CI can fail on it.\n\n**What**\n\nThe `system`\/`init` SDK message now carries `mcp_server_errors`, so a programmatic caller can see which MCP config entries were rejected at validation time rather than silently getting fewer servers.\n\n**Details**\n\n- each element is `{name, type, message}` for a config entry that failed validation and was skipped\n- entries whose server did connect anyway are filtered out of the array\n- the MCP config loader tags validation failures with a stable code, adding `\"invalid_config\"` alongside the existing categories\n- the schema note says the key is omitted when empty, and that \"CI can fail on `(mcp_server_errors?.length ?? 0) > 0`\"\n- the REPL bridge currently passes an empty list, so this is populated on the SDK path only\n\n**Evidence**\n\n`mcp_server_errors`\n\n- Area: SDK\n- Names: `mcp_server_errors`\n- Tier: Use it now\n- Useful: 4\/5\n- Signal: 0\/5"}