Fix cascade behavior: denying mcp tool calls should return exit code 2#4
Conversation
![devin-ai-integration[bot]](https://avatars.githubusercontent.com/in/811515?s=60&v=4){kind=small}
| ServerURL: input.ToolInfo.ServerURL, | ||
| ToolName: input.ToolInfo.MCPToolName, | ||
| ToolInput: input.ToolInfo.MCPToolArguments, | ||
| ServerURL: input.ToolInfo.MCPServerName, |
There was a problem hiding this comment.
🟡 Cascade MCP server name assigned to ServerURL field, misleading consumers
The MCPServerName (a server name like "my-server") is assigned to the ServerURL field of ExecutionContext, which is documented as "MCP server URL".
Detailed Explanation
At unified.go:412, the Cascade MCP tool handler maps input.ToolInfo.MCPServerName to ctx.ServerURL. The ExecutionContext.ServerURL field is documented at unified.go:175 as "MCP server URL (Cursor/Cascade only, for URL-based servers)" and in docs/reference-unified.md:119 as "MCP server URL (Cursor/Cascade only, for URL-based servers)".
For Cursor, ServerURL is populated from input.URL which is an actual URL (e.g., "https://mcp.example.com"). For Cascade, it's now populated with a server name (e.g., "my-mcp-server"). Any unified handler code that checks ServerURL expecting URL format (e.g., strings.Contains(ctx.ServerURL, "blocked.com") as shown in the old Cascade docs) will silently fail to match because the value is now a name, not a URL.
Impact: Users writing unified handlers that inspect ServerURL for Cascade MCP hooks will get a server name instead of a URL, causing URL-based filtering logic to silently fail.
Was this helpful? React with 👍 or 👎 to provide feedback.
3 participants
Fix cascade behavior: denying mcp tool calls should return exit code 2. This is a difference in behavior than other platforms, which just have exit code 0 with the deny response.
See https://docs.windsurf.com/windsurf/cascade/hooks