There's no documentation for handling tool calls sent to the client, and I've found no way to make this work properly. Tool calls configured to go to the client are received by the client as a message event, presumably via a WebRTC data channel. So there's no "request" to keep open and respond to directly, causing VAPI to fail. Behavior with async and synchronous tool calls to client: If the tool is set to async then the client automatically sends back a tool_call_result message with result Success. which is then passed to the LLM, causing the Assistant to be interrupted and confused. I believe these async result messages should not be sent to the LLM, and this is a bug/oversight. If the tool call is set to synchronous then the client receives the tool call message, but the server immediately regards it as having failed, and a

tool_call_result

message with result

No result returned.

is sent to the LLM. I believe the correct behavior would be to wait until the timeout is exceeded. Sending a message from the client with the role

tool_call_result

and correctly-formatted result just gives in an invalid message error. This feels like a straight-up bug. Of course, I can still send the content that the tool call requested to the Assistant as a regular system message, but by then the Assistant has already decided it's failed.

@SoulAuctioneer > Tool calls configured to go to the client are received by the client as a message event, presumably via a WebRTC data channel. So there's no "request" to keep open and respond to directly, causing VAPI to fail. Tools calls are webhook/server based so you can respond them from client side. > If the tool is set to async then the client automatically sends back a tool_call_result message with result Success. which is then passed to the LLM, causing the Assistant to be interrupted and confused. I believe these async result messages should not be sent to the LLM, and this is a bug/oversight. > > If the tool call is set to synchronous then the client receives the tool call message, but the server immediately regards it as having failed, and a tool_call_result message with result No result returned. is sent to the LLM. I believe the correct behavior would be to wait until the timeout is exceeded. Can you share the steps to reproduce this behaviour. > Sending a message from the client with the role tool_call_result and correctly-formatted result just gives in an invalid message error. This feels like a straight-up bug. Tools calls are webhook/server based so you can respond them from client side.

@Shubham Bajaj thank you for the response. > Tools calls are webhook/server based so you can respond them from client side. That is only true for server tool calls. Server tool calls make a request to the configured URL, and process the response. This is not true for client-side tool calls. For client-side calls, there is no server URL to call. Instead, the message is sent to the connected client, i.e. the VAPI SDK running on the user's device, browser, etc., that is connected to the call/assistant via WebRTC. The message is, presumably, sent via a text message on the RTC datachannel. As such, it is not a "request". tl;dr: Tools that are configured to go to the client are not webhook/server based, and do not have a request for the client to respond to.

@SoulAuctioneer Although we do not currently have a client-based tool, we do have a server-based tool. Could you please share the code snippet for the client-based tooling so that I can review it? A GitHub repository would be ideal, as it would allow me to access the environment setup details if any.

> Although we do not currently have a client-based tool, we do have a server-based tool > @Shubham Bajaj you do indeed have client-based tools. please review your documentation: https://docs.vapi.ai/api-reference/webhooks/client-message https://cdn.discordapp.com/attachments/1342336047589359618/1343763170325692507/image.png?ex=67be7479&is=67bd22f9&hm=d78c8cf9da2da9b9a296f07329a3bdc1b7abb629062e921e875bf9ac35faa6d0&

@SoulAuctioneer just wanted to confirm and avoid any confusions you want to get tool call result in client side not doing/processing tools calling on client side if that's true please let me know. Might be some confusion or misunderstanding from my side.

@Shubham Bajaj it's the second one: doing/processing tools calling on client side. I believe this used to work prior to the migration from

functions

to

tools

, though I could be wrong... I need to: 1. Receive a tool call request on the client. This already works, VAPI sends the tool call as a message, although I suspect it's just informational. 2. Send a toolCallResult back to VAPI from the client (this does not work, VAPI fails in various interesting ways). Per the documentation:

These are all the webhook messages that will be sent to the client-side SDKs during the call.
...
Request
...
type: "tool-calls"
This is the type of the message. “tool-calls” is sent to call a tool.

Response
These are the messages that can be sent from client-side SDKs to control the call.
...
type: "add-message"
message: This is the message to add to the conversation.
role: Allowed values: assistant, function, user, system, tool

The response roles

assistant

,

user

,

system

are self-explanatory and standard.

tool

and

function

are not, and there's no documentation about them.

Hey @soulauctioneer, sorry for the delay. The client-side tool processing isn’t applicable, and the documentation seems outdated. Tool calls are only server-side executable webhooks, and on the client side, they’re just informational events as you have mentioned.

@Shubham Bajaj got it. How can I make this a feature request? As it already almost works I suspect it wouldn't be hard to properly implement.

Hey Soul, you can submit a feature request here: