subtask

Overview Schema Source Related Servers Discussions Admin

start

Launch one background coding job and return its ID, with options for worktree isolation, verification, retries, model selection, and spend limits.

Instructions

Start one job; returns its id. kind: read|code|review|hard. Writes: repo= or isolation='worktree' (own branch). model: engine-specific model id (opencode, codex, kimi, API engines); omitted = the engine's default. verify: shell check run by subtask after the job; max_retries (0-5) resumes with the failure. invariants: default ['no_test_deletion','no_suppression'] fail verify on deleted/skipped tests or new noqa; [] = off. allowed_paths: files outside are reverted. symbol_scope: ['f.py::func'] only those defs may change; integrate merges by symbol. oracle_cmd: after verify passes, run on base and result; reports output_match and speedup_pct. adversarial: a Breaker job writes the tests first. context_refs: file:P[:A-B] | git:diff[:REF] | subtask:ID:summary|diff instead of pasting text; auto_repomap adds a symbol map. policy: worktree|sandbox|isolated|untrusted. tier: auto|fast|balanced|deep|free_only.

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": {
      "task": "<task>"
    },
    "name": "start"
  }
}

Input Schema

Name	Required	Default
`cwd`	No
`base`	No	HEAD
`kind`	No	code
`repo`	No
`task`	Yes
`tier`	No	auto
`files`	No
`model`	No
`effort`	No	medium
`engine`	No	auto
`policy`	No
`verify`	No
`max_usd`	No
`contract`	No
`readonly`	No
`isolation`	No	shared
`max_turns`	No
`invariants`	No
`oracle_cmd`	No
`adversarial`	No
`max_retries`	No
`auto_repomap`	No
`context_refs`	No
`symbol_scope`	No
`allowed_paths`	No

Schema Changelog

Changes observed during successful MCP inspections.

First observedv0.1.0Nov 13, 2026

TDQS

A3.5/5.0

Behavior4/5

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

With zero annotations, the description carries the full burden and does so well: it discloses that writes need repo= or an isolation worktree with its own branch, that verify is a shell check run by a subtask, that max_retries resumes with the failure, that files outside allowed_paths are reverted, and that oracle_cmd runs on both base and result. Gaps remain on failure semantics beyond retry and on permissions/side effects of policy levels.

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?

It is front-loaded with purpose and wastes no words, but the body is a dense telegraphic run of 'key: value' fragments that is hard to scan for 25 parameters. Compression is efficient in length yet costs readability; some entries like 'adversarial: a Breaker job writes the tests first' are cryptic without prior knowledge.

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 25-parameter, nested-object tool with no annotations and no output schema, the description covers the highest-risk behaviors (isolation, reverts, verification, retries) but omits budget (max_usd), contract, readonly, files and turn limits. An agent could call it but could easily misuse the cost and concurrency controls.

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

Parameters3/5

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

Schema description coverage is 0% across 25 parameters, so the description must compensate, and it does explain roughly a dozen (kind, model, verify, max_retries, invariants, allowed_paths, symbol_scope, oracle_cmd, adversarial, context_refs, auto_repomap, policy, tier, repo/isolation). But cwd, base, files, effort, engine, max_usd, contract, readonly and max_turns are undocumented, and enumerated values such as tier and policy are listed without explaining what each means.

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?

The opening clause 'Start one job; returns its id' gives a specific verb and resource and implicitly contrasts with the sibling start_many. However, 'job' is left abstract — nothing states this is an agent/coder job on a repo, so an agent must infer the domain from the kind and policy values.

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?

Usage is only implied: 'one job' hints that start_many exists for batches, and the kind enumeration (read|code|review|hard) hints at job-type selection. There are no explicit when-to-use/when-not statements, no guidance on choosing policy or tier, and no mention of whether to call plan or inspect first.

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

Deploy Server