Prompt, skill, harness, and fix tools

Prompt management

The prompt tools are the code-first prompt workflow with local file discovery replaced by inline content: prompt bodies travel as arguments, and the returned key → {promptId, versionId} mapping plus content hashes is the lockfile replacement — persist it client-side. moda prompts init, status, and --watch are local-file workflows and stay CLI-only. The prompt tools accept tenant_id where noted, with the same semantics as the fix tools.

prompts_sync

Pushes prompt definitions (content inline) to the Moda prompt registry, minting new versions for changed content, and returns the server’s synced list plus each prompt’s content hash computed with the CLI’s exact canonicalization. The sync is a full push with no explicit delete list: keys absent from prompts are conveyed as implicitly removed, so send the complete set every time.

Arguments

{
  "prompts": [
    {
      "key": "support.triage",
      "name": "Support triage",
      "content": "You are a support triage agent. Classify the request, then...",
      "source_path": "prompts/support/triage.prompt.md"
    }
  ],
  "dry_run": false,
  "source_commit": "9f8e7d6c5b4a39281706f5e4d3c2b1a098765432"
}

Parameter	Type	Default	Description
`prompts`	object[]	required	The full set of prompts to push, content inline (the CLI discovers these from `.moda/prompts.yml` globs). At least one entry.
`prompts[].key`	string	required	Registry key. The CLI derives it from the file path (`prompts/support/triage.prompt.md` → `support.triage`).
`prompts[].content`	string	required	The prompt body text, inline.
`prompts[].name`	string	—	Display name; defaults to the key when omitted (CLI parity).
`prompts[].description`	string	—	Description frontmatter passthrough.
`prompts[].category`	string	—	Category frontmatter passthrough.
`prompts[].system_prompt`	string	—	System prompt (wire: `systemPrompt`).
`prompts[].messages`	array	—	A JSON prompt file’s `messages` array.
`prompts[].variables`	array	—	A JSON prompt file’s `variables` array.
`prompts[].variables_schema`	object	—	Wire: `variablesSchema`.
`prompts[].model_config`	object	—	A JSON prompt file’s `modelConfig` (or `model:` frontmatter; wire: `modelConfig`).
`prompts[].tool_refs`	array	—	Wire: `toolRefs`.
`prompts[].response_schema`	object	—	Wire: `responseSchema`.
`prompts[].source_path`	string	—	Discovered file path, informational only (wire: `sourcePath`).
`dry_run`	boolean	false	Compute what would change without writing registry versions (wire: `dryRun`, always sent).
`source_commit`	string	—	The commit the content came from — the CLI sends `git rev-parse HEAD` automatically (wire: `sourceCommit`; omitted entirely when not provided).

CLI: moda prompts sync

prompts_diff

Previews what a sync would change by running the same POST /prompts/sync with dryRun forced to true — the server-computed replacement for moda prompts status/diff, which compare local file hashes against a local lockfile. Never writes registry versions.

Arguments

{
  "prompts": [
    { "key": "support.triage", "content": "You are a support triage agent. Classify the request, then..." }
  ]
}

Parameter	Type	Default	Description
`prompts`	object[]	required	Same entry shape as `prompts_sync`: the full set of prompts to compare, content inline.
`source_commit`	string	—	Wire: `sourceCommit`; omitted when not provided.

CLI: moda prompts status / diff

prompts_promote

Points a registry label (dev, staging, or prod) at a specific prompt version — the final step after prompts_sync, prompts_ab, or prompts_propose hands you a winning versionId. Promoting overwrites the label’s current assignment, and a prod promotion redirects live traffic immediately, so confirm the version first.

Arguments

{ "prompt_key": "support.triage", "label": "prod", "version_id": "pver_1f2e3d4c5b6a79880911223344556677" }

Parameter	Type	Default	Description
`prompt_key`	string	required	The registry key whose label to move.
`label`	enum	required	`dev`, `staging`, or `prod`.
`version_id`	string	required	The prompt version id to promote (wire: `versionId`).

CLI: moda prompts promote

prompts_ab

Runs a baseline-vs-candidate prompt comparison over a replay set: both arms travel inline as content strings. The replay set comes from at most one of set_id (reuse), conversation_ids (one case per trace), or auto_generate — the default when all three are omitted. MCP-shaped async: wait defaults to false, returning {replaySetId, runId} to poll with replay_run_status. Deliberate deviation from the CLI: promote_primary defaults to false here (the CLI defaults it to true), so a comparison never promotes the winning arm unless explicitly requested.

Arguments

{
  "baseline_content": "You are a support triage agent...",
  "candidate_content": "You are a support triage agent. Confirm the plan tier first...",
  "conversation_ids": ["conv_5e1a9c2b7d3f4680", "conv_8c33d2f1a09b44e7"],
  "seeds_per_case": 3,
  "wait": false
}

Parameter	Type	Default	Description
`baseline_content`	string	required	The baseline (prod arm) prompt text, inline.
`candidate_content`	string	required	The candidate (proposed arm) prompt text, inline.
`baseline_version_id`	string	—	Baseline registry version id from `prompts_sync`; sent as `""` when omitted.
`baseline_prompt_id`	string	—	Baseline registry prompt id; sent as `""` when omitted.
`candidate_version_id`	string	—	Candidate registry version id; sent as `""` when omitted.
`candidate_prompt_id`	string	—	Candidate registry prompt id; sent as `""` when omitted.
`set_id`	string	—	Reuse an existing replay set (no set-creation calls).
`conversation_ids`	string[]	—	Trace IDs. Build a new replay set with one case per trace; each case’s scenario is the trace’s first user message.
`auto_generate`	object	—	Have the server generate replay cases from recent production traffic. The default source when `set_id` and `conversation_ids` are omitted.
`auto_generate.case_count`	integer	—	1–500; default 5 (wire: `caseCount`).
`auto_generate.lookback_days`	integer	—	1–365; default 30 (wire: `lookbackDays`).
`auto_generate.name`	string	—	Replay set name; default `Prompt A/B <YYYY-MM-DD>`.
`seeds_per_case`	integer	3	1–10, materialized like the CLI (wire: `seedsPerCase`).
`assistant_model`	string	—	Assistant model override for the replay (wire: `assistantModel`; omitted when empty).
`promote_primary`	boolean	false	Wire: `promotePrimary`. Deliberate deviation: the CLI defaults to true.
`wait`	boolean	false	`true` polls until the run finishes or `max_wait_seconds` elapses; `false` returns the queued `runId` immediately for `replay_run_status` polling. The CLI defaults to waiting.
`max_wait_seconds`	integer	300	10–600: total seconds to poll before returning the in-flight status with a warning. Only used when waiting.
`poll_interval_seconds`	integer	10	2–60: seconds between polls. Only used when waiting.
`tenant_id`	string	—	Defaults to the tenant embedded in the signed API key.

CLI: moda prompts ab

prompts_propose

Turns a completed A/B run’s failures into a server-generated revised candidate, registered as a new unlabeled prompt version — the CLI’s --out file write becomes the returned content (plus versionId, contentHash, changelog, risks, and repair/holdout case ids). gate: true chains an automatic candidate-vs-baseline replay on the same set: baseline_content is then required inline, and promote_on_win promotes to prod only on a strict candidate win of a completed run. If the gate exceeds max_wait_seconds you get the in-flight status with a warning: finish with replay_run_status, then promote manually with prompts_promote.

Arguments

{ "prompt_key": "support.triage", "from_run_id": "run_9d2e", "set_id": "rset_31ab", "max_dossiers": 8 }

Parameter	Type	Default	Description
`prompt_key`	string	required	The registry key to revise.
`from_run_id`	string	required	The A/B run whose failures seed the revision (wire: `fromRunId`).
`set_id`	string	required	The replay set the run belongs to (wire: `replaySetId`); the gate re-runs this set.
`max_dossiers`	integer	8	1–16: failure dossiers fed to the revision, materialized like the CLI (wire: `maxDossiers`).
`model`	string	—	The revision LLM slug (omitted when empty).
`gate`	boolean	false	Automatically A/B the candidate vs `baseline_content` over the same replay set. Note the gate scores the full replay set — holdout cases cannot be isolated.
`promote_on_win`	boolean	false	Requires `gate: true`: promote the candidate to `prod` only on a strict candidate win of a completed gate run.
`baseline_content`	string	—	Required when `gate: true`: the baseline (prod arm) prompt text, inline — the CLI resolves this from local prompt files.
`seeds_per_case`	integer	3	1–10 (wire: `seedsPerCase`).
`assistant_model`	string	—	Assistant model for the gate run (wire: `assistantModel`; omitted when empty).
`max_wait_seconds`	integer	300	10–600. Only used when the gate waits.
`poll_interval_seconds`	integer	10	2–60. Only used when the gate waits.
`tenant_id`	string	—	Defaults to the tenant embedded in the signed API key.

CLI: moda prompts propose

replay_run_status

Fetches the latest state of a replay-set comparison run — status, per-arm pass counts and rates, per-case results — plus a formatted verdict (strict pass-count delta, same wording as moda prompts ab). Poll it after prompts_ab or prompts_propose returned a queued runId until run.status is completed, skipped, or error.

Arguments

{ "set_id": "rset_31ab", "run_id": "run_9d2e" }

Parameter	Type	Default	Description
`set_id`	string	required	The replay set id the run was enqueued on.
`run_id`	string	—	The `runId` from `prompts_ab`/`prompts_propose`. Sent as `?runId=` only when provided; omit to read the set’s most recent run — which can be someone else’s.
`tenant_id`	string	—	Defaults to the tenant embedded in the signed API key.

CLI: moda prompts ab (the poll step of --wait)

Skills

Moda distills recurring agent behavior into skill files. The MCP skill tools exchange content inline: they return SKILL.md text and accept it as arguments — installing files (.claude/skills/<id>/SKILL.md, .cursor/rules/<id>.mdc) and pruning via .moda/skills.yml is the client’s job.

skills_gen

Kicks off a tenant-wide skill generation run: it clusters recent SDK sessions, distills candidate skills, and optionally replays and improves them. Every option you omit is left to the backend default (the CLI materializes its own defaults client-side; this tool does not). Generation takes minutes — poll skills_status with the returned run id rather than passing wait_for_completion.

Arguments

{
  "source": "sdk",
  "max_sessions": 500,
  "start_at": "2026-08-01T00:00:00Z",
  "end_at": "2026-08-22T00:00:00Z",
  "improve_candidates": true
}

Parameter	Type	Default	Description
`max_sessions`	integer	—	Cap on SDK sessions considered, 1–100,000.
`lookback_hours`	integer	—	Only sessions from the last N hours, 1–8,760.
`start_at`	string	—	ISO 8601 lower bound on session start time.
`end_at`	string	—	ISO 8601 upper bound on session start time.
`clustering_run_id`	string	—	Reuse an existing clustering run instead of starting a new one.
`replay_set_id`	string	—	The replay set used by the replay stage.
`run_clustering`	boolean	—	Inverse of the CLI’s `--no-clustering` (the CLI materializes `true`).
`source`	enum	—	`all` or `sdk` (the CLI materializes `all`; its deprecated coding-agent value is not offered).
`clustering_timeout_seconds`	integer	—	1–86,400 (the CLI materializes 7,200).
`clustering_poll_seconds`	integer	—	1–600 (the CLI materializes 15).
`max_cluster_pct`	number	—	Float cap on a single cluster’s share of sessions (≥ 0; no client-side range).
`reprocess_segments`	boolean	—	The CLI also forces this true when `--force-reprocess` is set; pass both explicitly here.
`run_replay`	boolean	—	Run the replay stage (mirrors `--replay` / `--no-replay`).
`max_traces`	integer	—	Cap on traces replayed, 1–100,000.
`improve_candidates`	boolean	—	Run improvement rounds on candidate skills.
`improvement_rounds`	integer	—	1–10 (the CLI materializes 2).
`force_reprocess`	boolean	—	Reprocess sessions already covered by earlier runs.
`wait_for_completion`	boolean	—	Ask the server to hold the response until the run finishes. Prefer polling `skills_status` — this tool’s transport budget is 120 s.
`tenant_id`	string	—	Defaults to the tenant embedded in the signed API key.

CLI: moda skills gen

skills_status

Reports the status, counters, and outcome of a skill generation run: pass run_id for that run’s detail (including event breadcrumbs), or omit it to read the tenant’s latest run. An unknown run_id returns found: false with a warning rather than an error.

Arguments

{ "run_id": "51f2b3a4-9c8d-4e7f-a1b2-c3d4e5f6a7b8" }

Parameter	Type	Default	Description
`run_id`	string	—	A `generation_run_id` from `skills_gen`. Omit to read the tenant’s latest run.

CLI: moda skills status

skills_list

Fetches the tenant’s generated skills with their full SKILL.md content. This is the server half of moda skills pull: it returns content only — writing files is the client’s job.

Arguments

{ "status": "proposed" }

Parameter	Type	Default	Description
`status`	enum	`approved`	`approved`, `proposed`, or `all`. Always sent on the wire, like the CLI.

CLI: moda skills pull

skills_push

Pushes user-authored skills (SKILL.md content inline) to the Moda skill registry, minting new versions for changed content. This is moda skills sync with local .claude/skills/**/SKILL.md discovery replaced by arguments; the CLI’s managed AGENTS.md upsert is a local file write and stays CLI-only. Unchanged content is a server-side no-op.

Arguments

{
  "skills": [
    {
      "key": "handle-refund-retries",
      "name": "Handle refund retries",
      "skill_md": "---\nname: Handle refund retries\n---\nWhen a refund tool call fails, never retry with identical arguments...",
      "source_path": ".claude/skills/handle-refund-retries/SKILL.md"
    }
  ],
  "dry_run": true
}

Parameter	Type	Default	Description
`skills`	object[]	required	The user-authored skills to push (the CLI discovers these under `.claude/skills/`, excluding Moda-managed ones). At least one entry.
`skills[].key`	string	required	The skill key (the CLI derives it from the `.claude/skills/<key>/` directory name).
`skills[].name`	string	required	Display name (the CLI reads SKILL.md frontmatter, falling back to the key).
`skills[].skill_md`	string	required	The full SKILL.md content, inline (wire: `skillMd`).
`skills[].description`	string	—	SKILL.md description frontmatter.
`skills[].source_path`	string	—	The discovered file path (wire: `sourcePath`).
`skills[].content_hash`	string	—	Wire: `contentHash`. Computed as sha256 hex of `skill_md` when omitted (CLI-exact).
`skills[].source_commit`	string	—	Per-skill `sourceCommit`; defaults to the top-level `source_commit`.
`dry_run`	boolean	false	Compute what would change without writing registry versions (wire: `dryRun`, always sent).
`source_commit`	string	—	Wire: `sourceCommit`; omitted entirely when not provided.

CLI: moda skills sync

skills_proposals

Lists skill proposals — PR-ready skill candidates produced by generation runs — with their status and metadata. status defaults to ready_for_pr on the wire exactly like the CLI, and status: "all" drops the filter entirely.

Arguments

{ "status": "ready_for_pr" }

Parameter	Type	Default	Description
`status`	string	`ready_for_pr`	For example `ready_for_pr`. Materialized on the wire like the CLI; `all` omits the filter.
`generation_run_id`	string	—	Only proposals from that `skills_gen` run (wire: `generationRunId`).
`tenant_id`	string	—	Mirrors `--tenant-id` (wire: `tenantId`); omitted when not provided, so the API key’s tenant applies.

CLI: moda skills proposals

skills_proposal

Fetches a single skill proposal including its full SKILL.md content. This is the fetch half of moda skills proposal apply: the client applies the content itself (write the file, or adapt it for another agent), then acknowledges with skills_proposal_mark_applied.

Arguments

{ "proposal_id": "sp_7c1d9e2f4a6b8035" }

Parameter	Type	Default	Description
`proposal_id`	string	required	A proposal id from `skills_proposals`.
`tenant_id`	string	—	Mirrors `--tenant-id` (wire: `tenantId`); omitted when not provided, so the API key’s tenant applies.

CLI: moda skills proposal apply (fetch step)

skills_proposal_mark_applied

Acknowledges that a skill proposal’s content has been applied client-side, moving it out of the ready queue (the request records appliedBy: "moda-mcp"; the CLI sends moda-cli). Call it only after the client actually wrote the SKILL.md fetched with skills_proposal — marking without applying loses the reminder that the proposal is pending.

Arguments

{ "proposal_id": "sp_7c1d9e2f4a6b8035" }

Parameter	Type	Default	Description
`proposal_id`	string	required	The proposal id that was fetched with `skills_proposal` and applied client-side.
`tenant_id`	string	—	Mirrors `--tenant-id` (wire: `tenantId`); omitted when not provided, so the API key’s tenant applies.

CLI: moda skills proposal apply (mark-applied step)

Harness

The harness tools cover the server-side halves of the harness workflow: uploading, deleting, and reading hosted analysis runs. Producing the graph and report requires the local repo, so moda harness scan/analyze/approve/validate-report stay CLI-side.

harness_sync

Uploads a harness graph — and optionally an approved analysis report (the CLI’s --from-report form) — to the tenant’s harness registry. The backend’s 2,000,000-byte graph limit is enforced client-side before the POST, and dry_run previews without writing.

Arguments

{
  "graph": { "agents": [{ "id": "agent_support" }], "artifacts": [] },
  "graph_hash": "b41f0c2a9e7d5f3186c4a2e0d8b6f4a2",
  "source_commit": "9f8e7d6c5b4a39281706f5e4d3c2b1a098765432",
  "dry_run": true
}

Parameter	Type	Default	Description
`graph`	object	—	The harness graph from local `moda harness scan`/`analyze` (`.moda/harness.json`). Required unless `report` is given.
`graph_hash`	string	—	The graph hash computed by the local scan (wire: `graphHash`).
`source_commit`	string	—	Wire: `sourceCommit`; omitted when not provided.
`dry_run`	boolean	false	Validate server-side without writing (wire: `dryRun`, always sent).
`report`	object	—	The approved `.moda/harness-report.json` content (wire: `report`). The CLI refuses unapproved reports unless `--dry-run`.
`report_hash`	string	—	Wire: `reportHash`.
`report_validation_status`	string	—	The local `moda harness validate-report` outcome, for example `pass` (wire: `reportValidationStatus`).
`report_approval`	object	—	The recorded approval object keyed to the report hash, from `moda harness approve` (wire: `reportApproval`).

CLI: moda harness sync

harness_delete

Permanently deletes a harness from the tenant — including every synced version, agent, artifact, and relationship under it — and returns the server’s deleted counts. There is no undo, which is why the CLI demands --yes and this tool demands confirm: true.

Arguments

{ "id_or_key": "my-harness-key", "confirm": true }

Parameter	Type	Default	Description
`id_or_key`	string	required	The harness to delete (the CLI’s positional, also `--harness`).
`confirm`	boolean	required	Must be `true` to delete. The deletion cannot be undone.

CLI: moda harness delete

harness_analyze_status

Reads the status, progress, and (when completed) results of a hosted harness analysis run. Starting a remote analysis requires a source snapshot built from the local repo, so kicking one off is CLI-only (moda harness analyze --remote prints the run id this tool takes); this is the read half that moda harness pull uses. Server-controlled progress strings are sanitized of ANSI/control characters before being returned.

Arguments

{ "run_id": "8a4f2c6e-1b3d-4590-9e7f-a2c4e6081b3d" }

Parameter	Type	Default	Description
`run_id`	string	required	The hosted analysis run id (the CLI persists it in `.moda/harness-remote-run.json`).

CLI: moda harness pull

Additional CLI parity entries

MCP tool	CLI command	Toolset	Writes?
`prompts_sync`	`moda prompts sync`	prompts	Yes
`prompts_diff`	`moda prompts diff`	prompts	No
`prompts_promote`	`moda prompts promote`	prompts	Yes
`prompts_ab`	`moda prompts ab`	prompts	Yes
`prompts_propose`	`moda prompts propose`	prompts	Yes
`replay_run_status`	`moda prompts ab --wait` (poll step)	prompts	No
`skills_gen`	`moda skills gen`	skills	Yes
`skills_status`	`moda skills status`	skills	No
`skills_list`	`moda skills pull`	skills	No
`skills_push`	`moda skills sync`	skills	Yes
`skills_proposals`	`moda skills proposals list`	skills	No
`skills_proposal`	`moda skills proposal apply` (fetch step)	skills	No
`skills_proposal_mark_applied`	`moda skills proposal apply` (mark-applied step)	skills	Yes
`harness_sync`	`moda harness sync`	harness	Yes
`harness_delete`	`moda harness delete`	harness	Yes
`harness_analyze_status`	`moda harness pull`	harness	No

CLI-only commands

Command	Why it stays CLI-only	MCP alternative
`moda harness scan/analyze/approve/validate-report/agents/graph/explain/status`	Scans the local repo and writes `.moda/*` artifacts.	`harness_sync` uploads a locally produced graph; `harness_analyze_status` reads a hosted analysis run.
`moda prompts init/status/diff --watch`	Local manifest/lockfile scaffolding.	`prompts_diff`, or `prompts_sync` with `dry_run: true`, for a server-computed diff.
`moda skills pull` file writes	The MCP tools return content; writing files is the client’s job.	`skills_list` and `skills_proposal` return the content to write.

Deliberate deviations

Area	MCP server	CLI
`prompts_ab` / `prompts_propose` waiting	`wait` defaults to `false`: returns the queued `runId` to poll with `replay_run_status`; `wait: true` polls up to `max_wait_seconds`.	Blocks until the run finishes (up to 2 h) unless `--no-wait`.

Fixes

A Fix pairs a candidate change with a replay-gate verdict on held-out production evidence — see Fixes in the dashboard for concepts. The pipeline is advance-on-poll: nothing progresses server-side between requests, so wait: true and fixes_drive drive the pipeline rather than merely watch it. All fix tools accept tenant_id (string, optional): the tenant to operate on, defaulting to the tenant embedded in the signed API key — required only for legacy unsigned keys. Fix mutations are sent exactly once, never retried.

fixes

Lists the tenant’s ranked queue of Fixes (id, MODA-FIX short ref, status, fix type, status reason) with cursor pagination, optionally filtered by status. An empty queue means nothing is drafted yet — create fixes with fix_start or fixes_draft_batch.

Arguments

{ "status": "VERIFIED", "limit": 10 }

Parameter	Type	Default	Description
`status`	string	—	Raw status filter passed through to the backend (for example `PROPOSED`, `VERIFIED`, `GATE_FAILED`). Omit for every status.
`limit`	integer	—	Page size, 1–100; the backend default applies when omitted.
`cursor`	string	—	Opaque pagination token from `pagination.next_cursor` (raw string, never number-coerced).
`tenant_id`	string	—	See area note above.

fixes_draft_batch

Batch-drafts Fixes for the tenant’s top-ranked fixable problems in one server-side call (the backend scans up to 100 ranked problems) and returns the drafted fixes plus per-problem skip reasons. Creation only — drive the drafted fixes with fixes_drive afterwards.

Arguments

{ "limit": 10 }

Parameter	Type	Default	Description
`limit`	integer	—	Batch size, 1–25 (the backend’s LLM spend guard); backend default 10 when omitted.
`tenant_id`	string	—	See area note above.

fixes_drive

Snapshots the fix queue and round-robins one advance step per active fix per pass — fair progress, so a slow gate never starves the others. Bounded: it runs at most max_passes passes per call and reports stragglers — call it again to continue. coverage_truncated plus warnings report when the snapshot could not be proven complete, with the exact remedy for each case.

Arguments

{ "status": "GATING", "max_passes": 3, "pass_interval_seconds": 5 }

Parameter	Type	Default	Description
`status`	string	—	Must be one of the advancing statuses `DRAFT`, `SCOPING`, `PROPOSING`, `PROPOSED`, `GATING` (uppercased before the wire). Narrows the server-side scan window — the only way to reach an advancing fix older than the unfiltered window.
`max_passes`	integer	3	Passes this call runs, 1–10.
`pass_interval_seconds`	integer	5	Seconds between passes, 0–30.
`tenant_id`	string	—	See area note above.

fix

Reads one Fix — status, gate result, candidate ref, PR info — and, with wait: true, drives the advance-on-poll pipeline (each poll POSTs one advance step, so wait turns the read into a write). Waiting stops at a resting status or at max_wait_seconds, returning the current state with a timed-out warning — call again to continue. data.next_steps points at the status-appropriate follow-up tool.

Arguments

{ "fix_id": "cme9y2k1q0001l708g6p4xw3v", "wait": true, "max_wait_seconds": 300 }

Parameter	Type	Default	Description
`fix_id`	string	required	The fix to operate on (raw string, never number-coerced).
`wait`	boolean	false	Drive the pipeline while the fix is in an advancing status (`DRAFT`/`SCOPING`/`PROPOSING`/`PROPOSED`/`GATING`). Default is a pure read.
`max_wait_seconds`	integer	120	10–600: total wait budget.
`poll_interval_seconds`	integer	5	2–60: sleep between advance steps while the fix is `GATING`.
`tenant_id`	string	—	See area note above.

fix_start

Drafts a Fix for one problem and, with wait: true, drives scope → propose → gate to a resting status, attaching the fix packet fail-soft. Without wait it returns the drafted fix immediately — advance it later with fix (wait: true) or fixes_drive.

Arguments

{ "problem_id": "3f6b0a52-9d1c-4e7a-b2f8-6c0d5e4a3b21", "type": "auto", "wait": true }

Parameter	Type	Default	Description
`problem_id`	string	required	The problem to draft a fix for (raw string, never number-coerced).
`type`	enum	—	`auto` or `prompt`, sent as body `fixType`; omitted → backend default routing.
`wait`	boolean	false	Drive the pipeline to a resting status and attach the packet fail-soft.
`max_wait_seconds`	integer	120	10–600: total wait budget.
`poll_interval_seconds`	integer	5	2–60: sleep between advance steps.
`tenant_id`	string	—	See area note above.

fix_packet

Fetches the moda.fix_packet.v1 document for a fix verbatim — diagnosis, evidence, and any candidate blocks (tool-description rewrite, drafted SKILL.md, or a minimal skill edit), also surfaced as findings. This server writes no files: write the candidate text from the packet payload yourself if you want a diffable copy, then confirm with fix_mark_applied.

Arguments

{ "fix_id": "cme9y2k1q0001l708g6p4xw3v" }

Parameter	Type	Default	Description
`fix_id`	string	required	The fix whose packet to fetch.
`tenant_id`	string	—	See area note above.

fix_verify

Enqueues a gate + control run for a fix’s candidate — the stored one, or an inline replacement via candidate_content — then by default drives advance-on-poll until the gate verdict lands. VERIFIED with a pass verdict succeeds; GATE_FAILED returns an error with best-effort per-case findings for the fail-to-pass loop; anything else (inconclusive, blocked, a lapsed wait) is degraded, never a pass. A concurrent verify can supersede this run — a warning flags when the reported verdict belongs to a different gate run.

Arguments

{
  "fix_id": "cme9y2k1q0001l708g6p4xw3v",
  "candidate_content": "You are a support triage agent. Confirm the user's plan tier before quoting refund policy, and never retry a failed refund tool call with identical arguments.",
  "wait": true
}

Parameter	Type	Default	Description
`fix_id`	string	required	The fix to gate.
`candidate_content`	string	—	Inline replacement candidate (the API never sees a path). Trimmed length must be ≥ 40 characters. Omit to re-gate the stored candidate.
`wait`	boolean	true	The inverse of `--no-wait`: drive advance-on-poll to the gate verdict. Pass `false` to only enqueue (returns `gateRunId`; resume with the `fix` tool, `wait: true`).
`max_wait_seconds`	integer	120	10–600: total wait budget.
`poll_interval_seconds`	integer	5	2–60: sleep between advance steps.
`tenant_id`	string	—	See area note above.

fix_checkout

Resolves a prompt fix’s candidate content and returns everything a local checkout needs: the target path, the full candidate text, the branch convention (moda/fix/<shortref-lowercase>), the PR magic word (Fixes MODA-FIX-<SHORTREF>), and the candidate version id. This server writes nothing — you write content to path and run git yourself. It refuses artifact fixes (TOOL_SCHEMA/SKILL — use fix_packet + fix_mark_applied) and fixes without a proposed candidate, with the recovery path in each error.

Arguments

{ "fix_id": "cme9y2k1q0001l708g6p4xw3v" }

Parameter	Type	Default	Description
`fix_id`	string	required	The fix whose candidate to resolve.
`tenant_id`	string	—	See area note above.

fix_submit

Hands a fix back for delivery: channel pr has the backend open the draft PR (the response carries prUrl/prBranch — no local git anywhere), while channel local_ref records your own branch name server-side so landing it with the magic word in the PR body confirms the fix via the merge webhook.

Arguments

{ "fix_id": "cme9y2k1q0001l708g6p4xw3v", "channel": "local_ref", "local_ref": "moda/fix/7q2wjx4m" }

Parameter	Type	Default	Description
`fix_id`	string	required	The fix to deliver.
`channel`	enum	required	`pr` or `local_ref` — exactly one delivery channel.
`local_ref`	string	—	Your branch name. Required when `channel: "local_ref"`, forbidden with `pr`.
`tenant_id`	string	—	See area note above.

fix_mark_applied

Confirms you applied a fix’s candidate in your own infrastructure — the no-GitHub delivery path: the fix flips straight to SHIPPED, mark_fixed feedback is posted, and the problem enters fixed-monitoring (HELD after 14 clean days, REGRESSED on reopen). Idempotent server-side: repeating it on a confirmed fix is a duplicate no-op flagged as a warning.

Arguments

{ "fix_id": "cme9y2k1q0001l708g6p4xw3v", "note": "tool description updated in our agent config" }

Parameter	Type	Default	Description
`fix_id`	string	required	The fix to confirm.
`note`	string	—	Where/how you applied the candidate, trimmed, max 600 characters.
`tenant_id`	string	—	See area note above.

fix_dismiss

Dismisses a fix with a required reason, recorded as problem feedback that steers future drafting and ranking. Destructive — dismissal removes it from the active queue; prefer fix_mark_applied when you actually shipped the change.

Arguments

{ "fix_id": "cme9y2k1q0001l708g6p4xw3v", "reason": "not the right lever; fixing the API enum instead" }

Parameter	Type	Default	Description
`fix_id`	string	required	The fix to dismiss.
`reason`	string	required	Non-empty; recorded as problem feedback.
`tenant_id`	string	—	See area note above.

Fix tools

MCP tool	Toolset	Writes?
`fixes`	fixes	No
`fixes_draft_batch`	fixes	Yes
`fixes_drive`	fixes	Yes
`fix`	fixes	With `wait: true`
`fix_start`	fixes	Yes
`fix_packet`	fixes	No
`fix_verify`	fixes	Yes
`fix_checkout`	fixes	Yes
`fix_submit`	fixes	Yes
`fix_mark_applied`	fixes	Yes
`fix_dismiss`	fixes	Yes

fix is a pure read by default; wait: true turns each poll into an advance POST — the only thing that moves a fix through the pipeline — which is why it is not annotated read-only. fix_checkout performs no server-side write itself, but it is deliberately not annotated read-only so clients gate the checkout-and-deliver flow behind approval.

Fix timeout budgets

Call family	Budget
Fix pipeline advance steps (`fix`/`fix_start`/`fix_verify` polling, `fixes_drive`), `fixes_draft_batch`	300 s
`fix_start` create, `fix_verify` enqueue, `fix_submit`	120 s
`fix_mark_applied`, `fix_dismiss`, replay comparison reads	60 s

​Prompt management

​prompts_sync

​prompts_diff

​prompts_promote

​prompts_ab

​prompts_propose

​replay_run_status

​Skills

​skills_gen

​skills_status

​skills_list

​skills_push

​skills_proposals

​skills_proposal

​skills_proposal_mark_applied

​Harness

​harness_sync

​harness_delete

​harness_analyze_status

​Additional CLI parity entries

​CLI-only commands

​Deliberate deviations

​Fixes

​fixes

​fixes_draft_batch

​fixes_drive

​fix

​fix_start

​fix_packet

​fix_verify

​fix_checkout

​fix_submit

​fix_mark_applied

​fix_dismiss

​Fix tools

​Fix timeout budgets

Prompt management

prompts_sync

prompts_diff

prompts_promote

prompts_ab

prompts_propose

replay_run_status

Skills

skills_gen

skills_status

skills_list

skills_push

skills_proposals

skills_proposal

skills_proposal_mark_applied

Harness

harness_sync

harness_delete

harness_analyze_status

Additional CLI parity entries

CLI-only commands

Deliberate deviations

Fixes

fixes

fixes_draft_batch

fixes_drive

fix

fix_start

fix_packet

fix_verify

fix_checkout

fix_submit

fix_mark_applied

fix_dismiss

Fix tools

Fix timeout budgets