Hi Retell team, can you please review session ID call_c102a3bdec970612641a2fe0f75 for agent ID agent_54683001abc711bb3e0e57c055? Specifically, the fetch_availabilities tool is supposed to return an array of eligible slots, but the Tool Result does not even show the “slots” variable. But when I go into Data, the slots fully show up.
I believe the agent is not able to see this “slots” array, so it is failing to book appointments successfully. This is blocking our operations - can you please take a look?
Hello @phoebe On call_c102a3bdec970612641a2fe0f75, the fetch_availabilities response body exceeded our tool-response size cap (15,000 characters). When that happens we truncate the JSON the agent sees down to just the top-level fields — in this case {"success": true, "has_availability": true} — and drop large arrays like slots. The “Data” tab is unaffected because response-mapping / “Store Fields as Variables” runs on the full raw webhook body before truncation, which is why you still see all the slots there. So the agent genuinely didn’t see the slots array on this call, which is why the downstream book_intro_call step then failed.
A few options to unblock, in order of least invasive:
Shrink the payload from your webhook — return only the next ~15–25 candidate slots, use short keys, and drop any fields the agent doesn’t need. Most availability payloads fit comfortably under 15KB when trimmed.
Consume the array via the mapped variable, not the tool result. Since your response-mapping already captures slots into a collected dynamic variable, you can reference {{slots}} in the next node’s prompt or as a tool argument instead of relying on the LLM re-reading the full array from the tool output.
If neither works for your use case, let us know and we can look at raising the tool-response cap for this org.
Happy to help sanity-check whichever direction you take.