# Tools

Per-tool dashboard — call volume, run time, error rate, and the issues, satisfaction, and estimated token volume of the sessions that use each tool.

The **Tools** dashboard answers "which of my agent's tools is the problem?" Pick one tool and every chart rescopes to it.

## What it is

A single-tool view. The selector lists tools observed for the service, ranked by estimated token volume and capped at 300, opening on the heaviest.

## How it's populated

From tool-call spans your SDK or framework emits — no configuration needed, though a tool needs named, completed calls in the selected range to appear.

## How to read it in the dashboard

**Some charts measure the tool; others measure the sessions that used it.** This is the thing to get right here:

- **Call-level** — Call volume, Avg run time, Error rate, and Est. token breakdown count *this tool's own calls*. Error rate is the share of its calls that errored, not of affected sessions.
- **Session-scoped** — Top journeys, Issues, User satisfaction, Task completion, Task outcome, and Cache tokens measure *the sessions that used it*. A high issue count means co-occurrence, not causation.

The four sections:

- **Top issues & journeys** — the highest-*priority* issues in sessions using this tool (not the most strongly associated), plus a treemap of journeys sized by session count.
- **Usage & reliability** — Call volume, Avg run time, Error rate, and Issues over time. The last counts *distinct issues* at the bucket where they were first detected.
- **Quality** — User satisfaction, Task completion, and Task outcome for those sessions.
- **Token volume** — Input (call arguments), Output (the result), and Schema (the definition's size, assigned to each observed call on the assumption it's sent every time), plus cache tokens.

**Total vs per-session** divides by the sessions that used the tool — never your whole traffic. Numerators come from different clocks, so read it as a signal, not a precise ratio.

Global session filters and the time range apply to the charts. Change-event markers are the exception: they ignore session filters, so they line up a jump with a change without proving it caused one.

## How to act on it

1. **Look at schema volume first.** If your provider re-sends the definition each call, a verbose one is a fixed tax on every turn mentioning the tool.
2. **Read error rate against call volume.** The same rate matters far more on your busiest tool than on one called twice a day.
3. **Use per-session to separate growth from regression.** Rising calls *per session* means the agent reaches for it more often within a session — worth checking for a retry loop.
4. **Follow avg run time into latency.** A slower tool is a candidate cause for slower sessions, though parallel work means it won't always show end-to-end.
5. **Open the issues, don't just count them.** The panel is session-scoped, so confirm the tool is implicated first.

## Availability

On by default. If **Tools** isn't in your navigation, [contact us](mailto:support@brizz.ai).

## See also

- [Cost & usage](/docs/platform/cost.md) — actual spend, in money, across models.
- [Issues](/docs/platform/issues.md) — the full triage view for the issues surfaced here.
- [Latency & performance](/docs/platform/latency.md) — where a slow tool shows up end-to-end.