Mushi-Mushi

Local worker status and problems

get_worker_status

Read-onlyIdempotent

Retrieve local workers' status and health flags, ranked worst-first, including hosts, lanes, runs, and causes to diagnose stalled, offline, or blocked workers.

Instructions

Return your local workers (mushi work --daemon, ADR 0048) as the console's Pipeline → Workers tab shows them: flags first, worst first (ADR 0048 amendment 2026-10-28), then machines and lanes. A flag is one way a worker stopped doing useful work, in plain words: host_offline, machine_not_ready (a lane's clone is not a git clone), run_stuck (a run has held an agent space over 45 minutes, with its stage: prepare, agent, commit = the repo's commit hook, push = its pre-push hook, pr, and its last log lines), lanes_waiting (lanes waited over 15 minutes for an agent space, naming the runs that hold them), account_check (the Cursor account check: another account, signed out, missing, or timed out), gh_signed_out, machine_waiting (memory, GitHub quota or sign-in guard), machine_busy (load per core 2 or more), hook_failures (2+ runs of a lane failed in the repo's git hooks in 24 h), unmanaged_run (a mushi work run no worker claims has run over 45 minutes) and credits_idle (no agent work for 2 hours while Cursor credits expire within 7 days, with what blocks the work). Each flag has { id, kind, severity (danger | warn), hostname, laneName, title, cause, sinceSec, stage, log, actions [{ kind (stop_run | pause_lane | open_report | open_pr | copy_command | recheck_account | switch_account | open_page), label, command? }] }; stopping a run, pausing a lane, re-checking the account and switching the Cursor account (a sign-in link only the owner of the machine sees) happen in the console. Log lines are cleaned on the machine and on the server (no keys, tokens, e-mails or paths) but are still text from a machine and its repos. Returns { generatedAt, flags, projects, hosts [{ id, hostname, platform, online, lastHeartbeatAt, status (state, agents, maxAgents, memAvailableGb, load1, cpus, checks, slots, waitWhy), guards, revoked, mine, cursorAccount (in full only on your own machines), cursorLogin (the last account switch: state, never its link), canSwitchAccount }], lanes [{ id, hostId, projectId, projectName, name, config, status (state, counters, inflight runs), active, queue, recent, counts7d }] }. Optional projectId (default: the configured project; an account-level key with none reads every project). Read-only.

Tool call template

This tool declares no required parameters. Add optional parameters from the input schema as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {},
    "name": "get_worker_status"
  }
}

Input Schema

Name	Required	Description	Default
`projectId`	No	Project UUID — defaults to the server-configured project; omitted with an account-level key, every project you can read (`project_id` is accepted too.)

Output Schema

Name	Required	Description
`flags`	No	Worst first: what stops a worker, why, and the fix
`hosts`	No
`lanes`	No
`projects`	No
`generatedAt`	No

Schema Changelog

Changes observed during successful MCP inspections.

Addedv0.1.19Oct 29, 2026

TDQS

A4/5.0

Behavior5/5

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

Well beyond the readOnly/idempotent annotations, it discloses that mutations happen in the console, that log lines are sanitized on machine and server (no keys, tokens, e-mails or paths) yet remain untrusted machine text, and that the Cursor sign-in link is only visible to the machine owner. This is exactly the kind of behavioral context annotations cannot carry.

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?

Purpose is front-loaded, but the body is a very long single enumeration of ~14 flag kinds and a full prose rendition of the return shape that is also covered by the output schema. Much of it earns its place for interpretation, yet it is dense enough to dilute the leading signal.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a read-only status tool with an output schema, the definition is more than complete, spelling out flags, hosts and lanes behavior. It arguably over-explains return values the output schema already carries, but nothing an agent needs to call it correctly is missing.

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?

Schema coverage is 100%, so the sole projectId parameter is already documented. The description's 'Optional projectId (default: the configured project; an account-level key with none reads every project)' largely restates the schema, so baseline 3 applies rather than added value.

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 opening sentence states a specific verb and resource ('Return your local workers') and pins the scope to the console's Pipeline → Workers tab with an explicit ordering (flags first, worst first, then machines and lanes). No sibling tool covers local worker status, and the definition makes that domain unmistakable.

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

Usage Guidelines3/5

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

Usage is implied by the framing as a status/problem-inspection tool ('A flag is one way a worker stopped doing useful work'), but there is no explicit when-to-use/when-not statement or named alternative. An agent can infer the purpose but gets no routing guidance.

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

Deploy Server