This topic was automatically generated from Slack. You can find the original thread here.
Hi! I’m connecting Pipedream’s integrations to my AI Agents using the MCP infrastructure provided by Pipedream!
I am using the tools-only mode for the tool props, but I can’t get it to work with dynamic props.
Let’s use the “Slack” integration as an example with the slack-send-message tool. This tool has a customizeBotSettings prop which, when set to true, a new username prop is available (among others).
At first, my agent just tried to send both { customizeBotSettings: true, username: "Custom username" } values, along with the rest of regular attributes, without having to configure it first. However, Pipedream seems to be ignoring the username prop because customizeBotSettings was not configured beforehand! Is there no way to just skip this configuration step and send the whole complete payload instead?
If not, what’s the actual process? If my agent tries to run the provided CONFIGURE_COMPONENT tool with { componentKey: "slack-send-message", propName: "customizeBotSettings" }, I just get an should not be remotely configuring prop: customizeBotSettings error! What am I supposed to do instead?
As you call each tool, you should reload the available tools for the server, and we’ll expose meta tools for configuration, such as begin_configuration_google_sheets-add-single-row, which causes the rest of the tools to be removed and only tools relevant to the configuration are exposed.
Which tool do I need to call in this case, in order to begin the tool configuration? Should I call slack-send-message? Because that will just trigger the action instead of let the AI configure it. Should it be CONFIGURE_COMPONENT? Because I can’t seem to make it work with customizeBotSettings in order to see the username prop available anywhere…
Ideally, I’d like to receive a more complex schema for the tools from the beginning, where it already has defined the different possible attributes and optional values.
However, since that is not the case, I would at least be able to pass the complete payload, even if some of the attributes did not appear in the provided schema when listing tools. Using the example from before, to directly pass { customizeBotSettings: true, username: "Custom username" } without it ignoring this latter attribute just because I didn’t “configure” the first one beforehand…
I am using the official modelcontextprotocol sdk’s client, with the Transport as shown in your docs. Yes, I am able to reload the list of tools by running listTools on the same MCP client connection, if that’s what you mean
Sorry about the confusion and troubles here! I think tools-only might actually not fully support dynamic props, we have a fix queued up to deploy on Tuesday, which exposes a tool for reloading props / supporting dynamic props.