Bug: Custom Function GET query params not substituted during live calls (works in manual test)

Support Help
1

Summary: Custom Function (GET method) dynamic variable substitution fails during live/simulated conversation tool-calling, but works correctly in the function’s own manual Run a test dialog. The LLM correctly computes the argument values, but the actual outbound HTTP request contains the literal, un-substituted placeholder text instead of the real value.

Environment: Agent ID agent_833ad3ab9e4067171e056597a1. Function type Custom Function, Method GET. Affected function name check_calendar_availability. Target API Cal.com v2 /v2/slots.

Steps to reproduce: 1) Create a Custom Function with method GET. 2) Add a dynamic variable placeholder to the request, using double curly brace syntax around the variable name - tested two ways, both fail identically: embedded directly in the URL string, or added via the separate Query Parameters key value fields. 3) Save the function and reference it from the agent prompt so the LLM invokes it with computed arguments. 4) Start a conversation where the model calls the function with real computed values, e.g. start_time 2026-09-15T08:52:00-04:00, end_time 2026-09-22T08:52:00-04:00, timezone America/Toronto. 5) The Tool Invocation log correctly shows the LLM computed arguments. 6) The Tool Result shows the external API returning a 400 error, and the error payload shows the actual request URL contains the literal, URL-encoded placeholder text instead of the value - decodes to the literal unsubstituted variable name wrapped in double curly braces.

Example failing tool_call_id: call_k1LgvDFWeUac2N043cttBeUB

What works for comparison: the same function tested via the Run a test dialog with manually typed values correctly substitutes and returns real data. A separate Custom Function using POST with a JSON body (Payload args only mode) does NOT exhibit this bug - values ARE correctly substituted during a live conversation, and successfully created a real Cal.com booking.

Conclusion: the bug appears isolated to dynamic variable substitution in GET request URLs and query parameters specifically during live tool-calling execution, not the manual test tool, and not POST body payloads.

Impact: any Custom Function needing LLM-computed values via GET query parameters cannot work during real calls, even though it works in the function’s own test panel. Happy to share more details if useful. Thanks!

2

Hey @johann.lara.aranda00

Tthanks for the detailed report and reproduction steps. I’ll check this with the relevant team and get back to you once I have an update. Thank you for your patience.

Best regards.

3

Hey @johann.lara.aranda00

Are you using the native cal.com integration not an option?

Best Regards.

4

Hey mark1, following up - the native “Check Availability” integration (under Connected Integrations) works correctly! Unlike the raw Custom Function (GET), it doesn’t go through the same {{…}} string-substitution path, so start_time/end_time/timezone get passed through properly even during live/simulated conversation calls. Tested it end-to-end (full simulated conversation, not just Run a test) and it returned real available_slots data with no errors.

So that’s a solid workaround for anyone hitting this - switching check_calendar_availability from a Custom Function to the native integration. Still think the underlying bug (GET query param substitution in Custom Functions) is worth fixing though, since not everyone building a scheduling flow wants to be locked into a native integration for every use case. Thanks for pointing me in that direction!