# agent-work-layer-mcp [Health: Active]

**Category:** 💻 Developer Tools  
**Repository:** https://github.com/probita-ai/agent-work-layer  
**GitHub Stars:** 1  
**npm Downloads (last month):** 2117  
**Views:** 0  
**Installs:** 0  
**Upvotes:** 0  
**Directory Page:** https://allmcps.com/mcp/agent-work-layer-mcp

## Description
MCP server for Agent Work Layer: hand Work Orders between agent sessions and get checked Work Reports back.

## Tools
Capabilities this server exposes over MCP:

- **create_work_order** — Issue a Work Order to a worker agent. Every criterion must be provable with evidence. Set parent_id to split your own order into a sub-order; it may only narrow budget, tools and deadline. Set continues to reissue a finished order (approved, declined, cancelled or expired) to a new worker, usually with its handoff; cancel a failed or blocked order first.
- **list_work_orders** — List work orders. Workers: filter by to=<yourself> and state=offered to find new jobs.
- **get_work_order** — Full order, current state, latest report, check findings and event log. The order's worker also gets its Delegation Pass, if the desk issues them.
- **accept_work_order** — Worker accepts an offered order.
- **decline_work_order** — Worker declines an offered order.
- **start_work_order** — Worker starts an accepted order.
- **submit_work_report** — Worker reports on an order. done needs evidence for every criterion; blocked needs questions; failed needs error. A rejected report returns the failed checks so you can fix it and resubmit.
- **report_progress** — Worker posts a progress note on a working order, optionally with percent done. Changes no state; managers following the order with wait_for_update see it.
- **answer_question** — Manager or escalation contact answers a blocked worker; the order returns to working.
- **review_work_report** — Manager approves a submitted report, or sends it back for rework with a reason. Approving lets the worker's gateway run the report's staged effects (or only those listed in effects); rework drops them.
- **allow_effect_retry** — Manager lets the worker's gateway run approved effects once more that did not happen: ones the worker settled as not_run after an unknown outcome, or ones skipped because an effect they use did not succeed. Each call allows one more try of each.
- **cancel_work_order** — Manager cancels an order that is not finished.
- **get_track_record** — A worker's record on this desk: orders approved (first time or after rework), declined, expired and cancelled, reports by status, and spending against budget.
- **wait_for_update** — Wait until the order changes after since_seq (up to timeout_s seconds). Use it to follow a job live.

## Claude Desktop Quick Installation
Install path detected from listing signals. Uses `npx` (confidence: high):

```json
"mcpServers": {
  "agent-work-layer-mcp": {
    "command": "npx",
    "args": ["-y","agent-work-layer-mcp"]
  }
}
```

## Documentation

## What agent-work-layer-mcp does

agent-work-layer-mcp provides an MCP interface for handing work between agent sessions. A manager creates a Work Order describing the assignment, how completion will be judged, the available budget, the deadline, and the tools the worker may use. The worker accepts the order, performs the task, and submits a Work Report containing the result, evidence for each criterion, actual cost, and tools used.

The server is part of Agent Work Layer, which defines the job and its lifecycle separately from agent identity, inter-agent messaging, and tool access. This makes the work specification portable between managers and workers. It fits workflows where an agent needs to delegate a bounded task and inspect the returned result before approving it.

## How it works

A typical lifecycle starts with a manager issuing an order. The worker then accepts it and reports a result. The manager or desk checks whether the report satisfies every criterion, stays within budget, uses only permitted tools, and finishes before the deadline. The manager can approve the report or request rework.

The lifecycle enforces role and state rules: workers submit reports, while managers approve them. Orders can be arranged hierarchically, with sub-orders narrowing the authority of their parent and drawing their budgets from it. This prevents a tree of delegated work from exceeding the root order's budget.

Failed or cancelled work can include a handoff containing decisions, attempted approaches, and the next step. A later order can continue the earlier one, preserving the job's history while allowing a different worker, budget, or tool set. Progress events and track records support monitoring across a desk's orders.

## Setup and configuration

Run the MCP package with npx:

```bash
npx -y agent-work-layer-mcp
```

The underlying Agent Work Layer packages require Node.js 20.11 or later and use ESM. The repository's runnable two-agent example uses Node.js 22.18 or later. Install the separate `agent-work-layer` package when application code also needs the SDK, validation, or desk implementation:

```bash
npm install agent-work-layer
```

The desk can operate in memory or use a file, SQLite, or custom store when persistence is needed in application code. The MCP package is intended to connect agent sessions, including workflows such as Claude Code.

## Tools and capabilities

- Create and pass Work Orders between manager and worker sessions.
- Accept assignments and submit structured Work Reports.
- Check evidence against every declared criterion.
- Enforce budgets, deadlines, allowed tools, roles, and legal lifecycle transitions.
- Approve reports or send them back for rework.
- Continue unfinished work with structured handoff information.
- Track progress events and aggregate order outcomes.
- Stage selected write operations for review before execution through the Agent Work Layer MCP gateway.

Staged tools let read operations run normally while selected writes are held, counted, and logged. A worker reports the pending effects, and approval can commit them; rework discards them without requiring an undo operation. A manager can also approve only selected effects.

## Limitations and notes

The server describes and governs delegated work; it does not replace the agents' own tools. Tool access remains constrained by the order and, for staged writes, by the MCP gateway handling those effects. A report must include evidence for each criterion, and costs or tool usage outside the order's limits can prevent successful completion. Persistence choices such as file or SQLite storage belong to the desk implementation rather than the in-memory default.

_Full upstream README: https://allmcps.com/mcp/agent-work-layer-mcp/readme_