Monitors

See every check, not just the ones that fired

A monitor’s recent checks with their outcome — changed, unchanged or error — and an excerpt of the value each one read.

get_monitor_history

What it is

The job: Tell the difference between “nothing changed” and “the check has been broken for a week”.

A monitor that never fires looks identical, from the outside, to a monitor whose selector stopped matching two hundred checks ago. History is what tells them apart: each check is recorded as changed, unchanged or error, with an excerpt of the value that was read.

It is the first thing to look at when a monitor has gone quiet, and the honest way to verify a new monitor before you rely on it — run it a few times and look at what it is actually reading.

The call

Call it exactly like this.

Copied from the tool's registration and the route handler — not paraphrased.

MCPget_monitor_history.mcp.jsonjson
// MCP tool call — server "twin-browser"
{
  "tool": "get_monitor_history",
  "arguments": {
    "id": "…",
    "limit": 50
  }
}
GET /api/v1/monitors/{id}/historyrequest.shbash
curl -X GET "https://twin-browser.com/api/v1/monitors/MONITOR_ID/history?limit=50" \
  -H "Authorization: Bearer $TWIN_API_KEY"
Parameters accepted by get_monitor_history
ParameterTypeWhat it does
id*stringThe monitor id.
limitnumberMax checks to return. Default 50, max 200.

Returns

response.jsonjson
{ "checks": [ { "checked_at": "…", "outcome": "unchanged",
                 "value_excerpt": "…", "error": null } ] }

What it costs

Free

Reading history costs nothing. The checks it describes were billed when they ran.

See the full rate card

Which one

When a different tool is the right call.

The honest answer is often the neighbouring tool. These are the trades.

list_monitors

The list is configuration; the history is behaviour. Diagnose from the history.

list_monitors