MCP reporting tools
Jarvis injects a small set of worker-facing MCP reporting tools into supported coding runtimes so sessions can report what matters without dumping raw tool output into the main chat.
Definition
Section titled “Definition”MCP reporting tools are the worker-to-human signaling channel in Jarvis. They let a coding session push structured updates back into the main chat when the worker makes progress, gets blocked, needs a decision, or requires more context.
The core tools are:
report_progressnotify_blockedask_humanrequest_context
Why It Exists
Section titled “Why It Exists”Most coding runtimes already know how to work. What they lack is a clean way to supervise that work from outside the terminal.
Jarvis adds MCP reporting tools so workers can:
- report meaningful milestones without streaming everything
- escalate blockers as soon as they happen
- ask one precise human question instead of failing silently
- request missing context without forcing the operator to guess
This makes the main chat useful as a control plane instead of a transcript archive.
How It Works
Section titled “How It Works”When Jarvis launches or configures a supported worker session, it makes the reporting tools available inside that runtime. The worker can then call them directly as part of normal execution.
Tool Roles
Section titled “Tool Roles”| Tool | Purpose | Typical moment |
|---|---|---|
report_progress |
Send a concise update about completed or in-progress work | A milestone was reached or a branch of work finished |
notify_blocked |
Mark the session as blocked and explain why | The worker cannot continue safely without intervention |
ask_human |
Ask for a decision or missing instruction | There are multiple valid paths and the worker needs a choice |
request_context |
Ask for extra files, history, or external facts | The worker lacks context needed to continue |
Human Decision and Blocker Flow
Section titled “Human Decision and Blocker Flow”The normal escalation loop looks like this:
- A worker notices it cannot continue confidently.
- It calls
notify_blocked,ask_human, orrequest_context. - Jarvis inserts that report into the main chat in a structured, readable form.
- The operator reviews the question or blocker.
- The operator responds by answering the question, providing context, or dispatching the next instruction.
- The worker session resumes, and later progress is reflected in MCP reports and summary capsules.
This flow is one of the main reasons Jarvis can supervise multiple sessions without turning every worker into a manual babysitting job.
Failure Modes
Section titled “Failure Modes”The reporting channel is reliable enough for supervision, but it is still a separate signal path:
- Tool not available: a runtime may be visible in Jarvis but not currently configured for active reporting.
- Worker does not call the tool: a session can keep running silently if its prompts or workflow never emit a report.
- Report arrives late: a session state may have changed by the time you read the message.
- Question is underspecified: a vague
ask_humanrequest can still require you to open the session and inspect the surrounding work.
Because of that, MCP reports should be treated as structured alerts, not as the only source of truth.