This topic was automatically generated from Slack. You can find the original thread here.
I am seeing an issue across a wider range of apps with the MCP.
Often times, the tools included in the MCP requires an account id, property id or something similar in the input parameters. However, as those attributes are not included in the Pipedream account details payload, the LLM has no way of using these tools.
A couple of apps where I’ve come across this:
• Google Analytics
• ClickUp
What is a scalable way of addressing this? I’d rather not have to go through every single app in the catalog and write custom actions to make up for this.
In the case of Google Analytics, the run-report function requires a viewId value and the run-report-in-ga4 function requires a property value. The only way to retrieve these are by first knowing the accountId value, and then querying for views / properties associated with this accountId.
So without a payload including the accountId and associated viewId and property values, the LLM is not able to use the reports functions.
In the case of ClickUp, most functions require a workspaceId.
I’m sure there are loads of similar cases across the 2,700 apps. So in general, it would just be nice if the connect webhook always included an origin_id field something similar that helps me understand which entity I just authenticated.
Similar arguments could be made for metada fields for the authenticating user/entity. For instance when authenticating the Linkedin app, the webhook just tells me the email address of the user that authenticated, but what I actually need to know is the ID, name and photo of the page / profile I just got access to, and I none of the functions will tell me that, so I can’t show to the user what they just connected to our platform.
What I’m really looking for here is some sort of scalable solution for retrieving whichever basic account information is required by the included MCP tools.
Could be a webhook payload, or could just be adding 1-2 additional tools to the relevant apps.
We don’t typically collect / store those params at the account level, since a single account might be used to connect to multiple views or properties for GA, and multiple workspaces for ClickUp. You’ll noticed if you look at the individual actions or triggers that you can configure for those apps, those are typically required props at the tool-level. Does that makes sense? Here’s an example: One SDK, thousands of API integrations
Yeah, that makes sense if I were only to expose a small subset of apps in our product. But what I am trying to achieve is exposing the entire back catalog, so this approach would then require me to go through and configure props for every one of the 2,700 apps individually - assuming I was even able to do that (which of course I am not, since many of them are paid services that I don’t personally have access to.
Yes, we are an AI-powered business intelligence platform that allows our users to extract insights about their business assets through conversational interfaces. Our use case for Pipedream is essentially allowing our customers to connect any business asset they might have (i.e. Quickbooks, Google Analytics, Linkedin, Zoom, Hubspot etc.) to our platform, and then ask questions about their data.
Our user group is not technically minded, but rather business leaders, marketeers etc. so it’s critical for us that we deliver these integrations as turn-key as possible.
So for instance, if a customer of ours were to connect their Google Analytics account to us via Pipedream, they would then expect that after doing so, they could just ask us natural language questions about their reports and data. We have an LLM on our end that translates their broad questions into more specific data queries and then connects to the Pipedream MCP to retrieve these data. But all this crumbles if the user is required to know their own account ID or if we have to sit and manually configure props for each unique integration.
Can you just handle those inputs via MCP? And in the case of viewId for GA, can that be programmatically retrieved? That’s typically the implementation we prefer — if there’s an API to retrieve metadata, we strive to not require end users to find and input IDs manually wherever possible, but I see for that Run Report action we do require the raw ID, so I’m assuming maybe there isn’t an API for it?
So in the case of Google Analytics, the property can be retrieved with a two-step approach like this (courtesy of the AI workflow builder):
import { axios } from "@pipedream/platform"
export default defineComponent({
props: {
google_analytics: {
type: "app",
app: "google_analytics"
}
},
async run({ $ }) {
// First, get the list of accounts
const accounts = await axios($, {
url: "https://analyticsadmin.googleapis.com/v1beta/accounts",
headers: {
Authorization: `Bearer ${this.google_analytics.$auth.oauth_access_token}`
}
})
// Then get properties for the first account
return await axios($, {
url: "https://analyticsadmin.googleapis.com/v1beta/properties",
params: {
filter: `parent:${accounts.accounts[0].name}`
},
headers: {
Authorization: `Bearer ${this.google_analytics.$auth.oauth_access_token}`
}
})
}
})
So ideally, this would just be an extra function in the MCP tools, so the LLM can just invoke that whenever it needs the property value for a subsequent call.
Similarly, with ClickUp, I assume there’s a way to programmatically retrieve a list of the authenticating user’s connected workspaces. If that was an MCP function, then all would be fine.
So for any Google Analytics action (tool) that requires the property, if that was a field that the MCP server was capable of retrieving options for automatically, would that work?