Skip to main content
Glama
Sign In
luftpause

luftpause

by luftpause
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Hybrid

run

Launch a sub-agent and wait until it finishes in one call, returning the result and handling approval requests or task polling for MCP clients.

Instructions

Spawn a sub-agent run and wait in the same call until it finishes; takes the same arguments as spawn and returns the run as await does. Clients that opt into MCP Tasks get a task to poll instead, and an approval inside the run arrives as the task's input request. Other clients are asked approvals the way await asks them; without elicitation the call returns the run with status AwaitingApproval. Cancelling the call cancels the run.

Input Schema

NameRequiredDescriptionDefault
taskYesWhat the sub-agent should do.
modelNoModel to run on; defaults to the runtime's model.
toolsNoNames of the tools this run may use; all configured tools when omitted.
parentNoHandle of the run this one belongs to; cancelling the parent cancels it.
systemNoOptional system prompt for the sub-agent.
maxTokensNoLongest reply per model turn, in tokens; 0 leaves it to the engine. Engines that reserve memory per request (SGLang) batch far fewer requests without it.
approveToolsNoTools whose every call waits for the user's approval, on top of tools their server marks destructive.
budgetTokensNoPrompt plus completion tokens this run and every run under it may use; over it, the subtree is cancelled.
maxToolCallsNoTool calls allowed before the sub-agent must answer without tools.
serviceClassNointeractive (default) or batch. Batch runs yield to interactive ones.interactive
budgetSecondsNoWall-clock seconds this run may take, its subtree included; when they pass, the subtree is cancelled.
budgetToolCallsNoTool calls this run and every run under it may make; over it, the subtree is cancelled.
parallelToolCallsNoLet the model ask for several tool calls in one reply, run at once. Off by default: Llama 3.x takes one call per reply.

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.1.3

TDQS

A4.1/5.0
Behavior4/5

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

The annotations only cover openWorldHint/idempotentHint/destructiveHint, so the description carries the interesting burden and does so well: blocking semantics, cancellation propagation ('cancelling the call cancels the run'), and the fallback behavior of returning status AwaitingApproval when elicitation is unavailable. It leaves the shape of the returned run object implicit by deferring to await.

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?

Dense but front-loaded: the primary action and blocking behavior lead, followed by the Tasks-client variant, the approval path, and cancellation. Every clause carries distinct operational information, though the middle sentences pack three separate client-behavior branches into a single paragraph.

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 13-parameter orchestration tool with no output schema and thin annotations, the description covers the hard parts an agent would otherwise get wrong — that the call blocks, that cancellation propagates, and that approval may surface as either an input request or an AwaitingApproval status. The composition of the returned run is left to the await sibling rather than spelled out.

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% across all 13 parameters, so the schema does the heavy lifting for task, model, tools, budgets, and serviceClass. The description adds nothing parameter-specific beyond 'takes the same arguments as spawn', which is the correct baseline when the schema is fully documented.

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?

States a specific compound action — spawn a sub-agent run and block until it finishes — and immediately positions it against siblings by noting it takes spawn's arguments and returns what await returns. An agent can tell this apart from spawn and await without opening any schema.

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?

Clearly frames this as the combined spawn+wait path and explains that MCP-Tasks-opted clients instead get a pollable task, which is real routing guidance. It stops short of explicitly telling the agent when to prefer bare spawn (fire-and-forget) or await over this call.

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

Deploy Server

Other Tools