opencode-bridge

opencode_sessions

List and filter opencode sessions across all projects by state, agent, directory, or title to see active runs, outcomes, and stale sessions.

Instructions

READ-ONLY. List opencode sessions of the background service across all projects (newest first): id, state (running / succeeded / failed / interrupted / stale?), agent, age, tokens, directory, title. Use state=running to see what is active now; a session whose last update is older than ~45 min and has no outcome is shown as "stale?".

Tool call template

This tool declares no required parameters. Add optional parameters from the input schema as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {},
    "name": "opencode_sessions"
  }
}

Input Schema

Name	Required	Description
`agent`	No	only this agent, e.g. deep-research
`limit`	No	max rows (default 25, max 200)
`state`	No	running (default: all) \| active \| finished \| succeeded \| failed \| interrupted \| stale \| all
`search`	No	only titles containing this text (server-side search)
`children`	No	include child (sub-task) sessions; default true
`directory`	No	only sessions whose directory contains this text
`title_prefix`	No	only titles starting with this text, e.g. "ALPHA/"
`since_minutes`	No	only sessions updated in the last N minutes

Schema Changelog

Changes observed during successful MCP inspections.

First observedv0.5.0Nov 12, 2026

TDQS

A4/5.0

Behavior4/5

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

With no annotations supplied, the description carries the safety burden and does so by leading with "READ-ONLY." It additionally discloses ordering (newest first) and the non-obvious staleness heuristic (~45 min without an outcome shown as "stale?"). It stops short of mentioning pagination behavior, auth/permission requirements, or truncation of large result sets.

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?

Three tight sentences with the most important constraint (READ-ONLY) and the action front-loaded, followed by return fields then usage. Slightly list-heavy but no sentence is wasted.

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

Completeness4/5

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

For an 8-parameter, zero-required tool with no annotations and no output schema, the definition covers safety, ordering, return fields, and the trickiest state value. The remaining gap is operational context such as default limit behavior or how the service is reached, which an agent would want before first invocation.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters5/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is already 100%, so the baseline would be 3, but the description adds real meaning beyond it: it interprets state=running operationally ("what is active now") and defines the otherwise ambiguous "stale" value as no update in ~45 minutes and no outcome. That resolves a genuine semantic gap the schema's free-text state string leaves open.

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?

Opens with a specific verb and resource ("List opencode sessions of the background service across all projects") and even enumerates the fields returned (id, state, agent, age, tokens, directory, title). It does not explicitly contrast itself with siblings like opencode_list or opencode_status, so an agent must infer that distinction from context rather than being told.

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?

Provides one concrete usage pointer: "Use state=running to see what is active now." It also explains the stale? annotation's threshold. However, it never says when NOT to use this tool or which sibling (e.g. opencode_list, opencode_status, opencode_processes) covers overlapping needs, so routing is only partially guided.

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

Deploy Server