DZ23 Subagents Universal MCP

Start asynchronous mission

mission_start

Starts a background job and returns a job ID. Executes a dependency-aware task graph or loops with retries/failover until tests pass or it fails safe.

Instructions

Start a mission in the background and return a job_id immediately. With plan, runs a task graph: nodes whose depends_on are done run in parallel (dependency results passed as untrusted data), failed nodes retry up to max_attempts, nodes after a failure are skipped, progress is saved in dag_state and resume_plan: true skips nodes already done (also after a restart). Without plan, runs a loop where each iteration runs swarm_run with the previous integration as diagnosis; near-identical results switch routing strategy and then stop as failed_safe. Progress is kept in the mission loop_state, never in status, next_action or goal. The job ends completed only when the harness recorded new passing tests (memory_checkpoint) during the job; otherwise awaiting_acceptance. May consume provider credits. Reuse the project_id and mission_id of the current task (from project_init / memory_checkpoint); when omitted, results go to project "default" and a new random mission that mission_status and memory_checkpoint will not find.

Input Schema

TableJSON Schema

Name	Required	Description	Default
`goal`	Yes	Mission goal.
`plan`	No	Task graph (up to 30 nodes).
`roles`	No
`mission_id`	No	Mission of the current task; omitted creates a new random mission.
`project_id`	No	Project of the current task; defaults to "default".	default
`lease_token`	No	Token from mission_claim. Required only while another holder has a live lease on this mission.
`resume_plan`	No	Reuse nodes already done in this mission dag_state when the plan is identical.
`max_iterations`	No
`routing_strategy`	No		first
`acceptance_criteria`	No	Objective criteria the harness must prove with evidence.

Schema Changelog

Changes observed during successful MCP inspections.

Changed2 schema fields changedv4.3.0Sep 17, 2026

addedInput schema / properties / plan

Added value: +{
+  "additionalProperties": false,
+  "description": "Task graph (up to 30 nodes).",
+  "properties": {
+    "nodes": {
+      "items": {
+        "additionalProperties": false,
+        "properties": {
+          "depends_on": {
+            "items": {
+              "maxLength": 64,
+              "type": "string"
+            },
+            "maxItems": 30,
+            "type": "array",
+            "uniqueItems": true
+          },
+          "id": {
+            "description": "Unique node id.",
+            "pattern": "^[A-Za-z0-9][A-Za-z0-9_-]{0,63}$",
+            "type": "string"
+          },
+          "max_attempts": {
+            "default": 2,
+            "maximum": 3,
+            "minimum": 1,
+            "type": "integer"
+          },
+          "prompt": {
+            "description": "Task for this node.",
+            "maxLength": 32000,
+            "minLength": 1,
+            "pattern": "\\S",
+            "type": "string",
+            "x-pattern-reason": "must contain non-whitespace text"
+          },
+          "role": {
+            "default": "worker",
+            "enum": [
+              "worker",
+              "architect",
+              "backend",
+              "frontend",
+              "security",
+              "qa",
+              "devops",
+              "reviewer"
+            ],
+            "type": "string"
+          },
+          "task_type": {
+            "enum": [
+              "general",
+              "code",
+              "review",
+              "design",
+              "security",
+              "testing",
+              "ops",
+              "summary"
+            ],
+            "type": "string"
+          },
+          "title": {
+            "description": "Short title.",
+            "maxLength": 200,
+            "type": "string"
+          }
+        },
+        "required": [
+          "id",
+          "prompt"
+        ],
+        "type": "object"
+      },
+      "maxItems": 30,
+      "minItems": 1,
+      "type": "array"
+    }
+  },
+  "required": [
+    "nodes"
+  ],
+  "type": "object"
+}

addedInput schema / properties / resume_plan

Added value: +{
+  "default": false,
+  "description": "Reuse nodes already done in this mission dag_state when the plan is identical.",
+  "type": "boolean"
+}

Addedv4.1.0Sep 17, 2026

TDQS

A4.7/5.0

Behavior5/5

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

Annotations are minimal (readOnlyHint=false, destructiveHint=false, idempotentHint=false, openWorldHint=true), so the description carries the full burden. It discloses that it may consume provider credits, explains state management (progress saved in dag_state/loop_state, never in status/next_action/goal), completion criteria (only when memory_checkpoint records new passing tests, else awaiting_acceptance), retry and skip behavior on failure, and the routing-strategy switch on near-identical results. This is rich behavioral detail far beyond what annotations provide.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is front-loaded with the core action and immediate return. Each subsequent sentence adds necessary detail for a complex tool: the two modes, state management, completion condition, credit consumption, and parameter reuse guidance. No filler; every clause earns its place. The length is justified by the tool's complexity.

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 tool with 10 parameters, a nested plan object, and no output schema, the description covers all critical aspects: execution semantics, failure handling, state location, completion criteria, cost implications, and parameter reuse. An agent would understand exactly how to invoke it correctly and what to expect. Nothing essential is missing.

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 coverage is 70%, so the description compensates for the 30% gap (roles, max_iterations, routing_strategy lack schema descriptions). It adds meaning for plan (task graph, depends_on, retries, resume_plan), mission_id/project_id reuse, lease_token requirement, and the semantics of acceptance criteria via the completion logic. It does not explicitly describe roles or max_iterations, but these have enums/defaults in the schema. Overall it adds substantial value over the schema.

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 description opens with a specific verb and resource: 'Start a mission in the background and return a job_id immediately.' It clearly distinguishes two execution modes (with plan = task graph, without plan = loop), which differentiates it from sibling tools like swarm_run or delegate. The purpose is unambiguous and the scope is precisely stated.

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 description provides strong contextual guidance: it explains when to use the plan-based mode vs the loop mode, and explicitly instructs to reuse project_id and mission_id from project_init/memory_checkpoint, warning that omitting them creates a mission that mission_status and memory_checkpoint cannot find. It does not explicitly name alternative tools or state 'use this instead of X', but the async and orchestration nature is implied by 'background' and the two modes. This is clear usage context but lacks explicit exclusions.

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

Start asynchronous mission

Instructions

Input Schema

Schema Changelog

TDQS

Other Tools