Why Does Remote MCP Server Return 404 Instead of Inline Connect Link for Unconnected External Users?

Bugs
1

This topic was automatically generated from Slack. You can find the original thread here.

Remote MCP Server - tool calls return 404 instead of inline connect link for unconnected external users

Calling a tool via remote.mcp.pipedream.net with an x-pd-external-user-id that hasn’t connected the app yet now returns a 404 "no records found". Previously the same call returned a connect/auth link inline so the caller could surface the flow gracefully.

Symptom:
• Tool call (e.g. google_calendar-get-current-user) with a valid external user ID that hasn’t authorized the app → 404 "no records found"
• Error gives no indication that the actual issue is a missing account connection
• Same call previously returned a connect URL inline

What we’ve already ruled out:
• Auth token is valid, other SDK calls (listTools, etc.) work fine for the same user
• Project ID, environment, and external user ID are all correct
• After manually generating a connect token via POST /v1/connect/{project_id}/tokens and completing OAuth, the same tool call works perfectly → confirms the only missing piece is the account connection

Environment: @pipedream/sdk@2.3.5, @modelcontextprotocol/sdk@1.25.3, transport: Streamable HTTP (StreamableHTTPClientTransport), started seeing this around late May 2026.

What would help:

  1. Was the inline connect-link behavior intentionally removed? If so, roughly when did this change ship?
  2. The 404 "no records found" is misleading for this case, could the response carry a structured error code (e.g. ACCOUNT_NOT_CONNECTED) so MCP clients can branch on it cleanly?
  3. If the inline connect link can be restored, that would be ideal; otherwise the documented recommended pattern for handling unconnected users from an MCP client would unblock us.

Happy to share full request/response payloads and a minimal repro over DM.

2

Any feedback on this ?

3

Hi, we are looking into this and will share feedback with you when we have it. I agree that is not a descriptive error response at all

4

Hi DMing you to help triage this bug

5

I think this was a bug that we just shipped a fix for — can you let me know if you’re still seeing this issue?

6

@U0ASSCRDDM2 This appears to be resolved now. I’m seeing the Authorization URL being returned correctly again instead of the 404 error we were encountering earlier:

{
  "content": [
    {
      "type": "text",
      "text": "The user MUST be shown the following URL so they can click on it to connect their account and you MUST NOT modify the URL or it will break: https://pipedream.com/_static/connect.html?token={{token}}&connectLink=true&app=google_calendar"
    }
  ]
}

cc @U0B5UBZBECX