Skip to main content
Glama

pmux_agent_send

Send a prompt to an agent after validating readiness and optionally checking previous turn completion markers, with support for file-based or pane output.

Instructions

Primary agent orchestration tool: validate provider-specific readiness/busy/error state, optionally verify a previous DONE signal or END marker, append the v2.1 PMUX footer, and send the prompt. Use pmux_send_input/pmux_capture_pane only as low-level fallbacks. For fileOutput=true previous turns, pass expectPrevTurnEnd together with expectPrevRequestId so shortened req-keyed markers can be matched. On turn <= 1 only, pane fallback input_queued is treated as a composer placeholder and sent with validation.warning; later turns remain strict. fileOutput defaults true: requestId is generated when omitted, workspaceDir is resolved from workspaces[].directories[0], and expectedReportFile is returned. Use fileOutput:false when pmux_agent_start returned recommendedFileOutput:false; read-only/plan agents cannot write report files. fileOutput=false uses the pane BEGIN/END fallback. agent_busy returns {sent:false, reason:"busy"}. Caller contract: if pmux_agent_capture returns partial/working, do not call pmux_agent_send again until the current turn completes or is explicitly abandoned.

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).
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.
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.
Behavior5/5

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

No annotations provided, so description fully covers behavioral traits: validation steps, optional previous signal verification, busy response format, fileOutput behavior, turn<=1 exception, pattern override limits, and error handling. No contradictions with 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?

Description is comprehensive and front-loaded with main purpose, but somewhat verbose. Every sentence adds value; no redundancy. Good structure with separate points.

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 16 parameters, no output schema, and many siblings, the description covers key workflows, edge cases, and behavioral expectations. Lacks a brief note about expected return format after sending (besides busy), but otherwise complete.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema has 100% coverage, but description adds significant context: relationships between expectPrevTurnEnd and expectPrevRequestId, defaults for fileOutput/requestId/maxResponseLines, and runtime behavior. Adds value beyond schema.

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 agent orchestration tool, validates readiness/busy/error state, verifies previous markers, appends footer, and sends prompt. Distinguishes from siblings by naming pmux_send_input/pmux_capture_pane as low-level 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?

Provides explicit guidance: use fallbacks only when needed, fileOutput:false conditions, turn<=1 special handling, and caller contract about not calling again until turn completes. Alternatives and context are clearly articulated.

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