Sessions & HITL
Clear a warning once you have dealt with it
Dismiss one warning by the `id` list_warnings gave you. It drops off the default open list; a later failure on the same login raises a fresh one.
acknowledge_warning
What it is
The job: Close the loop after fixing what a warning named — a missing secret now stored, or a fresh session captured.
list_warnings and acknowledge_warning are a pair: one surfaces a broken login, the other clears it once you have actually fixed it — stored the missing secret with a secrets call, or sent the user through connect_account to recapture the session. The row is not deleted, only marked acknowledged, so pass `all:true` on list_warnings to still see the history.
Acknowledging does not prevent the warning from coming back. If the same account fails its login again, a fresh open row is raised — acknowledge_warning closes one incident, it does not silence the identity.
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": "acknowledge_warning",
"arguments": {
"id": "…"
}
}curl -X POST https://twin-browser.com/api/v1/warnings/WARNING_ID/ack \
-H "Authorization: Bearer $TWIN_API_KEY" \
-H "content-type: application/json"| Parameter | Type | What it does |
|---|---|---|
| id* | string | The warning id, from list_warnings. |
Returns
{ "id": "…", "acknowledged": true }Which one
When a different tool is the right call.
The honest answer is often the neighbouring tool. These are the trades.
Keep going