Skip to main content
Glama

Wait for jobs

wait_for_jobs
Read-onlyIdempotent

Waits up to timeoutSeconds for generation jobs to finish, then answers once with each job's state (the fields get_job returns), a summary and the finished images as pictures. Jobs take 1-5 minutes. Use it when no job panel shows: pass every jobId you are waiting on, tell the user the work is under way between calls, and call it again with the jobs still running until allFinal is true. Show finished creatives with show_creatives. An id that is not found answers for itself without failing the others.

Input Schema

NameRequiredDescriptionDefault
jobIdsYesThe jobIds the generation tools returned (generate_design returns one per concept, generate_image one per entry in images).
brandIdNoOptional: the brand it belongs to, by id or name. Read from the id when omitted.
timeoutSecondsNoHow long to wait for every job to be final. Defaults to 15; 0 reads them at once.

Output Schema

NameRequiredDescriptionDefault
jobsYes
nextYes
mediaYes
summaryYesJobs by status; failed includes rejected, errors counts ids that were not found.
allFinalYes

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed3 schema fields changed
    • changedInput schema / properties / brandId / description
      Previous value: -"Optional: the brand it belongs to. Read from the id when omitted."New value: +"Optional: the brand it belongs to, by id or name. Read from the id when omitted."
    • changedInput schema / properties / jobIds / description
      Previous value: -"The jobIds the generation tools returned (generate_design returns one per concept)."New value: +"The jobIds the generation tools returned (generate_design returns one per concept, generate_image one per entry in images)."
    • addedOutput schema / properties / media / items / properties / previewUrl
      Added value: +{
      +  "description": "A small WebP of it to look at; url is the full size to hand over.",
      +  "type": "string"
      +}
  2. First observed

TDQS

A4.7/5.0
Behavior5/5

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

Beyond the readOnly and idempotent annotations, the description discloses operational behavior: jobs take 1-5 minutes, the call answers once after waiting, repeated calls are needed until allFinal, and an unknown id fails only for itself. These are meaningful traits an agent needs before invoking it.

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 purpose is front-loaded in the first sentence, followed by practical timing, usage, display, and error-isolation details. Each sentence contributes useful information without waste.

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 annotations, a fully described input schema, and an output schema, the description supplies the remaining operational context: timing expectations, polling loop, partial failure behavior, and when to use show_creatives. Nothing important for correct invocation is missing.

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 description coverage is 100%, so the schema already documents jobIds, brandId, and timeoutSeconds. The description reinforces jobIds and timeoutSeconds but does not add much beyond the schema and omits brandId, so baseline 3 applies.

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 states a specific verb and resource: wait up to timeoutSeconds for generation jobs to finish, then answer with each job's state, summary, and images. It also positions the tool relative to get_job and show_creatives, so an agent can distinguish its role from those siblings.

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?

It gives explicit usage guidance: use when no job panel shows, pass every jobId being waited on, tell the user work is under way between calls, and call again until allFinal is true. It also names show_creatives for displaying finished creatives.

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