Skip to main content
Glama

OpenCode End

opencode-end
DestructiveIdempotent

End an OpenCode session by ID: stop the running turn, reject pending permission prompts, then delete or archive the session and remove it from tracking.

Instructions

Use this to finish working with an OpenCode session: it stops any running turn, rejects any leftover permission prompts, then deletes or archives the session and forgets it (action, default 'delete' — this server's configured OPENCODE_MCP_END_ACTION). Requires exactly one of sessionId, threadId or conversationId. Idempotent: ending an unknown or already-ended session returns structuredContent.status "not_found" without contacting OpenCode.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
actionNoWhether to delete or archive the session when ending it. Default is this server's configured OPENCODE_MCP_END_ACTION (see this tool's description for the current default).
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.
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.
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.7/5.0
Behavior5/5

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

Goes well beyond the idempotentHint/destructiveHint annotations: it discloses that a running turn is stopped, leftover permission prompts are rejected, the session is deleted or archived and forgotten, that the default action comes from server config (OPENCODE_MCP_END_ACTION), and that re-ending an unknown session returns structuredContent.status "not_found" without contacting OpenCode.

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

Conciseness5/5

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

Two dense sentences, front-loaded with the use case, then a colon-led list of effects. No filler, no repetition of schema-only content; the parenthetical for the default and the idempotency clause are both load-bearing.

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?

An output schema exists so return-shape detail is unnecessary, yet the description still supplies the one return nuance an agent needs ("not_found" for unknown/already-ended sessions). Combined with destructive/idempotent annotations and full schema coverage, nothing needed 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 cross-field constraint the schema does not encode: exactly one of sessionId/threadId/conversationId must be supplied, plus the default-action semantics for `action`. It does not restate the alias/deprecation details, which the schema already covers.

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?

States a specific verb+resource (end/delete-archive an OpenCode session) and enumerates the concrete steps it performs: stop the running turn, reject pending permission prompts, delete or archive, forget. This distinguishes it from siblings like opencode-cancel (stops a turn only) and opencode-status (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 Guidelines4/5

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

"Use this to finish working with an OpenCode session" gives clear context for when to call it, and the schema notes opencode-status as an alternative for listing. However the description never explicitly contrasts itself with opencode-cancel, even though it, too, stops a running turn — an agent could reasonably ask which to use.

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