ActionDock

Submit action job

run_action

Destructive

Create an action job. External writes always wait for workspace-owner approval in the dashboard; the owner is emailed, and wait_for_job blocks until the decision.

Input Schema

TableJSON Schema

Name	Required	Description
`input`	No	Action input matching the schema advertised by list_actions.
`action`	Yes	Catalog action name from list_actions, for example integration.execute.
`workflow_id`	No	Stable identifier of the agent workflow this job belongs to, for grouping events.
`workflow_name`	No	Human-readable workflow name shown to the workspace owner during review.
`idempotency_key`	No	Caller-chosen key; resubmitting the same key and input returns the existing job instead of creating another.

Output Schema

TableJSON Schema

Name	Required	Description
`id`	Yes	Job identifier.
`error`	Yes	Failure, execution_unknown or queued approval revocation explanation; null otherwise.
`input`	Yes	Validated action input exactly as submitted.
`action`	Yes	Catalog action name, for example integration.execute.
`output`	Yes	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.
`status`	Yes	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.
`createdAt`	Yes	Creation time.
`updatedAt`	Yes	Last status change.
`approvedAt`	Yes
`approvedBy`	Yes	Owner who approved the write.
`rejectedAt`	Yes
`rejectedBy`	Yes	Owner who rejected the write.
`sideEffect`	Yes	True when the action writes to an external system and therefore required owner approval.
`workflowId`	Yes	Caller-supplied workflow identifier shared across related jobs.
`workspaceId`	Yes	Workspace that owns the job.
`workflowName`	Yes	Caller-supplied workflow name shown in the dashboard.
`idempotencyKey`	Yes	Idempotency key that deduplicates this submission within the workspace.

Schema Changelog

Changes observed during successful MCP inspections.

Changed3 schema fields changedSep 28, 2026

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."

Changed5 schema fields changedSep 20, 2026

addedInput schema / properties / action / description

Added value: +"Catalog action name from list_actions, for example integration.execute."

addedInput schema / properties / idempotency_key / description

Added value: +"Caller-chosen key; resubmitting the same key and input returns the existing job instead of creating another."

addedInput schema / properties / input / description

Added value: +"Action input matching the schema advertised by list_actions."

addedInput schema / properties / workflow_id / description

Added value: +"Stable identifier of the agent workflow this job belongs to, for grouping events."

addedInput schema / properties / workflow_name / description

Added value: +"Human-readable workflow name shown to the workspace owner during review."

First observedSep 20, 2026

TDQS

A3.8/5.0

Behavior4/5

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

Annotations already declare destructiveHint=true and openWorldHint=true, but the description adds meaningful context beyond them: external writes require workspace-owner approval in the dashboard, the owner is emailed, and wait_for_job blocks until the decision. It still does not clarify irreversibility or failure behavior of the external write itself.

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?

Two tightly packed sentences with the core purpose front-loaded and the approval/blocking behavior following immediately. No filler text.

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?

With an output schema present, return details need not be explained, and the approval flow is covered well. Minor gap: no note on what happens if approval is denied or how long the job persists.

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 fully documents action, input, workflow_id, workflow_name, and idempotency_key. The description adds no parameter-level detail beyond that baseline, so a 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+resource ('Create an action job') and names the related sibling wait_for_job, so an agent can distinguish it from get_job/list_jobs style siblings. It does not, however, describe what an 'action' is beyond the schema's reference to list_actions.

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?

The description implies when this tool is invoked (submitting an action) and points at wait_for_job as the blocking companion, which is useful routing. But it gives no explicit when-not-to-use guidance or comparison against siblings like get_job or list_actions.

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

All ActionDock tools Inspect

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

Need Help?