I think the behavior is otherwise the same, just using v2 instead of v3 for the server URL
https://remote.mcp.pipedream.net/v2
I tried that but then the server responded with this:
Error retrieving tool list from MCP server: ‘hubspot’. Http status code: 424 (Failed Dependency)
I get that error 424 regardless of which app I try to load with https://remote.mcp.pipedream.net/v2. These are my headers:
{
"Authorization": "Bearer XXXXXX",
"x-pd-project-id": "XXXXXX",
"x-pd-environment": "development",
"x-pd-external-user-id": "XXXXXX",
"x-pd-app-slug": "hubspot",
"x-pd-account-id": "XXXXXX",
"x-pd-registry": "all",
"x-pd-tool-mode": "full-config"
}
Any idea why?
Will check with our team
My mistake - v2 auth is a bit different from v3. While v2 technically still works, indeed it’s not documented anymore since we expect everyone to use v3 moving forward
About the custom components - we expect to have adjusted this within the next day or two, hope that works for you. Any custom components will be available in v3 mcp except ones that have additionalProps (since these are 100% incompatible with the tools-only MCP model)
That would work for us, thanks.
Final ask from me: Could you possibly introduce a flag on components clearly identifying whether they are currently exposed in the MCP v3? I understand that this is ongoing work, but we don’t want to promise our customers certain capabilities, and it seems to me that the additionalProps is not the only factor impacting whether a tool is MCP-enabled or not?
Yes we also have something similar to what you’re asking being worked on, I don’t have an ETA on that yet unfortunately.
Your custom components should be listed now - can you confirm once you’re able to try again?
Thanks for the help debugging and triaging this, Guilherme
Apologies for the delayed response here. I can confirm now that this is working.
Any chance you have an ETA for being able to determine exactly which tools are exposed by the v3 MCP (and which are not)?
Can you tell me more about your specific use case? Is the goal just to understand what tools we have available for a given app?
The overall use case is governance. We expose the list of available tools for each app in our UI, and let users decide which tools they will allow their agents to utilize. We are trying to avoid situations where:
• A tool is listed but not actually available to the MCP, creating misaligned expectations
• The MCP has capabilities that are not among the listed tools (not sure if this is possible), preventing us from letting users decide whether to allow it.
We can’t determine this by just calling the MCP after authentication, because that would prevent us from communicating capabilities to our users prior to them authenticating the app.
You as a developer calling the Pipedream MCP server need to authenticate the tools/list request, but your end users do not need to connect an account. Does that help?
So if you list tools for Pipedream MCP from your application, that is an accurate reflection of the supported tools
So what you are saying is that with the mcp v3 we just shouldn’t reply on the component registry for vaildating mcp capabilities? What is the reasoning behind this?
That’s right, because there are actions in the public registry that were built with Pipedream’s workflow builder in mind, rather than LLMs and agents, and as a result, those just do not work well (they have dynamic schemas and descriptions / examples that are geared for humans configuring them in a UI rather than agents doing so programmatically).
So we’re working on modernizing as many as possible, and ideally exposing the actions in the v3 MCP that we have higher confidence in working well.
Ok, I understand. But would it be a big hassle for you to just expose an mcp_version field or something similar on each tool via the API? I’d rather have one source of truth from which I get all my tools than having to query multiple sources.
What is the use case for seeing tools that do not work in MCP?