You'll notice
Enabling or authenticating an MCP server now says whether it is managed, disabled or unapproved, with the step to take.
mcp_toggle (when enabling a server) and mcp_authenticate now run a shared block-reason check that can return managed-policy, disabled, or unapproved, each with its own instructive message, replacing the old generic "blocked by enterprise managed policy" catch-all. A disabled server now instructs you to run mcp_toggle first, and an unapproved server instructs you to approve it in /mcp first.
Names in the bundlemcp_toggle/mcp
The entry above is what we published on the day. These lines were added later, as Anthropic's own pages caught up, and they sit beside the original rather than replacing it.
Added since
A small documentation edit on Channels reference touched a line naming /mcp after this was published.
* **`curl` succeeds but nothing reaches Claude**: run `/mcp` in your session to check the server's status. A `failed` status usually means a dependency or import error in your server file. To see the stderr trace, restart with `claude --de…channels-reference see the edit
Confirmed since
Anthropic's documentation has since written up /mcp, on Third party connectors with remote MCP.
**MCP server URL**: the HTTPS address where the server accepts MCP requests, for example `https://mcp.example.com/mcp`. After you continue, Claude checks the URL and pre-fills the authentication settings it detects, marked "Detected."connectors/custom/remote-mcp see the edit
Two sources agreeTwo things we can check say the same as this entry.
Anthropic's documentation agrees
Anthropic's documentation has since written up /mcp, on Third party connectors with remote MCP.
Anthropic's release notes agree
Fixed /mcp reconnect and enable still connecting a settings-file MCP server that a managed MCP allow/deny list or…