The Cascade MCP page describes familiar mechanics: an mcp_config.json file, a marketplace for installing servers, a one-click deeplink. All of it looks like a shared tool setting for Devin Desktop - and here it is easy to err. The documentation marks it plainly: this is the configuration of the legacy Cascade agent, not Devin Local.
The naive move is to find the needed server by the name of its function and copy its config from Cascade into new work, expecting the tool to "just appear" for the current agent. Since MCP is one and the same protocol, the setup seems shared: connect once - works everywhere.
It breaks on the fact that MCP as a protocol is shared, while the configuration and the trust policy are not. Cascade keeps its servers in its own ~/.codeium/windsurf/mcp_config.json; Devin Local - the default agent for new tabs - configures MCP in the Devin CLI config, separately. A server copied by name is at best invisible to the new agent and at worst drags secrets and permissions along from someone else's environment.
Hence the order of migration: not by the name of the function but through the specific agent's settings. First open the Customizations of the agent that needs the tool. Move the server into its own separate config - for Devin Local that is the Devin CLI config, not Cascade's mcp_config.json. Remove the secrets from the file and set the tool-level grants anew: which of the server's tools exactly are allowed. The word "rebuild" here is literal: grants are set again, looking at what the server actually needs in this task, rather than carrying over the previous broad access by inertia. A minimal set of allowed tools is not over-caution but a way to limit what external code can do on your behalf. Migration is a rebuild of access, not a copy of a line.
Cascade MCP itself has documented boundaries worth remembering when taking apart an old config. It supports the transports stdio, Streamable HTTP and SSE, as well as OAuth for each of them. And it has a ceiling: up to 100 total enabled tools at a time. This limit explains why some servers have to be kept off, and why during a migration it is reasonable to take not everything but only what is actually used. The limit of 100 tools is not only about Cascade: it is a reminder that each connected server adds functions to the agent's shared attention budget, and a dozen half-forgotten servers can crowd out the ones actually needed today.
Web search in Cascade is also its own mechanics, not shared. The mentions @web and @docs and a URL pasted into a prompt belong to Cascade's web/docs search: @web forces a search, @docs turns to the documentation, a pasted address is read directly. Reading pages, moreover, is performed locally, on your machine. Devin Local has its own web and fetch tools, and they obey its own tool and permission model, not Cascade's settings.
Why this is separated rather than reduced to one setting. Cascade and Devin Local are different agents with different trust boundaries, and a shared config would mean a shared policy where there should be none. A tool allowed to one agent need not be allowed to another; a secret available to the legacy environment must not automatically flow into the new one. Separate configuration is not an inconvenience but a security boundary between two executors.
The cost of copying by name is concrete. At best you debug a server that the current agent does not see at all, because you looked in the wrong config. At worst you carry a secret into someone else's file or hand out tool-level grants wider than needed, expanding the attack surface. The mistake is the more dangerous because an MCP server is external code with access to your data, not just a line of settings.
You should check the migration from the side of the needed agent, not the old file. Whether the server is visible for exactly the agent that needs it, in its Customizations. Whether a secret is left in the config - it is looked for the same way as any secret before a commit. Whether grants are set by name rather than "everything allowed". Whether you fit within the limit of enabled tools without keeping extras for show. For web - whether fetch works under the needed agent's permission model rather than from memory of Cascade.
The typical failure is configuring the wrong layer. "The server did not connect" - because the config was edited for Cascade while Devin Local is running. "The tool is not visible" - because you hit the limit of 100 or the server is off. "A secret leaked" - because the config was copied verbatim. "Web does not search" - because @web belongs to Cascade while the current agent uses its own model. The sign is the same: a setting is migrated by the name of its function without naming the agent and its config. Name the agent and open its Customizations first - most often the problem is right there.