Skip to main content
Glama

ActionDock

by app.actiondock
OverviewDiscussionsAdmin

Wait for job

wait_for_job
Read-onlyIdempotent

Wait for an action job to reach a decision or a final state: approved and executed, rejected, failed, or execution_unknown. A job still awaiting owner approval when the timeout elapses is returned as awaiting_approval; call again to keep waiting. Keep timeout_seconds below your client's tool timeout.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
job_idYesJob identifier returned by run_action.
timeout_secondsNoHow long to wait for a decision or final state before returning the current job; keep it below your client's tool timeout.

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault
idYesJob identifier.
errorYesFailure, execution_unknown or queued approval revocation explanation; null otherwise.
inputYesValidated action input exactly as submitted.
actionYesCatalog action name, for example integration.execute.
outputYesFor writes awaiting_approval or queued: the exact approval preview bound to the owner's decision. Rejected writes retain that preview, including after a queued approval is revoked. After succeeded: the action result. After execution_unknown: the approved write plus the ambiguous provider response when one was received. Other jobs may have a preserved preview or null.
statusYesawaiting_approval, queued, and running are non-terminal; succeeded, failed, rejected, and execution_unknown are terminal. An owner may revoke a queued approval, producing rejected with both approval and rejection evidence.
createdAtYesCreation time.
updatedAtYesLast status change.
approvedAtYes
approvedByYesOwner who approved the write.
rejectedAtYes
rejectedByYesOwner who rejected the write.
sideEffectYesTrue when the action writes to an external system and therefore required owner approval.
workflowIdYesCaller-supplied workflow identifier shared across related jobs.
workspaceIdYesWorkspace that owns the job.
workflowNameYesCaller-supplied workflow name shown in the dashboard.
idempotencyKeyYesIdempotency key that deduplicates this submission within the workspace.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed3 schema fields changed
    • changedOutput schema / properties / error / description
      Previous value: -"Failure or execution_unknown message; null otherwise."New value: +"Failure, execution_unknown or queued approval revocation explanation; null otherwise."
    • changedOutput schema / properties / output / description
      Previous value: -"While awaiting_approval: the exact approval preview bound to the owner's decision. After succeeded: the action result. After execution_unknown: the approved write plus the ambiguous provider response when one was received. Otherwise null."New value: +"For writes awaiting_approval or queued: the exact approval preview bound to the owner's decision. Rejected writes retain that preview, including after a queued approval is revoked. After succeeded: the action result. After execution_unknown: the approved write plus the ambiguous provider response when one was received. Other jobs may have a preserved preview or null."
    • changedOutput schema / properties / status / description
      Previous value: -"awaiting_approval, queued, and running are non-terminal; succeeded, failed, rejected, and execution_unknown are terminal."New value: +"awaiting_approval, queued, and running are non-terminal; succeeded, failed, rejected, and execution_unknown are terminal. An owner may revoke a queued approval, producing rejected with both approval and rejection evidence."
  2. Changed2 schema fields changed
    • addedInput schema / properties / job_id / description
      Added value: +"Job identifier returned by run_action."
    • addedInput schema / properties / timeout_seconds / description
      Added value: +"How long to wait for a decision or final state before returning the current job; keep it below your client's tool timeout."
  3. Changed1 schema field changed
    • changedInput schema / properties / timeout_seconds / maximum
      Previous value: -60New value: +300
  4. First observed

TDQS

A3.8/5.0
Behavior4/5

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

Annotations already declare readOnlyHint=true, idempotentHint=true, destructiveHint=false, and openWorldHint=false, so the safety profile is covered. The description adds valuable behavioral detail beyond annotations: it lists the terminal states and explains that a timeout returns awaiting_approval and that the caller should call again to keep waiting. It does not cover auth, rate limits, or error behavior.

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?

Three sentences, all front-loaded and purposeful. The purpose and terminal states come first, followed by timeout behavior and a practical caveat about client tool timeouts. No sentence is wasted.

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 the description need not explain return values, and annotations cover safety. It explains the waiting semantics, timeout behavior, and retry guidance well. The only notable gap is lack of explicit contrast with sibling get_job for when immediate retrieval is preferable.

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 both job_id and timeout_seconds fully. The description adds no parameter syntax or meaning beyond what the schema provides, making the baseline of 3 appropriate.

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?

The description states a specific verb and resource: waiting for an action job to reach a decision or final state. It enumerates the terminal states, making the tool's scope clear. However, it does not explicitly distinguish this tool from sibling get_job or run_action, which would help an agent route correctly.

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

Usage Guidelines3/5

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

Usage is implied: wait for a job to reach a final state, and call again if the timeout returns awaiting_approval. The description provides behavioral context for repeated calls but does not explicitly state when to use this instead of get_job or the other siblings, nor does it mention any prerequisites beyond what the schema already contains.

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

All ActionDock toolsInspect
Try in Browser
One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources