Skip to main content
Glama

dispatch_async

Run long tasks asynchronously beyond MCP timeouts by spawning a background job and returning a job_id for polling or webhook notification.

Instructions

Spawn a dispatch in the background, return a job_id immediately.

Use this for anything that may exceed the MCP transport's per-call ceiling (~60s in Cowork) — persona runs, refactors, anything in a busy project. The subprocess is spawned with its own session (start_new_session=True) and its stdout/stderr go to files on disk, so the work survives transport timeouts and bridge restarts.

Then poll with wait_dispatch(job_id) in a loop until status != 'running'.

Args mirror dispatch. Empty prompts return a structured error synchronously without creating a job.

Optional webhook notification (notify_url): The bridge POSTs a JSON payload to notify_url when the job reaches a terminal state matching notify_on. notify_on values: done, error, cancelled, abandoned. Default ["done"]. Delivery is fire-and-log — failures are recorded in the event log as webhook_failed but don't affect the job. Add auth via notify_headers.

Payload shape (truncated to 4KB on result_preview)::

{"event": "done", "job_id": "...", "channel": "...",
 "status": "done", "ok": true, "started_at": ...,
 "finished_at": ..., "result_preview": "...", "error": null}

Returns: Success: {ok: true, job_id, channel}. Validation failure: {ok: false, error}.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
promptYes
channelNodefault
timeout_secondsNo
permission_modeNo
cwdNo
notify_urlNo
notify_onNo
notify_headersNo
Behavior5/5

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

With no annotations provided, the description fully bears the burden of behavioral disclosure. It reveals that the subprocess runs with its own session, stdout/stderr go to disk, the job survives transport timeouts and bridge restarts, webhook delivery is fire-and-log, and empty prompts return a synchronous error without creating a job. This is comprehensive for a tool with no annotations.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is well-structured with paragraphs and a bullet-like section for webhook details. It front-loads the core purpose and proceeds logically. While slightly long, every sentence adds essential information, and the structure aids readability.

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?

Given 8 parameters, no output schema, and no annotations, the description is nearly complete. It covers return values (success and failure shapes), background behavior, survival, polling instructions, and webhook details. The only gap is that it relies on 'Args mirror dispatch' without explicitly listing all parameters, but the context is rich enough for an agent to use the tool correctly.

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?

The schema has 0% description coverage, so the description must compensate. It adds meaning for notification parameters (notify_url, notify_on, notify_headers) with details on payload and behavior, but it only says 'Args mirror dispatch' for the other 5 parameters, leaving them to the agent's knowledge of the sibling tool. This partial compensation is adequate but not fully comprehensive.

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 explicitly states that the tool spawns a background dispatch and returns a job_id immediately. It distinguishes itself from siblings like dispatch (synchronous) and wait_dispatch (polling) by focusing on long-running tasks that exceed MCP transport limits.

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

Usage Guidelines4/5

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

The description provides clear guidance: 'Use this for anything that may exceed the MCP transport's per-call ceiling (~60s in Cowork) — persona runs, refactors, anything in a busy project.' It also instructs to poll with wait_dispatch. However, it does not explicitly state when not to use it or list alternatives.

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/JosiahSiegel/claude-bridge'

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