This is the second MCP connection I have tried that has the same result.
Hey @bsnipes, could you please record the error you’re seeing when trying to add this custom MCP server? That’ll help us understand what might be causing it: Gumloop: Build AI agents for work
Also, could you share the link to the custom MCP server so we can try to reproduce the issue on our end?
Yes. Two links from different companies both did that same behavior:
This MCP connector: https://app.taxmcp.io/mcp
And this one: https://mcp.patent.dev/mcp
Thanks @bsnipes! Would you also be able to record the issue using the link above? That’ll help us capture the logs and see what’s happening during authentication: Recording Link
Same issue here with https://api.crisp.chat/mcp/
We tested two completely independent auth methods against this same server:
- Header-based (Authorization: Bearer )
- Pre-signed URL with the token embedded in the URL itself
Both connect successfully but fail identically at tool discovery, and execute also fails with mcp_server_connection_failed even though list_tools returns connected/tools=[].
We also independently verified the server itself is completely healthy: calling tools/list directly via curl with the same Authorization header returns a full, valid response with all 26 tools. So the token, the header format, and the server are all confirmed working outside of Gumloop.
This points to the discovery/connection step inside Gumloop itself, not a configuration issue.
@bsnipes The Fix! URL-encode the slash instead of typing it literally.
Instead of: “https://api.crisp.chat/mcp/”
Use: “https://api.crisp.chat/mcp%2F”
My guess is that something in the Gumloop pipeline strips trailing slashes before the URL hits tool discovery. %2F isn’t a literal slash yet, so it survives that step and decodes back to a real / further down, past whatever’s stripping it. Not confirmed but this fits the behavior.
@Wasay-Gumloop Thanks for your help with this!