Skip to main content
Glama

get_job

Find out if a specific background operation is pending, running, or completed by supplying its operation ID. Use wait mode to block until it finishes.

Instructions

To check whether ONE specific operation you started is finished, pending, or failed, call this with its operationId (the pollUrl param accepts a bare operationId + brandId). Do NOT use list_operations to check a specific op. Poll the status of any background Operation by its operationId or pollUrl. Returns the Operation row: { id, kind, state (pending|running|completed|partially_failed|failed|cancelled), brandId, scopeType, scopeId, progress, result, errors, startedAt, finishedAt, createdAt, updatedAt }. Call repeatedly until state is 'completed' or 'failed' (or 'cancelled'). When completed, the payload you want is in result; on failure, see errors. Pass wait:true to block until the job is done (polls every 3s, capped at ~30s per call) — preferred over calling repeatedly. For longer-running jobs, call get_job again with wait:true to keep polling until it completes. Most generate_* and vibe_edit_* tools (including seo_generate_clusters and seo_generate_keywords) return an operationId — use this to poll them. Supports detail param: short=id+kind+state+progress, medium=adds timestamps+resultRef (key IDs from result, no full payload), full=raw including complete result JSONB.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
waitNoBlock and poll until the job reaches a terminal state (completed/failed/partially_failed/cancelled) or the wait window elapses. Polls every 3s. Use this instead of calling get_job repeatedly yourself.
detailNoVerbosity of returned item(s): "short" = id + primary label + status (cheap list scan); "medium" = key summary fields + counts (a useful glance); "full" = the complete object. Default "full". Lists default to "short" — to zoom into one item, call its get/view tool with detail="medium" or "full".full
brandIdNoBrand ID — required if pollUrl is a bare operationId
pollUrlYesFull poll URL returned by an async tool, OR a bare operationId (plus brandId param).
maxWaitSecondsNoRequested wait window in seconds, clamped to a hard cap of 30s (default ~30s) regardless of the value passed — the remote gateway kills longer-blocking calls. Only applies when wait=true. For longer operations, call get_job again with wait:true to keep polling.
Behavior5/5

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

With no annotations, the description fully discloses behavior: return fields, possible states, wait polling interval, maxWaitSeconds clamping, result/errors semantics, and detail levels. It explains the outcome on completion versus failure and the need for re-polling long jobs.

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?

The description is long but information-dense, with a clear structure: primary use, prohibition, return shape, polling guidance, waiting behavior, and parameter details. Every sentence contributes necessary 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 5-param tool with no output schema, this description is remarkably complete. It explains the return structure, state transitions, error handling, parameter semantics, and usage context, leaving little room for ambiguity.

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 covers all params with descriptions, but the description adds value by elaborating detail levels (short/medium/full exact fields), the wait polling cadence, and how pollUrl can be a bare operationId with brandId. This goes beyond the schema, though some information is already present.

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?

The description clearly states the tool checks the status of ONE specific operation by operationId or pollUrl, explicitly distinguishing it from list_operations. It names the resource (an Operation row) and the verb (poll/check), making it unambiguous.

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 instructs when to use (to check a single operation) and when not to (don't use list_operations for specific ops). It also provides guidance on using wait:true instead of repeated polling, and which tools return operationIds, making it easy to select.

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

Install Server

Other Tools

Latest Blog Posts

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/bitsandtea/postking-mcp'

If you have feedback or need assistance with the MCP directory API, please join our Discord server