Mushi-Mushi

Dispatch Mushi fix agent

dispatch_fix

Launch a fix agent on a classified bug report to write a branch and open a signed draft PR automatically, then poll the timeline and merge once CI passes.

Instructions

Start a Mushi fix agent for a classified report; it writes a branch and opens a signed draft PR. Set agent="cursor_cloud" to dispatch a Cursor Cloud Agent (default uses the in-repo worker). For a project with several linked repos, set targetRepoId (a project_repos.id) to choose the repo the PR opens against; omit it for the primary repo. Requires GitHub connected + an LLM key (run diagnose_setup mode=dispatch first). Returns { fixId, status } (fixId is the dispatch id; get_fix_timeline accepts it immediately); poll get_fix_timeline for progress and merge_fix when CI is green. Write; pass the same idempotencyKey to retry safely — without it each call starts a new attempt. Report must be classified — run triage_issue if not.

Input Schema

Name	Required	Description
`agent`	No	Which agent runs the fix. Omit for the project default (auto); cursor_cloud and github_cloud_agent dispatch a cloud agent.
`reportId`	Yes	Report UUID to fix (`report_id` is accepted too.)
`projectId`	No	Project UUID — defaults to the configured project. (`project_id` is accepted too.)
`targetRepoId`	No	Optional linked repo id (project_repos.id) to open the fix PR against, for a project with several repos. Omit for the project's primary repo. Another project's repo id is rejected with 400 TARGET_REPO_NOT_IN_PROJECT.
`idempotencyKey`	No	Optional RFC 4122 UUID. Resend the same key to safely retry without dispatching a duplicate fix job (Idempotency-Key IETF draft).
`inventoryActionNodeId`	No	Optional inventory Action node UUID for spec-traceability (§2.10). When provided, the fix-worker embeds the expected_outcome contract in the LLM prompt and runs validateAgainstSpec before opening the PR.

Output Schema

Name	Required	Description	Default
`fixId`	Yes
`status`	Yes

Schema Changelog

Changes observed during successful MCP inspections.

Changed1 schema field changedv0.1.14Oct 15, 2026

addedInput schema / properties / targetRepoId

Added value: +{
+  "description": "Optional linked repo id (project_repos.id) to open the fix PR against, for a project with several repos. Omit for the project's primary repo. Another project's repo id is rejected with 400 TARGET_REPO_NOT_IN_PROJECT.",
+  "format": "uuid",
+  "pattern": "^([0-9a-fA-F]{8}-[0-9a-fA-F]{4}-[1-8][0-9a-fA-F]{3}-[89abAB][0-9a-fA-F]{3}-[0-9a-fA-F]{12}|00000000-0000-0000-0000-000000000000|ffffffff-ffff-ffff-ffff-ffffffffffff)$",
+  "type": "string"
+}

Changed4 schema fields changedv0.1.12Sep 24, 2026

changedInput schema / properties / agent / description

Previous value: -"Override the agent adapter"New value: +"Which agent runs the fix. Omit for the project default (auto); cursor_cloud and github_cloud_agent dispatch a cloud agent."

changedInput schema / properties / agent / enum

Previous value: -[
-  "claude_code",
-  "codex",
-  "rest_worker",
-  "mcp"
-]New value: +[
+  "auto",
+  "claude_code",
+  "codex",
+  "cursor_cloud",
+  "github_cloud_agent",
+  "rest_worker",
+  "rest_fix_worker",
+  "llm",
+  "mcp"
+]

addedInput schema / properties / projectId

Added value: +{
+  "description": "Project UUID — defaults to the configured project. (`project_id` is accepted too.)",
+  "type": "string"
+}

changedInput schema / properties / reportId / description

Previous value: -"Report UUID to fix"New value: +"Report UUID to fix (`report_id` is accepted too.)"

Changed2 schema fields changedv0.1.10Sep 15, 2026

changedInput schema / $schema

Previous value: -"http://json-schema.org/draft-07/schema#"New value: +"https://json-schema.org/draft/2020-12/schema"

changedOutput schema / $schema

Previous value: -"http://json-schema.org/draft-07/schema#"New value: +"https://json-schema.org/draft/2020-12/schema"

Changed2 schema fields changedv0.1.1Jun 25, 2026

addedInput schema / properties / reportId / format
```
Added value: +"uuid"
```

addedInput schema / properties / reportId / pattern

Added value: +"^([0-9a-fA-F]{8}-[0-9a-fA-F]{4}-[1-8][0-9a-fA-F]{3}-[89abAB][0-9a-fA-F]{3}-[0-9a-fA-F]{12}|00000000-0000-0000-0000-000000000000|ffffffff-ffff-ffff-ffff-ffffffffffff)$"

First observedv0.1.0Jun 24, 2026

TDQS

A4.8/5.0

Behavior5/5

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

Annotations only cover the safety profile (openWorld, not readOnly, not idempotent); the description goes well beyond by disclosing the write side effects, the GitHub + LLM key prerequisites, and the idempotencyKey retry semantics (without it each call starts a new attempt). It also states the return shape and that fixId is immediately usable by get_fix_timeline.

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?

Purpose is front-loaded and every clause carries information (prereqs, agent choice, repo targeting, idempotency, next steps). It is dense as a single paragraph, but for a 6-param dispatch tool with many conditional branches the length is largely justified.

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?

Despite an output schema existing, the description covers prerequisites, the required classification precondition, the safe-retry path, and the follow-up workflow (get_fix_timeline, merge_fix). An agent has everything needed to call it correctly on the first attempt.

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 100%, so the schema already documents most parameters. The description still adds value the schema lacks, e.g. that the default agent is the in-repo worker and that targetRepoId exists for multi-repo projects, though much of the targetRepoId/idempotencyKey text duplicates 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?

States a specific verb and resource ('Start a Mushi fix agent for a classified report') plus the concrete side effects it produces (writes a branch, opens a signed draft PR). This clearly distinguishes it from siblings like suggest_fix, submit_fix_result, and merge_fix.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines5/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Explicitly routes the agent: run diagnose_setup mode=dispatch first for prerequisites, run triage_issue if the report isn't classified, set agent=cursor_cloud for a cloud agent, and poll get_fix_timeline then call merge_fix when CI is green. Both when-to-use and named alternatives are present.

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

Deploy Server