Skip to main content
Glama

Check batch progress

get_batch
Read-onlyIdempotent

Returns one batch's status with its total, completed, failed and processing job counts. Rendering after run_batch happens in the background, so call it again until processing reaches 0. An unknown batchId, or one from another workspace, returns Batch not found. For many batches at once use list_batches; for per-job values and render errors get_batch_jobs; for download URLs get_batch_outputs. Needs batches:read.

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": {
      "batchId": "<batchId>"
    },
    "name": "get_batch"
  }
}

Input Schema

NameRequiredDescriptionDefault
batchIdYesBatch ID returned by create_batch or list_batches

Output Schema

NameRequiredDescriptionDefault
idYes
nameYes
totalYesJobs in the batch
failedYesJobs that failed
statusYesprocessing while any job renders; pending while jobs wait for run_batch; once every job has finished: completed when all rendered, partial when some rendered and others failed or were cancelled, failed when none rendered and at least one failed, cancelled when none rendered, none failed and at least one was cancelled. The counts carry the detail
cancelledNoJobs cancelled
completedYesJobs rendered
createdAtYesCreation time, ISO 8601
processingYesJobs rendering now
workspaceIdYes

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed8 schema fields changed
    • removedInput schema / additionalProperties
      Removed value: -false
    • addedInput schema / properties / batchId / pattern
      Added value: +"^([0-9a-fA-F]{8}-[0-9a-fA-F]{4}-[0-9a-fA-F]{4}-[0-9a-fA-F]{4}-[0-9a-fA-F]{12})$"
    • addedOutput schema / properties / cancelled / maximum
      Added value: +9007199254740991
    • addedOutput schema / properties / completed / maximum
      Added value: +9007199254740991
    • addedOutput schema / properties / failed / maximum
      Added value: +9007199254740991
    • addedOutput schema / properties / id / pattern
      Added value: +"^([0-9a-fA-F]{8}-[0-9a-fA-F]{4}-[0-9a-fA-F]{4}-[0-9a-fA-F]{4}-[0-9a-fA-F]{12})$"
    • addedOutput schema / properties / processing / maximum
      Added value: +9007199254740991
    • addedOutput schema / properties / total / maximum
      Added value: +9007199254740991
  2. First observed

TDQS

A4.7/5.0
Behavior4/5

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

Annotations already declare readOnly, idempotent and non-destructive, and the description adds genuinely new behavior: the asynchronous render/polling loop, the error contract ('Batch not found' for unknown or cross-workspace IDs), and the required scope (batches:read). Only a note on throttling/rate limits is missing, so it falls just short of the top.

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

Conciseness5/5

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

Four tight sentences, front-loaded with the return shape, then the polling rule, then the error contract, then sibling routing. No repetition of annotations or schema, and every sentence carries actionable information.

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?

For a single-parameter read tool with an output schema, the description covers everything an agent needs: what comes back, that polling is required, what the auth scope is, and how unknown IDs fail. Return-value detail is correctly deferred to the output schema.

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% and already documents batchId with format and origin, so the baseline is 3; the description adds meaning beyond the schema by explaining that a batchId from another workspace fails with 'Batch not found', clarifying the ID's workspace scoping.

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 ('Returns one batch's status') plus the exact fields returned (total, completed, failed, processing counts), and explicitly distinguishes itself from list_batches, get_batch_jobs and get_batch_outputs. An agent can pick this tool over its siblings without opening any schema.

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?

Gives concrete usage guidance: poll repeatedly 'until processing reaches 0' because rendering runs in the background, and names three alternatives with the conditions that select them (many batches, per-job values, download URLs). Both when-to-use and when-not-to-use are covered.

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

Try in Browser

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources