Why do manually connected accounts in Pipedream Connect show in the UI but aren't usable by the Langchain agent, whereas agent-generated connections are functional but not visible in the UI?

Help
1

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

Hi team,

I encountered a problem while using Pipedream Connect with my SaaS.

Accounts connected manually via connect link, HTTP request, or UI appear in the UI but can’t be used by the external Langchain agent via the HubSpot MCP tool.

When the agent detects no connection, it generates a Connect Link internally; using this link connects my account and allows the agent to use the MCP tool, but these accounts don’t show in the UI.

Could you clarify why manually connected accounts show in the UI but aren’t usable by the agent, while agent-generated connections work but remain invisible?

2

I saw your email also, but I’ll respond here — this sounds like you probably are not passing your Pipedream developer credentials (and specifically an access token) in the MCP tool call. Can you show me how you’ve implemented Pipedream MCP?

3

Hi ,

Thanks for your reply ! I actually figured out the issue on my side: the MCP tool wasn’t able to find the connected accounts because I was passing the projectId and environment incorrectly. I had the right values, but they weren’t being picked up properly until I passed them as query parameters directly in the SSE URL. After that change, everything worked smoothly.

That said, I did notice something that seems more relevant to your infrastructure: it appears possible to generate a Connect Link from the agent and connect an account without any authentication or valid external user ID. The remote MCP accepts the connection and links the account to this arbitrary (or even fake) external user ID, which you can later reuse whenever you want, even though no Pipedream acces token is authenticated in the process.

In a multi-tenant SaaS setup like mine, this could potentially allow agents to connect accounts outside of any user context, which raises questions not just around security, but also about how usage is tracked and billed on your side.

Just wanted to flag it in case it helps, thanks again for your support.

4

That said, I did notice something that seems more relevant to your infrastructure: it appears possible to generate a Connect Link from the agent and connect an account without any authentication or valid external user ID. The remote MCP accepts the connection and links the account to this arbitrary (or even fake) external user ID, which you can later reuse whenever you want, even though no Pipedream acces token is authenticated in the process.
Those accounts that are created in this case are short lived and are automatically deleted after a short time. They’re essentially created in an internal Pipedream workspace and project. But when you pass your developer credentials, those users and accounts are created in your Pipedream workspace and project, and are only accessible with your developer credentials.

Let me know if that makes sense and alleviates your concern.

5

Yes, thanks, that makes sense! The fake user ID works short-term, but only real dev credentials create persistent accounts in my project.

6

Quick follow-up: if multiple accounts of the same type (e.g., two HubSpot accounts) are linked to the same external user ID, is there a way to select or target a specific one via the MCP?

I couldn’t find anything about this in the docs.

I do see the list of supported params (like projectId, environment, etc.), but there doesn’t seem to be any appId or similar field to differentiate between multiple accounts of the same provider.

7

Not currently, though that’s been discussed in the past. What’s the priority on supporting that from your perspective?

8

The underlying Connect API fully supports it, we just haven’t yet extended support to the MCP interface.

9

Thanks Danny, for us, it’s quite high priority.

Let me know if you need anything from my side to move forward.

10

Can you tell me more about the use case?

11

By the way we shipped the ability to define specific accounts you want to use for a given user and app. So if your user has 2 connected Gmail accounts for example, you can pass accountId as a query param or x-pd-account-id as an HTTP header. The account ID should start with apn_xxxxxxx.

Updated docs are forthcoming!