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.
// MCP tool call — server "twin-browser"
{
"tool": "get_monitor_history",
"arguments": {
"id": "…",
"limit": 50
}
}curl -X GET "https://twin-browser.com/api/v1/monitors/MONITOR_ID/history?limit=50" \
-H "Authorization: Bearer $TWIN_API_KEY"| Parameter | Type | What it does |
|---|---|---|
| id* | string | The monitor id. |
| limit | number | Max checks to return. Default 50, max 200. |
Returns
{ "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 cardWhich one
When a different tool is the right call.
The honest answer is often the neighbouring tool. These are the trades.
list_monitorsThe list is configuration; the history is behaviour. Diagnose from the history.
list_monitors