Skip to main content
Glama
Sign In
agent-bridge

agent-bridge

by merlinh0
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Python
Local

start_agent

Starts an implementation agent on a self-contained repository task in a new Tern tab and isolated git worktree, so parallel coding work runs on its own branch.

Instructions

Start an implementation agent on task in a new Tern tab (Tern session "agents").

repo: path to the git repository (any directory inside it). task: the full, self-contained instructions; the agent sees nothing else from this conversation. name: short id (lowercase letters, digits, dashes); defaults to the task's first words. The branch is agent/. base: commit-ish the worktree branches from (default HEAD of the repo). engine: "omp" (default; every provider configured on this machine) or "claude" (Claude Code). model: "auto:fast" | "auto:balanced" | "auto:frontier" (tier from the live catalog), or an exact model: omp selector from list_models (e.g. "openai-codex/gpt-6.1-sol"), or for claude an alias ("opus", "sonnet", "haiku") / full id. Omitted: the engine's default, unless the model policy has an allowlist (then auto:balanced). thinking: reasoning level. omp: off|minimal|low|medium|high|xhigh|max|auto (one the model supports); claude: low|medium|high|xhigh|max|auto (--effort). Omitted with an auto tier: the tier's default. auto_approve: let the agent run every tool without asking (omp --auto-approve / claude --dangerously-skip-permissions). Refused unless the user enabled it on this machine. Without it the agent may stop on approvals; read them with capture_screen, answer with press_keys. worktree: False runs in the repository checkout itself (no isolation; avoid with parallel agents).

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "repo": "<repo>",
      "task": "<task>"
    },
    "name": "start_agent"
  }
}

Input Schema

NameRequiredDescriptionDefault
baseNoHEAD
nameNo
repoYes
taskYes
modelNo
engineNoomp
thinkingNo
worktreeNo
auto_approveNo

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.1.0

TDQS

A4.4/5.0
Behavior4/5

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

With no annotations, the description carries the full load and mostly succeeds: it discloses that the agent sees nothing but `task`, that auto_approve is refused unless enabled on the machine, that without it the agent may stop on approvals, that worktree=False runs in the checkout with no isolation, and the agent/<name> branch convention. It does not say what the call returns or whether it is blocking until the agent finishes.

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?

A one-sentence purpose up front, followed by a per-parameter glossary with indented continuations — easy to scan and logically ordered. The model and thinking entries are long, but the length is earned by genuinely conditional semantics rather than filler.

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 a nine-parameter mutating tool with no annotations and no output schema, the definition supplies defaults, constraints, policy gates, and cross-tool escape hatches. The notable omission is the return value (agent id or tab id) and any precondition that the Tern tab or repo must already exist.

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 description coverage is 0%, yet every one of the nine parameters is explained with meaning beyond type: repo accepts any directory inside the git repo, task must be self-contained, name has a charset constraint plus a default derived from the task, model enumerates per-engine families and the allowlist fallback to auto:balanced, and thinking lists the per-engine levels.

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?

The opening sentence names a specific verb, resource, and destination: 'Start an implementation agent on `task` in a new Tern tab (Tern session "agents")'. That distinguishes it from siblings like get_agent, list_agents, and adopt_session, which read or attach to existing agents.

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?

The `worktree` entry says 'avoid with parallel agents', and the `auto_approve` entry routes the agent to capture_screen and press_keys when the run stalls on approvals — genuine when-to-use guidance. It lacks an explicit alternative-selection statement (e.g. when to prefer adopt_session) and any stated preconditions.

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