Mushi-Mushi

Record a fix outcome

submit_fix_result

Submit an externally completed fix by providing branch, PR URL, files changed, and lines modified to attach the fix attempt to a bug report and mark it as done.

Instructions

Record a fix outcome from an external agent (e.g. your own Cursor/Claude run): branch, PR URL, files changed, lines added/removed. Creates a fix_attempt row then patches it to completed and links it to the report. Returns { fixAttemptId }. Write; NOT idempotent — each call creates a new fix_attempt, so call once per PR. Use after you opened a PR outside Mushi; use dispatch_fix to have Mushi open the PR instead, or merge_fix once CI is green.

Input Schema

TableJSON Schema

Name	Required	Description
`prUrl`	No	GitHub pull request URL, if a PR was opened (`pr_url` is accepted too.)
`branch`	Yes	Git branch name where the fix was implemented
`summary`	Yes	One-line human summary of what the fix changed
`reportId`	Yes	Report UUID to attach this external fix attempt to (`report_id` is accepted too.)
`filesChanged`	Yes	Repo-relative paths modified by the fix
`linesChanged`	Yes	Total lines added + removed across filesChanged
`idempotencyKey`	No	Optional UUID — resend the same key to safely retry without creating duplicate fix rows. Omit it and a stable key is derived from reportId + branch + prUrl, so a retried submission carries the identical key instead of a fresh random one.

Output Schema

TableJSON Schema

Name	Required	Description	Default
`ok`	Yes	True when the fix_attempt row was created and marked completed
`fixId`	Yes	UUID of the new fix_attempt row

Schema Changelog

Changes observed during successful MCP inspections.

Changed2 schema fields changedv0.1.12Sep 24, 2026

changedInput schema / properties / prUrl / description

Previous value: -"GitHub pull request URL, if a PR was opened"New value: +"GitHub pull request URL, if a PR was opened (`pr_url` is accepted too.)"

changedInput schema / properties / reportId / description

Previous value: -"Report UUID to attach this external fix attempt to"New value: +"Report UUID to attach this external fix attempt to (`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"

Changed1 schema field changedv0.1.9Aug 21, 2026

changedInput schema / properties / idempotencyKey / description

Previous value: -"Optional UUID — resend the same key to safely retry without creating duplicate fix rows"New value: +"Optional UUID — resend the same key to safely retry without creating duplicate fix rows. Omit it and a stable key is derived from reportId + branch + prUrl, so a retried submission carries the identical key instead of a fresh random one."

Changed7 schema fields changedv0.1.2Jun 28, 2026

changedInput schema / properties / branch / description

Previous value: -"Git branch name"New value: +"Git branch name where the fix was implemented"

changedInput schema / properties / filesChanged / description

Previous value: -"Files modified"New value: +"Repo-relative paths modified by the fix"

changedInput schema / properties / linesChanged / description

Previous value: -"Total lines changed"New value: +"Total lines added + removed across filesChanged"

changedInput schema / properties / prUrl / description

Previous value: -"GitHub PR URL"New value: +"GitHub pull request URL, if a PR was opened"

changedInput schema / properties / reportId / description

Previous value: -"The report UUID"New value: +"Report UUID to attach this external fix attempt to"

changedInput schema / properties / summary / description

Previous value: -"Fix summary"New value: +"One-line human summary of what the fix changed"

changedOutput schema / (root)

Previous value: -nullNew value: +{
+  "$schema": "http://json-schema.org/draft-07/schema#",
+  "additionalProperties": false,
+  "properties": {
+    "fixId": {
+      "description": "UUID of the new fix_attempt row",
+      "type": "string"
+    },
+    "ok": {
+      "description": "True when the fix_attempt row was created and marked completed",
+      "type": "boolean"
+    }
+  },
+  "required": [
+    "ok",
+    "fixId"
+  ],
+  "type": "object"
+}

First observedv0.1.0Jun 24, 2026

TDQS

A4.7/5.0

Behavior5/5

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

The description reveals internal behavior beyond annotations: it creates a fix_attempt row, patches it to completed, links it to the report, and returns a fixAttemptId. It explicitly flags the write nature and non-idempotence, and explains the idempotency key mechanism and its default derivation. This goes well beyond the annotation hints and gives the agent a realistic model of side effects.

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 two sentences, front-loaded with the core purpose, and packs essential usage guidance and behavioral context into a compact space. No filler or redundant phrasing; every clause 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 tool with 7 parameters and a required output, the description covers the invocation trigger, the side effects, the return value, idempotency caveats, and sibling alternatives. Combined with a fully described schema and an output schema, an agent has everything needed to call it correctly.

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?

The input schema has 100% coverage with detailed descriptions for every parameter, including the nuanced idempotencyKey behavior. The description merely lists field names without adding new semantic meaning; it reinforces the overall purpose but does not clarify any parameter beyond what the schema already provides. Baseline 3 applies since the schema carries the load.

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 ('Record') and resource ('fix outcome from an external agent'), lists the exact fields involved (branch, PR URL, files changed, lines added/removed), and immediately distinguishes it from sibling tools by naming dispatch_fix and merge_fix as alternatives. This leaves no ambiguity about what the tool does and how it differs from related operations.

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?

It gives an explicit condition for use: 'Use after you opened a PR outside Mushi.' It then states clear alternatives: 'use dispatch_fix to have Mushi open the PR instead, or merge_fix once CI is green.' It also adds a critical usage warning about idempotency ('call once per PR'), which is exactly the kind of guidance an agent needs to avoid mistakes.

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