Skip to main content
Glama

OpenCode Status

opencode-status

Check or wait for a running OpenCode turn, list tracked sessions, relay pending approvals, and batch-check up to 16 sessions in one call to collect parallel results.

Instructions

Use this to check on or wait for a running OpenCode turn, or — with no id — to list the sessions tracked by this server. With an id it can block up to wait-seconds (max 600) and will also relay any pending approval prompts to you, so it is not purely read-only: it can act on the session while waiting. Without an id it returns the tracked session list in structuredContent.sessions and structuredContent.content. Pass ids (up to 16, instead of a single sessionId/threadId/conversationId) to check several sessions in one call — pair with wait-seconds:0 on opencode/opencode-reply to fan work out in parallel, then wait-for "any" (default) or "all" here to collect the results; batch items are always compact and max-output-chars becomes the shared answer budget split across them. detail/max-output-chars shrink a single-session answer the same way as on opencode.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
idsNoCheck up to 16 sessions at once instead of one (batch mode): each array entry is a session id, unique, 1-200 chars. Mutually exclusive with sessionId/threadId/conversationId. Each id captures that session's current (or pending) turn at call start; an unknown id comes back as a per-item error, never failing the whole call. Pair with wait-seconds:0 on opencode/opencode-reply to fan several turns out in parallel, then batch-check them all here.
detailNo'compact' (default 'standard') drops toolCalls and filesChanged from this response (keeping toolCallCount, filesChangedCount, pendingApprovalCount, and pendingApprovals itself) to save context; the full answer and tool-call log stay retrievable with opencode-output regardless of this setting.
threadIdNoAlias for sessionId (Codex-compatible name), same session id value. Exactly one of sessionId, threadId, conversationId is required to target a session; opencode-status may omit all three to list tracked sessions instead.
wait-forNoOnly with ids: 'any' (default) returns as soon as one item is ready; 'all' waits for every item (bounded by wait-seconds) before returning. Invalid without ids.
sessionIdNoId of a session tracked by this server, from a prior opencode call. Exactly one of sessionId, threadId, conversationId is required to target a session; opencode-status may omit all three to list tracked sessions instead.
wait-secondsNoHow long (seconds, max 600, default 0) to wait for the turn to reach a terminal or approval-waiting state before returning a snapshot; while waiting, this call also relays pending approval prompts. With a single id: required id (sessionId/threadId/conversationId) or list mode is used instead. With ids: the batch wait bound (see wait-for).
conversationIdNoDeprecated alias for sessionId, same session id value. Exactly one of sessionId, threadId, conversationId is required to target a session; opencode-status may omit all three to list tracked sessions instead.
max-output-charsNoCaps how many characters of the answer come back in THIS response only (0..44000; 0 returns no answer text at all). Never truncates the retained turn — read the rest with opencode-output. Omit to use the default for the chosen detail level (44000 standard, 2000 compact).

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault
costNo
diffNo
hintNo
kindYes
turnNo
agentNo
errorNo
modelNo
rootsNo
totalNo
actionNo
agentsNo
finishNo
modelsNo
offsetNo
outputNo
reasonNo
serverNo
statusYes
tokensNo
turnIdNo
cleanupNo
contentYes
hasMoreNo
partialNo
requestNo
resultsNo
sectionNo
waitForNo
readyIdsNo
sessionsNo
threadIdNo
warningsNo
directoryNo
elapsedMsNo
sessionIdNo
toolCallsNo
truncatedNo
nextOffsetNo
observedAtNo
pendingIdsNo
snapshotIdNo
availabilityNo
filesChangedNo
resendSafetyNo
responseLoopNo
upstreamReadNo
omittedFieldsNo
toolCallCountNo
upstreamRetryNo
executionStateNo
opencodeVersionNo
pendingApprovalsNo
structuredOutputNo
filesChangedCountNo
abortedRunningTurnNo
pendingApprovalCountNo
structuredOutputErrorNo
structuredOutputStatusNo

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.3.0

TDQS

A4.6/5.0
Behavior4/5

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

Annotations only supply readOnlyHint=false, so the description carries most of the behavioral burden and delivers: it flags that the call is 'not purely read-only' because it relays/acts on approval prompts, discloses the wait bound (max 600s), and describes what compact mode drops and what max-output-chars does to the response. It stops short of describing error/edge behavior, but adds substantial context beyond the single annotation.

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 core purpose and the id/no-id split are front-loaded in the first sentence, and the remaining sentences map to batch, collect, and shrink behaviors. It is dense and the first sentence is long, but for an 8-param tool with three operating modes almost every clause carries distinct information.

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?

Even though an output schema exists (so return values need not be spelled out), the description goes further and names structuredContent.sessions/content, batch item error isolation ('never failing the whole call'), and budget splitting. Combined with the mode routing and wait/approval semantics, an agent has everything needed to call it correctly.

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 coverage is 100%, so the baseline is 3, but the description adds cross-parameter semantics the schema documents only per-field: that `wait-for` is only valid with `ids`, that batch items are compact and `max-output-chars` becomes a shared budget split across them, and that `detail`/`max-output-chars` shrink single-session answers like on opencode. This is real added meaning over the 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?

The opening sentence states a specific verb+resource pair ('check on or wait for a running OpenCode turn') and immediately distinguishes the no-id branch ('list the sessions tracked by this server'). An agent can separate it from opencode-reply, opencode-output, and opencode-cancel 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 Guidelines5/5

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

It explicitly routes between modes: with an id to wait/relay approvals, without an id to list sessions, and with `ids` for batch checks. It names the sibling workflow (pair 'wait-seconds:0' on opencode-reply to fan out, then collect here) and points to opencode-output for the full retained answer, covering when-not-to-expect-this-tool-to-return-everything.

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