[FEATURE] Fork/copy actions and MCP configs from official provider MCPs (Notion, Linear, Google Apps, etc.) to optimize for agents

[aliasgher-sketric]

Is your feature request related to a problem? Please describe.

The current Pipedream actions and MCP tool configs are not optimized for agent use.

Generic tool names and descriptions derived from component configurable_props, which are written for human workflow builders, not for LLM tool selection and parameter filling.

No alignment with official MCP servers published by providers (e.g. Notion MCP, Linear, Google-related MCPs), which are explicitly designed for agents: clearer tool names, better descriptions, and schemas that reduce hallucination and wrong calls.

Inconsistent coverage of "viral" apps: The most widely used apps (Notion, Linear, Google Calendar, Gmail, Slack, etc.) would benefit most from agent-optimized tool definitions, but today they use the same generic mapping as the rest of the registry.

So agents get a worse experience on the highest-value integrations.

Describe the solution you'd like

Fork or copy actions and MCP configs from official MCPs
For key providers (e.g. Notion, Linear, Google Apps), either:

Option A: Introduce "agent-optimized" variants of existing actions (or new actions) whose tool names, descriptions, and parameter schemas are copied/adapted from the official provider MCPs, so the Pipedream MCP server exposes agent-friendly tools while still using Pipedream auth and execution; or

Option B: Maintain a separate layer of "MCP config" (tool name, description, schema, annotations) that overrides or augments the component-derived tool definition when the app is used via MCP, without forking action implementation code.

Prioritize the most viral / high-impact apps
Start with a short list (e.g. Notion, Linear, Google Calendar, Gmail, Slack, GitHub) and explicitly optimize their actions and MCP configs for agents. Then expand based on usage and demand.

[alisadiq1999]

It would be awesome if we can do this, linear and notions official MCPs are so much better for the AI Agents than the current ones in Pipedream.

[dannyroosevelt]

@aliasgher-sketric thank you so much for the feedback — I lead Product for Pipedream Connect (including for our MCP server).

Have you run into specific issues during configuration and / or execution? How are you interfacing with our MCP server?

We've discussed some similar ideas, so I'd love any additional specific feedback you have on challenges you've run into.

[aliasgher-sketric]

Hello @dannyroosevelt , first of all thank you for your comment and interest in this feature.

Currently this is how we interface with the MCP Server:

• We use the OpenAI HostedMCPTool to connect with the server , so basically we just pass the URL, and required headers and the OpenAI Client connects with the server and passes the tools on the server to the LLM.
• The LLM sees the schema of the tool and calls the tool accordingly.

So our use case of using pipedream is in a highly Agentic paradigm, we do not decide when and how tools should be called but the LLM decides it.

The primary issues we face right now is that many actions are developed such that they will be called independently and someone will configure them, yet this is not the case for us. This is especially seen where configurable dynamin props are involved for example spreadsheet ids in Google Sheets, or user ids in Linear.

When we use the official MCPs of the above apps (Linear provides an official MCP) the performance of our Agents are much better to let them discover these configurable props on runtime and make better decisions.

Another problem we faced was the schemas are not well defined and the descriptions are really brief of specific attributes in tools , this creates confusion for the LLM on how to configure them. For e.g in a specific tool of WA Business an attribute was accepting object type but the Agent was for some reason continuously configuring it as string type. (see #19821)

Another critical problem we faced is that if a tool call is failed the response generated by the server sometimes consumes a lot tokens this unnecessarily increase costs at our end , the response payloads should be LLM friendly so that they understand errors and make good decisions to fix them in subsequent calls.

For now these are some of the critical issues we are facing with using Pipedream Connect, our platform https://sketricgen.ai enables non technical people to create no code AI workflows and integrate 2000+ Pipedream apps to them, so for us it is imperative that these tools work without much configuration on our user side.