Tool Call Flow
The tool call flow draws one gateway tool call as the path it actually travelled. Instead of reading the raw log JSON to work out what an agent did, you see each step the call passed through, which one stopped it if it never completed, and how long each part took.
Open the flow
In Monitor > Logs, hover a Tool Call row and select the view icon (its tooltip reads View call flow). The same flow opens from a tool call in a Recent Activity list, on the dashboard or on an MCP server's overview.
Only tool calls have a flow. Every other action type (Init, Connect, Connector Auth, Webhook, Messages, Conversations) keeps opening the JSON details modal.
Reading the header
The header sums up the call in one line: the user's email, the AI agent, the MCP server, and the tool name, followed by an outcome badge, the total duration, and the timestamp.
| Outcome badge | Meaning |
|---|---|
| Completed | The call went through every step and the tool returned. |
| Waiting for approval | The call is held until someone approves it. |
| Blocked by … | A step stopped the call, for example Blocked by a rate limit, Blocked by user risk, Blocked by an input guard, Blocked by a condition, or Blocked by an output guard. |
| Could not reach the MCP, The MCP returned an error, Tool call failed | The gateway let the call through, but the upstream server failed. |
Switch between Flow and Raw JSON at the top right. Raw JSON shows the same full log row the details modal does.
The steps
The flow reads left to right, in the order the call passed through the gateway:
| Step | What it shows |
|---|---|
| Source | The AI agent that made the call (or the background agent, with the person or trigger that started it), its transport, and the session. |
| Sign-in | How the caller signed in to the gateway: your SSO provider or Willow sign-in, and the resolved user. |
| Gateway | Which gateway served the call, and the timing breakdown for the whole call. |
| Rate limits, User risk, Approval, Conditions, Input guards | The checks that run before the tool, drawn side by side. Each one shows whether it passed, stopped the call, wasn't required for this call, or was never reached. |
| MCP authentication and Gateway SSO | How the gateway authenticated to the MCP server, and whether it forwarded the caller's SSO token. |
| Outbound call | The hop to the upstream server: a remote MCP, a REST call, or a local command. |
| MCP server and tool | The server and tool that ran, its credentials, and its execution time. |
| Guards after the tool | The output guards that evaluated the response, and whether any blocked, warned, or redacted it. |
| Input · arguments and Output · response | The request arguments and the response, with their size and token count. |
| Result | The outcome, error code and message, total time, total tokens, and the timing breakdown. |
When the call stopped early, the step that stopped it is marked with a red cross, and every step after it is marked as not reached. The flow opens with that step already selected, so the reason is the first thing you see.
Step details
Select any step to open its details beside the graph. A check lists every policy, condition, or guard it evaluated and how each one went, for example the rate limit policy that was reached and how many calls it allows. Guard steps name the guards that ran and the ones that triggered.
The Timing breakdown in the Gateway and Result steps splits the call into stages: organization and installation lookup, rate limit check, user risk check, input guards, conditions, building auth headers, MCP init, tool execution, output guards, and the audit log write. Use it to see whether time went to Willow's checks or to the upstream server.
Local MCP calls
When a call ran on the device through a local MCP, it never passed through Willow's gateway. The flow still draws the checks and guards, but marks each one bypassed (Runs on Willow's gateway · skipped) rather than passed, so a skipped pipeline doesn't read as a clean one.
Older log rows
The flow is built from the log row alone. Rows written before the gateway recorded stage timings, or before it recorded guards that passed, show less: a guard stage with nothing recorded is shown as having no data rather than as passing.