WebRun Browser Automation

Get task status

get_task_status

Read-onlyIdempotent

Check the status of a task previously started in a browser session. Use to poll for completion or detect guardrails. Read-only: reports on the task without affecting it.

Input Schema

Name	Required	Description	Default
`taskId`	Yes	Task ID to check
`sessionId`	Yes	Session ID

Output Schema

Name	Required	Description
`data`	No	Task output payload when completed (instance-authored shape)
`type`	No	Raw result type when the task finished
`status`	Yes	Task/session state: 'completed', 'failed', 'awaiting_input', 'pending', 'active', 'paused', 'orphaned', or 'not_found'
`taskId`	No
`message`	No
`sessionId`	No
`liveViewURL`	No	Page for watching the run live, present while it is still running or awaiting input. The only URL here that is safe to show a user or open in a browser.

Schema Changelog

Changes observed during successful MCP inspections.

Changed1 schema field changedAug 26, 2026

addedOutput schema / properties / liveViewURL

Added value: +{
+  "description": "Page for watching the run live, present while it is still running or awaiting input. The only URL here that is safe to show a user or open in a browser.",
+  "type": "string"
+}

Changed1 schema field changedAug 8, 2026

changedOutput schema / (root)

Previous value: -nullNew value: +{
+  "additionalProperties": true,
+  "properties": {
+    "data": {
+      "additionalProperties": true,
+      "description": "Task output payload when completed (instance-authored shape)",
+      "type": "object"
+    },
+    "message": {
+      "type": "string"
+    },
+    "sessionId": {
+      "type": "string"
+    },
+    "status": {
+      "description": "Task/session state: 'completed', 'failed', 'awaiting_input', 'pending', 'active', 'paused', 'orphaned', or 'not_found'",
+      "type": "string"
+    },
+    "taskId": {
+      "type": "string"
+    },
+    "type": {
+      "description": "Raw result type when the task finished",
+      "type": "string"
+    }
+  },
+  "required": [
+    "status"
+  ],
+  "type": "object"
+}

First observedAug 8, 2026

TDQS

A3.6/5.0

Behavior3/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

The description's 'Read-only: reports on the task without affecting it' largely restates the readOnlyHint/destructiveHint annotations already provided. It does add genuinely new behavioral context — that the tool is meant for polling and that a guardrail state may surface (pointing toward guardrail_response) — but does not cover polling frequency, terminal states, or auth needs.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Three short sentences with the purpose front-loaded and no filler. The final read-only sentence is mildly redundant with the annotations, which keeps it from a 5.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

An output schema exists, so return-value/state enumeration is not the description's burden, and the essential prerequisite (a previously started task in a session) plus the polling intent are covered. Minor gaps remain around polling cadence and terminal state handling.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100% and both parameters are named and described in the schema, so the baseline is 3. The description only indirectly links sessionId to a browser session ('started in a browser session') and adds no format or ID-provenance detail beyond the schema.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb+resource ('Check the status of a task') and scopes it to a task 'previously started in a browser session', which separates it from generic session tools. It does not explicitly name the sibling it differs from (e.g., guardrail_response, pause_session_task), so it falls short of full sibling differentiation.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Gives concrete usage context: 'Use to poll for completion or detect guardrails', which tells the agent when this tool is the right call. It stops short of naming alternatives or stating exclusions, so it is clear context without routing guidance.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

All WebRun Browser Automation tools Inspect

Try in Browser

Let your AI agent see the webWeb-to-screenshot MCP for Claude, Cursor and Codex. No cookie banners. Free to start.snap-render.comAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources

Need Help?