Skip to main content
Glama

ActionDock

by app.actiondock
OverviewDiscussionsAdmin

Get job

get_job
Read-onlyIdempotent

Get the current status and result of an action job.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
job_idYesJob identifier returned by run_action.

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. Changed1 schema field changed
    • addedInput schema / properties / job_id / description
      Added value: +"Job identifier returned by run_action."
  3. First observed

TDQS

B3.4/5.0
Behavior3/5

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

Annotations already declare readOnlyHint, idempotentHint, destructiveHint=false, and openWorldHint=false, so the safety profile is fully covered. The description adds only that it returns both status and result, which is useful but minimal beyond the structured fields.

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?

A single front-loaded sentence with no filler; every word carries information about what is retrieved.

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?

For a one-parameter read tool with full annotations and an output schema, the definition is nearly sufficient—return values need not be explained and the job_id origin is documented in the schema. The only real gap is the missing polling-vs-waiting routing against wait_for_job.

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%, and the schema itself even documents that job_id comes from run_action, so the description has no compensating work to do. Baseline 3 is 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?

States a specific verb (get) and resource (status and result of an action job), which is more precise than the bare title 'Get job'. It does not, however, distinguish itself from the closely related sibling wait_for_job, which an agent would also consider when retrieving job results.

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

Usage Guidelines2/5

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

There is no explicit guidance on when to use this tool versus wait_for_job or list_job_reconciliations. The phrase 'current status' hints at a non-blocking poll, but the choice between polling and waiting is left entirely to inference.

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