{"version":"2.1.317","anchor":"cloud-mcp-http-endpoint-now-requires-a-bearer-header-instead","canonical_anchor":"cloud-mcp-http-endpoint-now-requires-a-bearer-header-instead","heading":"Local plugin MCP server secret moves from the web address to an Authorization header","tier":"notice","area":"MCP","scope":"individual","heads_up":false,"url":"https:\/\/changelogs.core-directive.com\/v\/2.1.317\/e\/cloud-mcp-http-endpoint-now-requires-a-bearer-header-instead","release_url":"https:\/\/changelogs.core-directive.com\/v\/2.1.317","markdown":"### Local plugin MCP server secret moves from the web address to an Authorization header\n\nThe local HTTP MCP server for plugins now expects its secret as a Bearer token in the Authorization header instead of in the URL path\n\n**What**\n\nMCP servers are outside programs that give Claude Code extra tools. A plugin's MCP server can be reached through a small local web server on your own machine, protected by a secret.\n\n- The plugin's MCP config no longer puts the secret in the address. The address is now just the port, plugin name and version, and the secret is sent as `Authorization: Bearer <secret>`.\n\n- The local handler now reads the secret from the `authorization` header as `Bearer ${n.secret}`, compares it with a constant-length check, and answers \"not found\" if it does not match. Before, it took the secret from the first part of the URL path.\n\n**Why**\n\nAddresses often end up in logs and error messages, so keeping the secret out of the URL keeps it out of those places too.\n\n- Area: MCP\n- Tier: You'll notice\n- Useful: 2\/5\n- Signal: 1\/5\n- Scope: individual\n- Heads-up: no"}