Skip to main content
Glama
Sign In
agent-bridge

agent-bridge

by merlinh0
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Python
Local

adopt_session

Take control of an existing omp or Claude Code session: drive a live Tern block in place or reopen a saved transcript with full history in a new tab, keeping its directory, branch, and model.

Instructions

Take control of an existing omp / Claude Code session (from discover_sessions).

block: a live Tern block running the session: it is driven in place, nothing is restarted. session_file: a saved transcript; if it is running in Tern it is adopted live, otherwise it is reopened (resumed with its full history) in a new tab of the Tern session "agents". name: agent name (default: from the session title). base: commit-ish get_diff compares against (default: the current HEAD, so the diff shows changes made from now on plus any uncommitted edits already present). The session keeps its own directory, branch and model: no worktree is created, the model policy is not applied until you switch its model, and stop_agent never deletes anything of an adopted session.

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": "adopt_session"
  }
}

Input Schema

NameRequiredDescriptionDefault
baseNo
nameNo
blockNo
session_fileNo

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.1.0

TDQS

A4.7/5.0
Behavior5/5

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

With no annotations, the description carries the full burden and does so well: nothing is restarted, history is preserved on resume, no worktree is created, the model policy is not applied until a model switch, and stop_agent never deletes an adopted session. These are exactly the side-effect and safety facts an agent needs before mutating state.

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?

Front-loads the core action in one sentence, then uses a compact per-parameter list, which is easy to scan. The base explanation is slightly convoluted ('changes made from now on plus any uncommitted edits already present') but still earns its place.

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?

For a 4-parameter, zero-annotation, no-output-schema tool, the description covers purpose, mode selection, defaults, and side effects. Nothing an agent needs in order to invoke it correctly appears to be missing.

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 0%, so the description must compensate, and it documents all four parameters: block (live Tern block), session_file (saved transcript), name (default from session title), and base (default current HEAD, with the diff semantics explained). This adds meaning well beyond the bare schema titles.

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 and resource ('Take control of an existing omp / Claude Code session') and anchors it to the sibling discover_sessions as the source of sessions. The two operating modes (block vs session_file) are named explicitly, so an agent can tell this apart from discovery or agent-start tools.

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?

Gives clear conditional guidance: use block for a live Tern block driven in place, use session_file for a saved transcript (adopted live if running, otherwise reopened in the 'agents' tab). It implies discover_sessions is the prerequisite. It stops short of explicit when-not-to-use or naming alternatives like start_agent.

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

Deploy Server

Other Tools