Tool calls

Every tool call that runs through Workforce, whether it succeeded, failed, was redacted, or was blocked, is captured with full context in Logs → Tool calls. This is what you read when an employee says their AI client could not do something, when you need to know who reached which system, and when your security team asks what an agent actually did.

This page covers tool calls: the individual tool executions an employee’s client ran. For the HTTP requests Workforce made to the third party to complete each one, see API request logs.

What’s captured

The table shows time, Connector, tool name, Tool Pack, employee, status, and duration. Open a row and the full record is there:

• Tool name, namespaced as <Connector>__<tool>, like slack__post_message
• Employee, whose credentials ran the call
• Tool Pack, which pack the call came through
• Status, success, failure, pending, or blocked by a rule
• Duration, total time from receipt to response
• Arguments, exactly what the client passed in, post-redaction
• Result, exactly what came back, post-redaction. For a failed call this is where the Connector’s error message lands.
• Headers, the X- headers the client sent plus W3C trace context (traceparent, tracestate, baggage), useful for tracing
• Request ID, the id Workforce assigned the request, returned to the client in the MCP response _meta as dev.merge/request_id and in the X-Request-ID header. Filterable on an exact match of the full id.

The record also carries client_trace_id and turn_id when the calling client sends the headers they come from. Those two are served by the log endpoint rather than shown as their own fields in the dashboard, where you read them off the raw headers. See Correlating with the model request.

The same rows are available from the GET /api/v1/logs/tool-calls/ endpoint, which is how you stream them to a SIEM. The API reference has the schema.

Filtering

The filter bar covers the dimensions you reach for:

• Employee. Every call one person’s client made. Type to search by name.
• Connector and tool name. Narrow to one Connector, or to a single tool.
• Tool Pack. Useful when you run more than one pack and want to scope an investigation.
• Result status. Success, failure, pending, or blocked.
• Date. Is after, is before, or is between two timestamps.
• Request headers and tool call response. Free-text search inside the headers the client sent and the result that came back.
• Request ID. Exact match, for jumping straight to one call.

Filters compose. “All slack__post_message calls for one employee in the last hour with status failure” is one combined query.

Correlating with the model request

A tool call is one step inside a larger unit of work: an employee prompt that their client answered with several model requests and several tool calls. Two fields let you reassemble that unit.

Both are read from the request headers rather than the payload, so they survive redaction, and both are opaque ids Workforce does not interpret.

Two coding agents populate them with no work on your side. Claude Code sends the same traceparent trace id on every model request and every HTTP MCP tool call in a prompt once CLAUDE_CODE_PROPAGATE_TRACEPARENT=1 is set on the device. Codex CLI sends its turn metadata on model requests and on tools/call. The parsing rules match Gateway’s, so the same ids appear in the LLM calls and you can join a tool call to the model request that decided to make it.

Drilling into a single call

Click any row to open the call detail, which has a Tool call tab and an API calls tab. The Tool call tab holds:

• Details, the MCP URL, Connector, tool name, Tool Pack, employee, start time, duration, and request ID
• Headers, the ones the client sent, shown when the call carried any
• Request body, the full arguments JSON
• Response, the status badge and the full result JSON

API calls holds every request the Connector made to the third party for this tool call, one collapsed row per request showing its method, URL, status, and time, each expanding to the full request and response headers and bodies.

For a failed call the upstream error message is in the result JSON. What a security rule matched on the call is recorded separately, in Violations and alerts.

Debugging a failure

The flow for “my AI client’s tool call did not do what I expected”:

1. Find the call. Filter to the employee and the tool, narrow by time. The call is there within seconds of the client running it.
2. Check status. A success with a wrong result means the third party returned what it returned. A failure means read the error in the result JSON.
3. Read the arguments. Did the model pass what you expected? If not, the fix is usually a tool description override or a tool input override to constrain what the model can produce.
4. Check the violations. If a field is missing from the result, a rule probably redacted it. Violations and alerts names the rule. Adjust it, scope it to a different Tool Pack, or accept the redaction.
5. Check the third-party call. Open the API calls tab and read the status the provider returned. A 401 or 403 means the employee’s stored credentials for that Connector are bad and they need to reconnect it. A 404 means the resource does not exist or that employee does not have access to it. A 429 means you have hit the third party’s quota.

Retention

One window covers tool call logs, the Audit trail, and violation records. Past it, individual calls are not queryable through the dashboard or the API. The default is 90 days, and your plan or contract can set a longer one.

If you need a longer history, forward events as they happen rather than planning to fetch them later. Subscribe to the tool_call and tool_call_error webhooks to land them in your own warehouse, or stream them to a SIEM.

Next

Read the raw provider exchange behind any of these calls in API request logs.