I am hereby reporting a critical bug where my assistant is calling the incorrect tool, despite clear instructions and a UI that reports the correct tool was called. My backend automation is working perfectly and has proven the discrepancy. The supposed Bug: After a successful Outskill-Live-Check-Availability call, the assistant collects user details to book an appointment. My prompt then explicitly commands it to call the Outskill-Live-Book-Appt tool. The Vapi call transcript correctly shows a green checkmark next to Outskill-Live-Book-Appt. However, the actual data sent to my webhook proves that the Outskill-Live-Check-Availability tool was called again instead. This is probably a critical bug: The Vapi front-end UI is reporting a different tool call than the one its back-end is actually executing. Proof: I have attached two screenshots that prove this discrepancy: vapi_transcript.png: Shows the Vapi UI successfully "completing" the Outskill-Live-Book-Appt call. make_com_webhook_log.png: Shows the filter inspector from my webhook server, proving that the intent it actually received was Outskill-Live-Check-Availability. Conclusion: My system prompt is logically sound, and my server is working correctly. The Vapi platform is getting stuck in the context of the first tool call and is incorrectly calling it again, overriding the prompt's instructions. Please investigate why the assistant is calling the wrong tool and why the UI is reporting a different action than the one being executed. My Assistant ID is [72972e66-3cd0-49ec-812c-fc7b63fa0616] and the Call ID is [0199eec3-b760-711e-81e3-fe067b65d80f] The Issue occured yesterday at around 23:00. Thank you for your attention to this critical issue. https://cdn.discordapp.com/attachments/1428612563268145162/1428612563532513310/IMG_0398.png?ex=68f322a1&is=68f1d121&hm=d5c32a695435fc2c0d4f5b350e76582873b37098fb78e0ba3cb0621fd879d366& https://cdn.discordapp.com/attachments/1428612563268145162/1428612563943424094/IMG_0399.png?ex=68f322a1&is=68f1d121&hm=fb4a61dce4b3da9fdccf9346eaf9809338d2a6e4c6457999528f626bc2fde544&

Thank you for your detailed report. To help us investigate further, could you please confirm whether the "Call Logs" in your Vapi dashboard (under Observe > Call Logs) show the same tool call as the webhook data, or do they match the UI (i.e., Outskill-Live-Book-Appt)? This will help determine if the discrepancy is between the UI and backend, or if it also appears in the platform logs. Your answer will help us pinpoint where the issue may be occurring in the workflow. Source: - [Vapi Debugging Documentation](https://docs.vapi.ai/debugging)

Hey, that’s a sharp catch — looks like Vapi might be reusing the first tool context or misrouting calls after the initial trigger. I can help trace where the mismatch happens between the UI log and webhook data. Sometimes this occurs if tools share schema IDs or internal names. Could you confirm if each tool has unique names and endpoints in your setup? @Astro

Hi, @Vignxt Flow Thanks for the quick response. I can confirm the following about my setup: Unique Names: Yes, the tools have unique names: Outskill-Live-Check-Availability and Outskill-Live-Book-Appt. Endpoints: Both tools intentionally point to the same webhook URL on my server (Make.com). My server uses a router to differentiate between the tool calls based on their unique name. This setup works perfectly for the initial Outskill-Live-Check-Availability call. The issue occurs on the second tool call. Even though the conversation context and my prompt require a call to Outskill-Live-Book-Appt, the assistant incorrectly calls Outskill-Live-Check-Availability again. This confirms the suspicion that the platform is incorrectly reusing the context from the first tool call. Please let me know what you find or if you need any other information. Thanks, Ivo

Thank you for the detailed explanation. We have sent all this info to the team and will get back to you shortly

Hi Kyle, thank you a lot! Hope to hear from you again soon.

1. Your booking webhook replied 

200 OK

 with body 

Accepted

 (just plaintext) 2. Vapi requires a 

{ "results": [ { toolCallId, result|error } ] }

 JSON body 3. Because the response didn’t follow that shape, Vapi shows “No result returned” 4. The green “Completed successfully” badge in Vapi only means the HTTP request succeeded, not that a tool result was returned

Hi Kyle, Thanks for confirming the required response format. I've double-checked my Make.com setup, and both webhook responses (for check_availability and book_appointment) already strictly follow the { "results": [ { "toolCallId": "...", "result": "..." } ] } format, including the correct toolCallId. (See attached screenshots). However, the original problem persists. On the latest test run, the Vapi UI showed Outskill-Live-Book-Appt being called, but my Make.com logs definitively prove that Outskill-Live-Check-Availability was actually called instead. My filter correctly caught this mismatch. This confirms the issue isn't the response format, but that the Vapi platform is getting stuck in the context of the first tool and calling the wrong function during the booking step, despite the prompt's instructions. Could you please investigate this context handling / tool routing discrepancy further? Thanks, Ivo https://cdn.discordapp.com/attachments/1428612563268145162/1431028402374180949/a2efd96c-c848-421a-a0ad-e4860221f4c8.png?ex=68fbec8e&is=68fa9b0e&hm=93f0c609be99106689243c26ed4dc5e771b0aef7ececa90b0b3f816edb5a4b95& https://cdn.discordapp.com/attachments/1428612563268145162/1431028402680238172/ed9d35dc-eb4c-4954-b210-e36e2782d68e.png?ex=68fbec8e&is=68fa9b0e&hm=2b322cf0b495ab4cf58e19da9fac9d84f84b9e1f89a2b6a8a7b397087d0bcc6b&

Hi Ivo, Thanks for sending over the screenshots. To help us narrow this down further, could you share the full [Make.com](http://Make.com) log output for that call (instead of the filtered view)? Seeing the complete request and response data will help us confirm whether the platform is misrouting the tool call or if something else is happening in the flow. Once we have the full log, we’ll be able to investigate this more precisely.

Hi Kyle, Im sending it to you as a screenrecording because it would be a lot of screenshots. I also provided the Json blueprint of my whole scenarion on make, just in case it might help you. Thanks a lot for your help again! Ivo https://cdn.discordapp.com/attachments/1428612563268145162/1432505674067214377/2025-10-27_23-57-53.mkv?ex=69014c5f&is=68fffadf&hm=567f3eef78a475d6a719c793e2a66d9fd3e35aef645ac13a57c7921e4f174128& https://cdn.discordapp.com/attachments/1428612563268145162/1432505674625060925/2025-10-28_00-00-39.mkv?ex=69014c5f&is=68fffadf&hm=fc76f20c60bd9427eb6745eb592301149d6e1bc21222f76fc1c5e27259573b3c& https://cdn.discordapp.com/attachments/1428612563268145162/1432505674939760823/Integration_Webhooks_copy_gemini.blueprint.json?ex=69014c5f&is=68fffadf&hm=dd8ec108601ba26e2c84aa82b644d07171de1920cf3e2bc32bca733b364102b0&

Not sure if you saw my response yesterday, but in case you didnt I will put my findings here as well. Your webhookUrls for both of your tools are the same, so you might need to check if the webhook URLs on the [make.com](http://make.com) side are different for each node.