Dialogflow Messenger missing toolCall data in API response

Other Questions AI Agent
1

I’m working with Function Tools in Vertex AI Agent Builder and running into an issue where the toolCall information shows up in some responses but not others.

Based on the documentation, when an agent decides to use a tool, the response should include toolCall details like this:

{
  "queryResult": {
    "text": "check temperature in San Francisco", 
    "languageCode": "en",
    "responseMessages": [
      {
        "source": "VIRTUAL_AGENT",
        "toolCall": {
          "tool": "<tool-identifier>",
          "action": "fetch-temperature",
          "inputParameters": {
            "city": "San Francisco"
          }
        }
      }
    ]
  }
}

When I test this in the Agent Builder interface by asking “what’s the temperature today”, I can see the network calls to dialogflow.clients6.google.com/v3alpha1/ contain the toolCall information properly:

"queryResult": {
  "text": "what's the temperature in Berlin?",
  "languageCode": "en", 
  "responseMessages": [
    {
      "source": "VIRTUAL_AGENT",
      "toolCall": {
        "tool": "projects/myproject/locations/us/agents/12345/tools/67890",
        "action": "fetchTemperature",
        "inputParameters": {
          "city": "Berlin, Germany",
          "format": "fahrenheit"
        }
      }
    }
  ]
}

However, when I use Dialogflow Messenger integration, the API calls go to dialogflow.googleapis.com/v3/ and the toolCall section is completely missing:

"queryResult": {
  "text": "what's the temperature in Berlin?",
  "languageCode": "en",
  "responseMessages": [
    {}
  ]
}

This causes problems because my client code never gets the tool execution details, and subsequent requests fail with errors like “Session is waiting for tool call result of tool and action fetchTemperature”.

Why do these two interfaces behave differently? Is there a way to get toolCall information through the Dialogflow Messenger API?

2

I’ve dealt with this exact headache before. The issue is that Dialogflow Messenger doesn’t expose toolCall data in its standard response format, even when the underlying agent is executing tools.

What’s happening is the messenger widget handles tool execution internally and only returns the final response text to your client. The toolCall metadata gets stripped out during this process.

Here’s what worked for me:

Option 1: Custom Integration
Ditch the messenger widget and build your own chat interface using the Sessions API directly. This gives you full access to the raw response including toolCall data.

Option 2: Webhook Approach
Set up a webhook in your agent that captures tool execution events. When a tool gets called, your webhook receives the full context and can store or forward the toolCall information to your client through a separate channel.

Option 3: Response Parsing
Modify your agent’s responses to include tool execution details in the actual text response. Not elegant but it works when you need a quick fix.

I ended up going with option 1 for a project last year because we needed granular control over tool interactions. The messenger widget is great for simple chat but falls short when you need access to the full conversation flow.

The API version difference Luna mentioned is real, but even forcing v3alpha1 through messenger won’t give you the toolCall data due to how the widget processes responses.

3

sounds like your hitting different api versions - the messenger widget probaly uses the stable v3 endpoint while agent builder console uses v3alpha1. try switching your messenger integration to use the alpha version or check if theres a parameter to include tool metadata in v3 responses.

4

From my experience integrating with Vertex AI agents, this behavior stems from the messenger widget’s architecture rather than just API versioning differences. The Dialogflow Messenger essentially acts as a proxy that sanitizes responses before delivering them to the frontend. I encountered this same limitation when building a customer service bot that needed to track which knowledge base articles were being accessed. The toolCall metadata was crucial for analytics but kept disappearing through the messenger interface. One workaround that saved me considerable development time was implementing a custom event system. Instead of relying on toolCall data in the response, I modified the tool functions themselves to emit custom events with the execution details. These events get captured server-side and can be pushed to your client through websockets or server-sent events. Another approach is leveraging the conversation history API after each interaction. While not real-time, you can query the session history to reconstruct which tools were executed, though this adds latency and complexity. The fundamental issue is that Google designed the messenger widget for simple conversational flows where tool execution should be transparent to end users. For applications requiring tool visibility, direct API integration remains the most reliable path despite the additional implementation overhead.