> ## Documentation Index
> Fetch the complete documentation index at: https://docs.getmcpulse.com/llms.txt
> Use this file to discover all available pages before exploring further.

# Calls

> How many times your tools ran: per tool, per day, and across the whole server.

A **call** is one `tools/call` request handled by your server. It is counted whatever the outcome — a crash is still a call.

## Where it appears

|                         |                                                                            |
| ----------------------- | -------------------------------------------------------------------------- |
| **Total calls** card    | Every call in range, with a delta against the previous window              |
| **Calls per day** chart | One point per bucket in range, stacked by outcome                          |
| **Tool health** table   | Calls per tool, sorted descending                                          |
| **Clients** panel       | Calls per model                                                            |
| **MCP list**            | Calls in the last 30 days, per MCP — the same window the overview opens on |

## Per day, or per hour

The chart is **gap-filled**: every bucket in the range gets a point, so a quiet day plots as zero instead of vanishing and making the line look continuous when it is not.

Ask for a single day and the grain becomes the **hour** — twenty-four points rather than one, which is the only way a one-day window is a line at all. Anything wider stays daily. The API decides this and sends `granularity` beside the series.

It comes from `tool_hours` whether a filter is on or not, so a filtered series and an unfiltered one cannot disagree about a day. There is no second table holding the same totals at a coarser grain, which is how two tables come to disagree.

## Stacked by outcome

One series could not say whether a spike was traffic or crashes, so the bars are stacked: **ok**, **empty**, and **failed** — with the first-call rate on a right axis as a dashed line that breaks where the [nightly pass](/api/concepts/nightly-pass) has not reached.

Three bands, not five. There are three outcome hues in the palette and no fourth a reader could tell from the others; three shades of one red says *these differ* while giving nobody a way to know which is which. So colour groups the failures and the **tooltip separates them** — `bad_args`, `tool_errors` and `crashes` are sent per bucket beside the `errors` band, and a row appears only when it happened.

## Buckets are UTC

Ingest buckets a call into an hour with `date_trunc('hour', started_at at time zone 'utc')`, and every read uses the same clock. A call at 23:50 UTC belongs to that day, not to the next one in your timezone. Hourly labels on the chart are UTC for the same reason.

The one place local time is used is the [live call feed](/metrics/live-calls), and deliberately: a call is a moment, a bucket is not.

The `timezone` on your [company profile](/company/profile) is display only. Nothing reads it into a query.

## Retries are calls

A model that calls `search_orders`, gets nothing useful, rewords and calls again has made **two calls**. Both are counted here.

That is the point: the gap between calls and [first-call success](/metrics/first-call-success) is the work your tool descriptions are making the model do.

## Why totals can lag by seconds

The SDK buffers and flushes every 5 seconds or 30 calls, and ingest replies `202` before writing. A call made a moment ago may not be visible yet. Nothing else lags — only [retries, first-call success and tool pairs](/api/concepts/nightly-pass) wait for the nightly pass.

## Related

* [Sessions](/metrics/sessions) — calls grouped by conversation
* [Outcomes](/metrics/outcomes) — how those calls ended
* [Clients](/metrics/clients) — which client made them