Mushi-Mushi

Open a CI cost fix PR (draft)

open_ci_cost_fix

Open a draft pull request that applies one CI cost autofix to a workflow file, then track the job until merge to measure daily savings.

Instructions

Open a DRAFT pull request that applies one CI cost fix to one workflow file (ADR 0047), the fix a CI advice item offers as autofix (get_ci_overview / get_ci_costs advice[].autofix { kind, projectId, repo, workflowPath }). kind: add_concurrency (a concurrency group that cancels superseded pull request runs, never a push), skip_drafts (ready_for_review added to the pull_request types and every job skips drafts), weekly_cron (a schedule that fires more than weekly runs once a week), ignore_docs_paths (paths-ignore for docs-only changes, Markdown, docs/, license and issue templates, on pull_request and push; refused when a job looks like a required check, because a skipped workflow never reports and the PR could not merge). The repo must be connected to the project. Mushi reads the workflow from the default branch, edits only that file (comments kept), opens the PR as a draft with a conventional ci: title, and records the workflow's billed minutes per day for the 14 days before; nothing changes until a person reviews, readies and merges it. The job runs in the background: read it again with the job id (GET /v1/admin/ci/cost-fixes/{id}, or mushi runner fix-status); after the merge it shows the saving measured per day. Writing a workflow file needs the GitHub App's Workflows: Read and write permission or a token with the workflow scope. Confirm with the user first. Returns { job: { id, status (queued | running | pr_opened | no_change | refused | failed), summary, errorCode, error, prUrl, baseline, measured, saving } }, or an error (REPO_NOT_IN_PROJECT, PR_ALREADY_OPEN with the job, COST_FIX_IN_PROGRESS, RATE_LIMITED: 10 an hour per project). Write.

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>",
      "workflowPath": "<workflowPath>",
      "kind": "<kind>"
    },
    "name": "open_ci_cost_fix"
  }
}

Input Schema

Name	Required	Description
`kind`	Yes	The fix (advice[].autofix.kind)
`repo`	Yes	owner/repo, connected to the project
`projectId`	No	Project UUID — defaults to the server-configured project (`project_id` is accepted too.)
`workflowPath`	Yes	The workflow file, e.g. .github/workflows/ci.yml

Schema Changelog

Changes observed during successful MCP inspections.

Addedv0.1.19Oct 29, 2026

TDQS

A4.2/5.0

Behavior5/5

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

Far exceeds the annotations: it discloses that the operation is asynchronous with a pollable job id, lists the terminal statuses and error codes (REPO_NOT_IN_PROJECT, PR_ALREADY_OPEN, COST_FIX_IN_PROGRESS), states a rate limit of 10 per hour per project, and explains the refusal path for ignore_docs_paths when a job looks like a required check. Critically, it reassures that nothing changes until a human readies and merges, consistent with destructiveHint=false.

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?

The key framing is front-loaded in the first clause, but the body is a single dense paragraph with stacked parentheticals that is hard to scan, and the trailing 'Write.' is a stray word. Almost every fact earns its place, but the structure works against quick comprehension of a fairly complex operation.

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 mutating, asynchronous, externally-side-effecting tool with no output schema, the description covers the return shape inline ({ job: { id, status, summary, prUrl, baseline, measured, saving } }), how to poll it, permission requirements, rate limits and failure modes. Nothing an agent needs to call or follow up correctly 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 already 100%, so the baseline is 3, but the description adds real meaning beyond the enum: it explains what each kind actually does (add_concurrency never applies to push, skip_drafts adds ready_for_review plus job-level skips, weekly_cron collapses more-than-weekly schedules, ignore_docs_paths lists the exact ignore set and its refusal case). The repo/projectId linkage is restated but not deepened much beyond the schema.

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 names a specific verb, artifact and scope: 'Open a DRAFT pull request that applies one CI cost fix to one workflow file.' It also states where the fix originates (get_ci_overview / get_ci_costs advice[].autofix). It does not, however, explicitly distinguish itself from close siblings like preview_ci_cost_fix_rollout, apply_ci_cost_fix_rollout or get_ci_cost_fix_bundle, which an agent must still disambiguate on its own.

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?

Gives concrete preconditions: the repo must be connected to the project, the caller needs Workflows: Read and write permission or a workflow-scope token, and 'Confirm with the user first.' It also clarifies the fix is the one advice items expose as autofix. It stops short of naming an alternative tool or saying when not to use this one (e.g. previewing a rollout first).

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

Deploy Server