Skip to main content
Glama
Sign In

zenrows-mcp

by io.github.ZenRows
OverviewDiscussionsAdmin

batch_results

Read-only

List a Batch run's result rows, a page at a time: up to limit rows (default 100, max 1000) and next_cursor. Pass next_cursor back as cursor to continue; it is null once every row was read.

Each row has task_id, external_id, url, metadata, status (successful, failed, pending, processing, expired), type, result_url when successful, and error when failed. A result_url is presigned and expires after 2 hours: call batch_results again for a fresh one, or read the body with batch_content. Results are kept 14 days by default; after that a successful row reads as status "expired", with no result_url, and batch_content answers BATCH_RESULT_EXPIRED.

Filter with status: all (default), successful, failed, or processing (not finished yet). A sparse filter can return fewer rows than limit with next_cursor still set: keep paging. While the run is still running or writing its tasks, the list is partial.

Input Schema

NameRequiredDescriptionDefault
limitNoMax rows to return (default 100, max 1000)
cursorNonext_cursor from a previous batch_results call
job_idYesBatch job id returned by batch_create or batch_list
run_idNoAn earlier run's id (from batch_status or batch_rerun). Default: the job's latest run.
statusNoFilter rows by status (default all). processing = tasks not finished yet. successful also returns expired rows.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed7 schema fields changed
    • addedInput schema / properties / cursor
      Added value: +{
+  "description": "next_cursor from a previous batch_results call",
+  "type": [
+    "string",
+    "null"
+  ]
+}
    • changedInput schema / properties / job_id / description
      Previous value: -"Batch job id"New value: +"Batch job id returned by batch_create or batch_list"
    • addedInput schema / properties / job_id / minLength
      Added value: +1
    • addedInput schema / properties / limit
      Added value: +{
+  "anyOf": [
+    {
+      "maximum": 1000,
+      "minimum": 1,
+      "type": "integer"
+    },
+    {
+      "type": "null"
+    }
+  ],
+  "description": "Max rows to return (default 100, max 1000)"
+}
    • addedInput schema / properties / run_id
      Added value: +{
+  "anyOf": [
+    {
+      "minLength": 1,
+      "type": "string"
+    },
+    {
+      "type": "null"
+    }
+  ],
+  "description": "An earlier run's id (from batch_status or batch_rerun). Default: the job's latest run."
+}
    • changedInput schema / properties / status / anyOf
      Previous value: -[
-  {
-    "enum": [
-      "successful",
-      "failed",
-      "all"
-    ],
-    "type": "string"
-  },
-  {
-    "type": "null"
-  }
-]New value: +[
+  {
+    "enum": [
+      "successful",
+      "failed",
+      "processing",
+      "all"
+    ],
+    "type": "string"
+  },
+  {
+    "type": "null"
+  }
+]
    • changedInput schema / properties / status / description
      Previous value: -"Filter results by status (default: all)"New value: +"Filter rows by status (default all). processing = tasks not finished yet. successful also returns expired rows."
  2. First observed

TDQS

A4.8/5.0
Behavior5/5

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

Goes well beyond the readOnly/openWorld/destructive annotations: presigned result_url expiry (2 hours), 14-day retention, expired-row behavior, the BATCH_RESULT_EXPIRED error from batch_content, and partial lists while the run is still writing. This is exactly the operational context an agent 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?

Dense and front-loaded, with the paging mechanics first and return-shape second. Minor redundancy with the schema on limit defaults and the status enum, but every sentence is otherwise load-bearing.

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

Completeness5/5

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

With no output schema, the description carries the full burden of describing return values and does so thoroughly (task_id, external_id, url, metadata, status, type, result_url, error). Nothing needed to call it correctly is missing.

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

Parameters4/5

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

Schema coverage is 100%, so the baseline is 3, but the description adds cross-parameter behavior beyond the schema: status filter semantics (processing = not finished, successful includes expired) and the warning that a sparse filter can return fewer rows than limit with next_cursor still set.

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

Purpose5/5

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

States a specific verb and resource ('List a Batch run's result rows, a page at a time') and scopes it clearly. An agent can immediately distinguish it from batch_content (reads a body) and batch_status (run state) without opening schemas.

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

Usage Guidelines5/5

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

Explicitly routes to alternatives with conditions: 'call batch_results again for a fresh one, or read the body with batch_content,' and explains the cursor continuation loop and the status filter options. The paging guidance ('keep paging' on sparse filters) removes inference.

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

All zenrows-mcp toolsInspect
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