opencode-cli-mcp

Overview Schema Source Related Servers Discussions Admin

OpenCode Sessions

opencode_sessions

Inspect and interact with opencode sessions: list, get, transcript, send, diff, grep, export, share, unshare, rename, or delete.

Instructions

Inspect and interact with opencode sessions: list, get, transcript, send, diff, grep, export, share, unshare, rename, or delete.

Return Format

{"success": bool, "message": str, "data": dict}

Examples

opencode_sessions(action="list", limit=50) opencode_sessions(action="messages", session_id="sess_01", limit=100) opencode_sessions(action="send", session_id="sess_01", message="continue") opencode_sessions(action="share", session_id="sess_01") opencode_sessions(action="unshare", session_id="sess_01") opencode_sessions(action="rename", session_id="sess_01", title="Refactor auth module") opencode_sessions(action="delete", session_id="sess_01", confirm=True)

Input Schema

Name	Required	Description	Default
`limit`	No	Page size (list/messages)
`query`	No	Search query (required for grep)
`title`	No	New title (required for rename)
`action`	Yes	list: all sessions. get: one session. messages: transcript. send: message a session. diff: files changed. grep: search messages across sessions. export: render session as markdown/html. share: publish an unlisted share page (offline, revocable). unshare: revoke a session's share pages. rename: set title (serve API, live UI). delete: permanently remove (confirm=True).
`format`	No	Export format: markdown or html (export)	markdown
`offset`	No	Page offset (list)
`confirm`	No	Must be True to delete (permanent)
`message`	No	Message text (required for send)
`session_id`	No	Session ID (required for get/messages/send/diff/export/share/unshare/rename/delete)

Output Schema

Name	Required	Description	Default
`data`	Yes
`message`	Yes
`success`	Yes

Schema Changelog

Changes observed during successful MCP inspections.

Changed6 schema fields changedv0.2.11Oct 21, 2026

changedInput schema / properties / action / description

Previous value: -"list: all sessions. get: one session. messages: transcript. send: message a session. diff: files changed. grep: search messages across sessions. export: render session as markdown/html. rename: set title (serve API, live UI). delete: permanently remove (confirm=True)."New value: +"list: all sessions. get: one session. messages: transcript. send: message a session. diff: files changed. grep: search messages across sessions. export: render session as markdown/html. share: publish an unlisted share page (offline, revocable). unshare: revoke a session's share pages. rename: set title (serve API, live UI). delete: permanently remove (confirm=True)."

changedInput schema / properties / action / enum

Previous value: -[
-  "list",
-  "get",
-  "messages",
-  "send",
-  "diff",
-  "grep",
-  "export",
-  "rename",
-  "delete"
-]New value: +[
+  "list",
+  "get",
+  "messages",
+  "send",
+  "diff",
+  "grep",
+  "export",
+  "share",
+  "unshare",
+  "rename",
+  "delete"
+]

changedInput schema / properties / session_id / description

Previous value: -"Session ID (required for get/messages/send/diff/export/rename/delete)"New value: +"Session ID (required for get/messages/send/diff/export/share/unshare/rename/delete)"

removedOutput schema / additionalProperties
```
Removed value: -true
```

addedOutput schema / properties

Added value: +{
+  "data": {
+    "type": "object"
+  },
+  "message": {
+    "type": "string"
+  },
+  "success": {
+    "type": "boolean"
+  }
+}

addedOutput schema / required

Added value: +[
+  "success",
+  "message",
+  "data"
+]

First observedv0.2.3Aug 5, 2026

TDQS

A3.6/5.0

Behavior4/5

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

Annotations only give readOnlyHint=false, so the description must carry the safety burden and it largely does: delete is flagged as permanent and gated on confirm=True, share is described as 'offline, revocable', unshare as revocation, and rename as affecting the serve API and live UI. What is missing is the auth/permission requirements and any note that this tool mixes read and write actions in one surface.

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?

The opening sentence simply re-lists the enum values already present in the schema, which is wasted text, and the 'Return Format' line duplicates a return value the tool already declares via output schema. The Examples block does earn its place, and the structure is front-loaded, but roughly a third of the description is redundant with structured fields.

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

Completeness3/5

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

For a nine-parameter, eleven-action tool with a full output schema, the description covers action scope and mutation behavior adequately. The gaps are the absence of any sibling routing guidance (critical given five near-duplicate siblings) and no error or failure-mode information for actions like send/grep on nonexistent sessions.

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 baseline is 3; the description earns a bump because the Examples block ties parameters to specific actions (session_id with get/messages/send/diff/export/share/unshare/rename/delete, query with grep, format with export), which the flat schema does not express. It still doesn't clarify pagination semantics for offset/limit across list vs messages.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb ('Inspect and interact with') plus resource ('opencode sessions') and enumerates the twelve operations in scope, so an agent knows exactly what the tool covers. However, it never distinguishes itself from highly overlapping siblings such as opencode_list_sessions, opencode_get_session, opencode_send_message, opencode_get_messages, and opencode_session_diff, which is the main purpose-clarity gap for a facade tool.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

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

The Examples block implicitly demonstrates which action pairs with which parameters (action='messages' with session_id, action='rename' with title, action='delete' with confirm=True), which is real invocation guidance. But there is no explicit when-to-use-this-vs-alternative guidance, and nothing tells the agent why it should call this consolidated tool rather than the granular session siblings.

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