Skip to main content
Glama

pmux_agent_turn

Send a prompt to an agent, poll for completion evidence, and return the recovered response. Retries transient busy/starting states and uses fallback on timeout.

Instructions

Primary agent orchestration tool for one full turn: send a prompt, poll for completion evidence, then return the recovered response. Safe to call immediately after a previous turn; transient pre-send busy/starting states are retried within the same pollTimeoutMs budget. Use pmux_agent_capture with the returned marker to resume after timeout; use pmux_send_input/pmux_capture_pane only as low-level fallbacks. Completion evidence from a valid report file or pane markers wins over readiness/runtime-error signals. Without completion evidence, ready plus runtimeError returns status:"agent_error".

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
turnYesCaller-owned turn number. turn=0 is recommended for bootstrap.
tabIdYesTarget tab id (from pmux_list_tabs / pmux_create_tab).
pollMsNoPolling interval in ms after a successful send. Defaults to 2000; minimum 500.
promptYesPrompt body to send before the standard PMUX sentinel footer.
agentIdYesCaller-owned agent id: ^[a-z0-9][a-z0-9_-]{0,31}$.
providerYesProvider used for readiness/busy checks: codex or claude.
requestIdNoOptional caller-owned request id using the same format as agentId.
fileOutputNoDefaults to true. true writes response content to the v2.1 report file; false uses pane BEGIN/END fallback.
busyPatternNobusyPattern regex override. Max 200 chars; compile errors become ToolError.
workspaceIdYesTarget workspace id (from pmux_list_workspaces).
errorPatternNoerrorPattern regex override. Max 200 chars; compile errors become ToolError.
readyPatternNoreadyPattern regex override. Max 200 chars; compile errors become ToolError.
pollTimeoutMsNoTotal polling timeout in ms after a successful send. Defaults to 120000; max 300000.
skipReadyCheckNoSkip prompt-readiness gating, but still reject launch/error patterns.
maxResponseLinesNoLine limit inserted into the sentinel footer. Defaults to 40.
expectPrevTurnEndNoIf set, the pane must contain the previous turn's completion marker before sending. For fileOutput=true turns, pair this with expectPrevRequestId.
expectPrevRequestIdNoOptional previous turn request id. Use with expectPrevTurnEnd for fileOutput=true prior-turn validation.
runtimeErrorPatternNoruntimeErrorPattern regex override. Max 200 chars; compile errors become ToolError.
Behavior4/5

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

No annotations provided, so description carries full burden. It discloses polling timeout, retry logic, priority of completion evidence, and error status. However, it does not explicitly state that sending input mutates state or that it is destructive.

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?

Description is front-loaded with purpose and usage, then adds behavioral details. All sentences are valuable but could be slightly more streamlined. No redundancy.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness3/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the complexity (18 params, no output schema), the description covers purpose, usage, and many behaviors. However, it lacks detail on the return structure beyond mentioning 'recovered response' and a specific error status. Without an output schema, the agent would benefit from more explicit return description.

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 coverage is 100%, so baseline is 3. Description briefly mentions key parameters (pollTimeoutMs, fileOutput) but does not add significant new semantics beyond summarizing their roles. Schema already documents each parameter well.

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?

Description clearly states it is the primary tool for a full agent turn: sending a prompt, polling for completion, and returning the response. It distinguishes from siblings like pmux_agent_capture, pmux_send_input, and pmux_capture_pane by positioning them as fallbacks.

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

Usage Guidelines5/5

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

Explicitly states when to use (immediately after previous turn, retrying transient states) and when not to (after timeout use pmux_agent_capture, low-level fallbacks only as fallback). Provides clear 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/yoway030/purplemux-mcp'

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