Skip to main content
Glama

OpenCode Output

opencode-output
Read-only

Page through a turn's full retained answer, tool-call log, structured output, or file diff using offset/limit to read only what's needed without fetching the entire text each call.

Instructions

Page through a turn's full retained answer, tool-call log, structured output, or the OpenCode-reported file diff for that turn. Use detail:"compact" and max-output-chars on opencode/opencode-reply/opencode-status to keep every normal answer small; come back here with the same turn number to read more of it, one page at a time (offset/limit), without paying for the full text on every call — useful together with wait-seconds:0 plus opencode-status ids/wait-for fan-out, reading each turn's full output here only for the ones that need it. Requires exactly one of sessionId, threadId or conversationId, plus turn; section defaults to "answer". Retained output expires (OUTPUT_UNAVAILABLE) and is dropped once opencode-end succeeds, so read what you need before ending the session. Read-only: never mutates OpenCode.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
turnYesThe turn number to read (from a prior turn result's `turn` field).
limitNoHow much of this page to return: chars for answer/structured-output/diff-patch (256..20000, default 4000), items for tool-calls/diff-stat (1..100, default 20 for tool-calls, 50 for diff-stat). Also bounded by this server's configured output limit.
offsetNoWhere to resume paging from (default 0): a UTF-16 code-unit offset for text sections, an item offset for tool-calls/diff-stat. Use the previous call's nextOffset; offset === total returns an empty final page.
sectionNoWhich retained artifact to page through (default "answer"): the full final answer text, the tool-call log, the structured-output JSON (when output-schema was used), or the OpenCode-reported file diff for this turn (see diff-view).
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.
diff-viewNoOnly with section:"diff" (default "stat"): "stat" lists changed files with add/delete counts, "patch" returns one file's patch text (requires file-index).
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.
file-indexNoOnly with diff-view:"patch": which file (by its fileIndex from a prior "stat" page) to read the patch of.
snapshot-idNoPins reads to one frozen diff snapshot (required for diff-view:"patch", and for diff "stat" continuation once offset > 0): the id returned by a prior opencode-output diff read. Omit to fetch (or refetch, if the prior snapshot expired) a fresh one.
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.

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

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

Beyond the readOnlyHint/openWorldHint annotations, it discloses critical lifecycle behavior: retained output expires (OUTPUT_UNAVAILABLE) and is dropped once opencode-end succeeds, so reads must happen before ending the session. It also states the exactly-one-of session id requirement and the read-only guarantee, which is exactly the behavior an agent cannot infer from 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?

Purpose is front-loaded in the first sentence and every clause carries routing, retention, or constraint information. However, the middle 'useful together with...' sentence is a long chain of nested parentheticals that is denser than it needs to be for the value delivered.

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 an output schema present, the description correctly omits return-value explanations, and instead covers the non-schema essentials: session targeting rules, retention/expiry, the read-before-end ordering, and diff snapshot handling. Nothing an agent needs to call this correctly is 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 coverage is 100%, so the baseline is 3, but the description adds a real constraint not encoded in the schema: 'Requires exactly one of sessionId, threadId or conversationId, plus turn', and clarifies section defaults and snapshot-id pinning semantics for diff reads. It mostly reinforces what the schema already says, so it stops short of 5.

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?

Opens with a specific verb ('Page through') plus the exact set of resources it can return (full retained answer, tool-call log, structured output, file diff) and scopes it to a single turn. This clearly distinguishes it from siblings like opencode-reply (which produces small answers) and opencode-status (which lists sessions).

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 routes the agent: keep normal answers small via detail:"compact" + max-output-chars on opencode/opencode-reply/opencode-status, then 'come back here with the same turn number to read more'. It names the alternative tools, the fan-out pattern (wait-seconds:0 with opencode-status), and when not to use this tool ('reading each turn's full output here only for the ones that need it').

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