Skip to main content
Glama

Send message to Workspace

send_workspace_message
Destructive

Send a message to a Plori Workspace to start or continue a background agent run that works on its files and saves a new revision, returning run status for long builds or reports.

Instructions

Use this when a build, research or recurring report should run in the background or after the chat ends. Do not use for quick lookups. Send a message to a Workspace's main conversation, or to another of its conversations named by session_id; the Workspace's agent runs it. The run works on the Workspace's current files and saves them as a new revision when it ends. Returns the run with agent_id and workspace_id. A completed run has text (the agent's reply), the files the reply linked, a url to the conversation in the Plori web app, and its credits and tokens; file_source.state ready and no save_failure mean its files are saved. A run still going has status "running", run_id and poll_after_seconds, and continues after this call returns. A paused run has status "awaiting_input" and lists its requests; tell the person each approval's approve_url and who it is assigned to. A run started through this connector pauses before each action outside the agent's own environment (connected-account, MCP and outbound HTTP writes, git push, publishing, deploys, email) until the account owner approves that one action in the Plori web app; the owner's standing approvals do not apply and the calling model cannot approve. While the conversation is running or paused, a plain-text message is accepted as steering or queued (steer_id), or answers an ordinary question assigned to its sender, and never cancels a pending request. A message with attachments or run options gets 409 conversation_busy until the conversation is idle: keep them and resend once it is idle. Runs are charged to the account's prepaid US-dollar balance; a run the balance cannot cover is refused with 402. idempotency_key identifies the request for 24 hours: the same key with the same arguments returns the original result, and the same key with different arguments is refused.

Input Schema

NameRequiredDescriptionDefault
waitNoQueued or steering messages return their receipt immediately, regardless of wait. For a newly started or continued run, true (default): hold this call until the run finishes, pauses for a person, or the hold ends. The hold is 25 seconds by default, 50 seconds for Codex, and up to 30 minutes for Claude Code 2.1.212 or later; a call without an MCP progressToken is held at most 50 seconds. If the hold ends first, the result has status "running" and the run continues. false: return the run_id at once. Clients that support MCP Tasks always receive the run_id at once.
messageYesThe message for the agent, in plain text.
session_idNoA conversation of this Workspace to continue (session_id from an earlier result). Omitted, the message goes to the main conversation. A worker's private conversation cannot be selected here.
callback_urlNoOptional callback URL for this run. Must use http or https and resolve only to public addresses.
wait_secondsNoHold length in seconds when wait is true, used instead of the client default. 0 or omitted uses the client default. A call without an MCP progressToken is still held at most 50 seconds.
workspace_idYesThe Workspace UUID.
callback_secretNoOptional secret used to sign callback deliveries with HMAC-SHA256.
idempotency_keyNoA string of 1-255 bytes you generate for this message. The same key with the same arguments returns the original run or message receipt for 24 hours instead of acting again; the same key with different arguments is refused. Without a key, every call submits a new message.
max_turn_tokensNoOptional cumulative cache-weighted token ceiling for this turn. 0 or omitted: no ceiling for a registered account, and 2,000,000 for an anonymous trial. The maximum is 5,000,000. The agent reserves its final 2% for a tool-free wrap-up that says the work so far is saved and that a new message continues the task.
max_turn_secondsNoOptional wall-clock budget for this turn in seconds, maximum 14,400. When it runs out the agent is told to finish and reply; the run is not cancelled. 0 or omitted uses the platform default, when one is set.
max_advisor_spend_micro_usdNoOptional maximum advisor-completion spend for this turn in micro-US-dollars. 0 disables advisor completions. Omit it or pass null to use the agent setting; when neither is set, at most two advisor calls can run. The maximum is 5,000,000.

Output Schema

NameRequiredDescriptionDefault
urlNoA deep link to this run's session in the plori web app.
hintNoWhat to do next with this run, in one sentence. Present only while the run is non-terminal.
textNoThe assistant's reply once the run has finished. While a run is still going this is the run's own status message, not an answer, and is often absent — read last_worklog and last_tool_step instead.
causeNoMachine-readable cause for a non-normal terminal state.
errorNoWhy a terminal error or cancelled run failed, whether it was charged and what to do about it. Absent for a run that is still going or that finished normally.
filesNoFiles in the Workspace files that this reply linked, in the order they appear. Each url is fetchable with the bearer token you called this tool with. Absent when the reply linked none.
run_idYesThe public run identifier; empty for an answered message whose continuation has not started.
statusYesThe current run status, queued/steering for a message accepted into an active conversation, or answered when the answer is recorded but its continuation has not started.
tokensNoAttributed token count; null when attribution is unavailable.
advisorNoAdvisor calls used and allowed, spend this turn, and its optional spend cap in micro-US-dollars.
creditsNoAttributed spend in micro-US-dollars; null when attribution is unavailable.
agent_idNoThe agent that runs the run. get_run_result and cancel_run take this value or workspace_id.
ended_atNoWhen the run reached a terminal state.
steer_idNoDurable message receipt when status is queued or steering. run_id names the running or paused predecessor, not a result of this message; find the later queued turn with list_runs.
retryableNoWhether sending the same message again could plausibly succeed. A time_limit run can continue with a follow-up message.
session_idYesThe durable conversation/session identifier.
started_atNoWhen the run started.
file_sourceNoWhere this run's file links read from and whether its files are saved. Execution status does not report the save; check state here.
stop_reasonNoController-selected stop reason, when present.
input_statusNoThe durable status of this run's human-input request, when it has one: pending, answered, cancelled or expired. cancelled and expired are terminal — that run will never resume, so stop polling it.
last_worklogNoThe agent's most recent one-sentence note about what it is doing, from the run's durable event log. Absent for a terminal result and for a run that has written none.
save_failureNoPresent when saving the run's working copy failed, so its files are not durable outputs. code names the failure. content_refusals lists up to three refused paths, relative to the copy root, each with its cause: hardlink, database_backup_required (a SQLite file that needs sqlite3 .backup) or unsupported_file_mode.
workspace_idNoThe Workspace UUID.
input_expiredNoTrue when this run is paused on a question its conversation has already moved past: a later run in the same conversation has completed. Do not answer it; start a new run instead.
poll_after_msNoThe same wait as poll_after_seconds, in milliseconds.
resume_run_idNoThe exact auto-resume successor for an interrupted run; poll this run next.
resume_statusNoAuto-resume disposition for an interrupted run: pending, resumed, failed, or unknown.
tool_progressNoDurable tool execution progress; absent when this run has no tool-progress telemetry.
usage_by_roleNoAttributed spend, tokens, and model-call counts split into executor, advisor, and reviewer roles.
last_tool_stepNoWhat this run last did with a tool: "running <tool>" while a call is in flight, otherwise "completed <tool>" for the most recent finished call. Absent for a terminal result and for a run with no tool-progress telemetry.
pending_inputsNoHuman inputs blocking an awaiting_input run.
elapsed_secondsNoSeconds since the run started; absent for a terminal result.
upstream_statusNoThe model provider's HTTP status when this run died on an upstream fault; absent otherwise.
last_activity_atNoWhen the run last wrote a note or finished a tool call. Absent for a terminal result and for a run that has done neither.
last_heartbeat_atNoMost recent durable executor heartbeat.
continuation_errorNoWhy the answered message has not started its continuation.
poll_after_secondsNoSuggested seconds before polling again, paced to this run's recent tool-completion rate; absent for a terminal result.
continuation_run_idNoThe exact continuation created for an answered input; poll this run next.
continuation_pendingNoThe answer was recorded and its continuation has not started yet. Retry this message with the same idempotency key to get the continuation.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Addedv0.17.1

TDQS

A4.5/5.0
Behavior5/5

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

Annotations only say destructive/openWorld/non-idempotent; the description adds substantial operational context beyond them: approval pausing before external actions, that the caller cannot self-approve, 409 conversation_busy on attachment/option messages, 402 when the prepaid balance cannot cover the run, and 24-hour idempotency_key semantics. This is exactly the kind of behavior an agent needs that structured fields do not carry.

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

Conciseness3/5

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

It is front-loaded with the usage rule, which is good, but the body is a very long single block that restates schema-documented material (idempotency_key behavior, run status fields) even though an output schema already exists. It is information-dense rather than wasteful, but the duplication of structured fields and the sheer length cost it.

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

Completeness5/5

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

With 11 parameters, full schema coverage, an output schema, and annotations, the remaining burden is behavioral — and the description covers billing, approval gating, busy/error states, waiting semantics, and idempotency. Nothing an agent needs in order to invoke it correctly appears missing.

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 description coverage is 100%, so the schema already documents all 11 parameters and the baseline is 3. The description adds meaning on top: it clarifies what a plain-text message does during a live conversation (steering, queued, answering a pending question) and reinforces the idempotency_key contract, going beyond the schema's field-level wording.

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 states a specific verb and resource ('Send a message to a Workspace's main conversation, or to another of its conversations named by session_id; the Workspace's agent runs it') and frames the scope as background/after-chat work. An agent can distinguish this from siblings like answer_pending_input or steer_workspace_worker because the description explains that a plain-text message becomes steering when the conversation is already running.

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?

It gives explicit when-to-use ('when a build, research or recurring report should run in the background or after the chat ends') and a when-not ('Do not use for quick lookups'), plus busy/refusal conditions. It does not name alternative tools (answer_pending_input, steer_workspace_worker) explicitly, so the routing to siblings is left partly implicit.

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