> This page is for Workforce. > For clean Markdown of any page, append .md to the page URL. > For a complete documentation index, see https://docs.merge.dev/llms.txt. > For AI client integration (Claude Code, Cursor, etc.), connect to the MCP server at https://docs.merge.dev/_mcp/server. # Tool calls > What is captured in the Workforce tool call logs, how to filter them, and how to debug a failed tool call end to end from the dashboard. 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](https://wf-develop.merge.dev/logs/agent-handler/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](/merge-workforce/logs/api-requests). ## 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 `__`, 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](#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](/merge-workforce/logs/siem). The [API reference](/merge-agent-handler/agent-handler) 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. | Field | Where it comes from | What it groups | | ----------------- | -------------------------------------------------------------------------------------------- | -------------------------------------------------------- | | `client_trace_id` | The 32-hex trace id in the W3C `traceparent` header | Every request the client made while answering one prompt | | `turn_id` | `X-Merge-Turn-Id`, otherwise the `turn_id` inside Codex CLI's `x-codex-turn-metadata` header | One turn of the conversation | Both are read from the request headers rather than the payload, so they survive redaction, and both are opaque ids Workforce does not interpret. Claude Code sends the same `traceparent` trace id on every model request and every HTTP MCP tool call in a prompt, but only while its OpenTelemetry tracing is on with an `otlp` exporter and `CLAUDE_CODE_PROPAGATE_TRACEPARENT=1` is set; the [Workforce CLI](/merge-workforce/rollout/workforce-cli#following-a-prompt-across-both-logs) sets all of this with `mfw env`, and `mfw chat` sends an `X-Merge-Turn-Id` per prompt. Codex CLI sends its turn metadata on model requests only, not on `tools/call`, so for Codex the id appears on the LLM side alone. The parsing rules match Gateway's, so the same ids appear in the [LLM calls](/merge-workforce/logs/gateway) 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](/merge-workforce/security/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](/merge-workforce/tool-packs/tool-description-overrides) or a [tool input override](/merge-workforce/tool-packs/tool-input-overrides) 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](/merge-workforce/security/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](/merge-workforce/logs/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](/merge-agent-handler/observe/webhooks) to land them in your own warehouse, or [stream them to a SIEM](/merge-workforce/logs/siem). ## Next Read the raw provider exchange behind any of these calls in [API request logs](/merge-workforce/logs/api-requests).