Respond to browser task
task_respondPerform one action from the current observation in the user's browser (click, type, select, press a key, navigate, scroll and similar; fill submit presses Enter after filling), resolve an uncertain effect, mark the task done, or report it blocked. Actions can change or submit data on websites; pauses follow current account-wide Permissions and immutable task confirmations, and an action whose effect is uncertain is never repeated automatically. BrowserPair dismisses page confirmation dialogs (outcome.dialogs); to answer a dismissed dialog OK, use acceptDialog: true only for the reported dialog and follow BrowserPair's approval decision; Developer mode with all questions off may handle dialogs automatically. Never replay an effect_unknown action. Downloads use download under current account-wide Permissions and immutable task confirmations: a blocked download is listed in outcome.downloads; repeat that action with allowDownload: true to ask the user. BrowserPair never returns file contents. To put a file into a page's file field (an element of kind file, or the button that opens the chooser), use kind upload with file; it uses file_upload under current account-wide Permissions; a user-picked file always waits for the user. When the task has several tabs, the observation lists them in task_tabs; use kind switch_tab with tabId to go back to one, or kind close_tab with tabId to close one this task opened (opened_by_task) that is not current. The observation's open_tabs lists tabs the user already has open on the task's sites (other_open_tabs counts the rest without naming them); use kind adopt_tab with one of those tabIds to work in it instead of opening a new tab. An adopted tab stays the user's: ending the task never closes it. For responsive QA, kind set_viewport with width/height uses viewport_control under current account-wide Permissions and changes only the task-owned tab viewport; BrowserPair resets it when control ends. To have the user do one step on the page (sign in, a CAPTCHA or code, a payment step) and then continue yourself, use kind user_step with a reason. For sign_in or verification you may name a structured method such as passkey, QR code, security key or device approval; BrowserPair asks the user in Chrome, never handles that secret/device factor itself, and returns a fresh observation when they press Continue. When the user should continue themselves (for example to review, sign in or pay), end with kind handoff and a summary: the current tab stays open in front of them and BrowserPair stops acting. Never invent refs that are not in task_state.
Tool call template
Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.
{
"id": 1,
"jsonrpc": "2.0",
"method": "tools/call",
"params": {
"arguments": {
"task_id": "<task_id>",
"interaction_generation": "<interaction_generation>",
"action": "<action>"
},
"name": "task_respond"
}
}Input Schema
| Name | Required | Description | Default |
|---|---|---|---|
| action | Yes | ||
| task_id | Yes | ||
| interaction_generation | Yes |