
Agent Handoff MCP
io.github.SarutobiSasuke8由 GitHub 帳號 SarutobiSasuke8 發布v0.1.0更新於 Oct 25, 2026
Bounded, auditable handoffs between AI agents through a local MCP server.
概覽
本機 MCP 伺服器,為多個 AI 代理提供共享且可稽核的交接收件匣,讓它們依生命週期狀態傳遞結構化工作。
- 可以做什麼
- 查詢目前代理身分、權限邊界與策略版本
- 向已授權的接收方送出結構化交接,並列出寄給目前身分的收件匣
- 讀取單一交接及其僅可追加的事件歷程
- 確認接收排隊或受阻的工作、標記受阻或完成,或在仍排隊時取消
- 透過命令列管理登錄檔與儲存:初始化、驗證、簽發、輪替、停用、啟用、撤銷、備份與還原
- 適用情境
- 適用於同一台機器上多個代理或 MCP 用戶端需要互相交接工作、又不希望一個模型控制另一個模型的情況;也適合需要明確歸屬、授權邊界與持久稽核紀錄,而不想靠聊天紀錄或臨時檔案傳遞工作的情境。
- 執行需求
- 需要 Node.js 22.13 或更新版本,並以本機程序方式安裝;此套件尚未發佈至 npm,需使用原始碼檢出。需要環境變數 HANDOFF_AGENT_ID(登錄檔中已啟用的身分)、HANDOFF_MCP_DB(SQLite 資料庫絕對路徑)與 HANDOFF_MCP_REGISTRY(登錄檔 YAML 絕對路徑)。HTTP 模式使用命令列簽發的 bearer 權杖,伺服器預設只綁定本機。
安裝
在 SourceWeft 中
- 開啟 儀表板中的 Agent Handoff MCP,將其新增到工作區。
- 為需要使用其工具的對話啟用該服務。
Desktop only,透過 STDIO。 STDIO 服務會啟動本機處理程序,因此需要 SourceWeft 桌面主機。
其他 MCP 客戶端
參照 儲存庫 中的啟動說明。
README
Agent Handoff MCP
A local-first Model Context Protocol server for bounded, auditable handoffs between AI agents.
Agent Handoff MCP gives Claude, Codex, local agents, and other MCP clients a shared inbox without giving one model control over another. Agents can send structured work, acknowledge it, report a blocker, complete it, or cancel work they originally queued. Every transition is attributable and retained in SQLite.
Why this exists
Multi-agent systems often pass work through chat transcripts, ad hoc files, or vendor-specific orchestration. That loses ownership, lifecycle state, authorization boundaries, and a durable audit trail. This server turns a handoff into a small protocol object:
The server coordinates work; it does not execute agents, fetch references, read arbitrary files, or create autonomous agent loops.
MCP tools
Design properties
- SQLite shared state with WAL mode and parameterized queries
- Streamable HTTP and stdio transports
- Opaque UUID handoff, event, and thread identifiers
- Explicit
send_toandreceive_fromauthorization with no permissive defaults - Per-agent disclosure ceilings:
public-safe,internal, orrestricted - Strict registry validation: unknown keys, duplicates, and unsupported versions are rejected
- Immutable policy snapshots: every operation is checked against the current registry, so disabling an identity, rotating a token, or narrowing a relationship takes effect on live sessions without a restart
- Hashed, expiring bearer-token bindings for HTTP
- Idempotency keys for safe retries
- Maximum reply-chain depth to limit automated ping-pong
- Strict message, array, reference, and request-size limits
- Sender/recipient-only reads, re-authorized against current policy
- Append-only lifecycle events; no MCP delete tool
- References are stored as inert strings and never dereferenced
Command line
The package installs one dispatcher binary, agent-handoff-mcp, whose name matches the package so npx @sarutobi-sasuke/agent-handoff-mcp <command> resolves directly once the package is published to npm. (It is not published yet; use a source checkout until then.)
agent-handoff-http, agent-handoff-stdio, agent-handoff-token, and agent-handoff-validate are also installed as direct aliases.
Quick start
Requirements: Node.js 22.13 or newer.
For a source checkout:
Each issue command prints that identity's raw token exactly once; hand it to that client over a secure channel. Only SHA-256 digests are stored. See docs/QUICKSTART.md for complete PowerShell and POSIX clean-room flows.
The default endpoints are:
The server binds to localhost by default. Put an authenticated private-network or TLS boundary in front of it before any remote deployment.
Stdio mode
Each stdio client supplies its identity through its own process environment while sharing the same SQLite database and registry:
Use HTTP when multiple clients should connect to one long-running service. Use stdio for local clients that can safely receive a fixed identity through their own configuration. Both transports re-check the registry on every operation, so revocation applies to running stdio sessions too.
Local HTTP conformance check
Run npm run conformance from a source checkout after npm ci. It validates
server.json against the existing pinned Registry schema, starts an isolated
loopback server and disposable SQLite registry fixture, checks missing and
invalid bearer requests with curl, and runs the official framework plus an
Inspector tools/list and read-only handoff_whoami call. It requires curl and
network access for the exactly pinned npx tools. No operator registry, existing
database, stored login or live service is used.
The asserted spec revision is 2026-07-28, using
@modelcontextprotocol/[email protected] --requirements 2026-07-28.
The current HTTP transport targets 2025-11-25; stateless request handling
alone does not establish support for the newer lifecycle. Inspector
@modelcontextprotocol/[email protected] explicitly uses its legacy protocol
era for the application smoke. The upstream framework has no bearer-header
flag, so a test-only fetch adapter adds the ephemeral fixture header solely
to that loopback endpoint. Production authentication is exercised unchanged.
The check currently exits 1 on the revision gap. Findings and redacted
logs go to ignored release-evidence/conformance/ (override with
HANDOFF_CONFORMANCE_OUTPUT). Every check runs even when another fails.
Failures are never silently baselined or repaired in the runner. See
the first-run findings before proposing
this as a release gate. This command does not publish or modify CI.
Bearer request negative tests
Run npm run test:auth-negative after npm ci in a source checkout. This
dependency-free runner uses the existing disposable registry/SQLite harness
on 127.0.0.1, with a random port and freshly generated fixture credentials.
It accepts no remote endpoint or stored-token override. It runs every probe,
prints only names and status codes, writes sanitised results under ignored
release-evidence/auth-negative/results.json, and exits 1 if any expected
response is missing. It does not change CI. A successful
header-authenticated tools/list control guards against a broken fixture.
The numbered cases use RFC 6750 sections 2 and 3.1 for bearer error responses; they are a focused request-shape check, not a claim of full MCP/OAuth conformance.
Case 6 was a finding on the first run. Since 25 October /mcp rejects any
JSON or form body that carries access_token, with or without a header, with
HTTP 400 and a Bearer error="invalid_request" challenge, before the token is
checked. Form bodies are parsed (16 KB cap) only to find that field; MCP
requests must still be JSON. The form probe uses RFC 6750's form-encoded
access_token; the JSON probe separately checks the same field on an
otherwise valid MCP request.
Cases 4, 8-12 are N/A to this static-token profile today: no JWT audience,
issuer, per-token OAuth scope hierarchy or Protected Resource Metadata is
implemented. Revisit them with an OAuth resource-server migration; N/A is
not evidence of compliance. Unknown tokens still fail even though an issuer
claim is not evaluated. Case 3 is not N/A: static registry credentials
already have expires_at, and this runner and existing e2e tests exercise
expiry. Existing rotation, disabled-token and handoff authorisation tests
also remain in place.
For external conformance tooling, the package names are mcp-spec-check and
@modelcontextprotocol/conformance; the existing pinned official framework
command above is unchanged. This runner installs neither package and adds
no dependency. Proposed CI wiring belongs in the PR description until the
response findings are resolved.
Operational metrics
Set HANDOFF_MCP_METRICS=1 to record in-process counters for handoffs
created, accepted (claimed), expired and store errors, plus per-tool call
duration histograms. Only the initial queued-to-accepted move counts as a claim.
The default is off. When enabled, both HTTP and stdio servers write one JSON
snapshot to local stderr at startup, every 60 seconds and on graceful shutdown.
For example, HANDOFF_MCP_METRICS=1 agent-handoff-mcp stdio 2>metrics.jsonl
captures the running process's snapshots without mixing them with MCP stdout.
The snapshot from src/metrics.ts uses an OpenTelemetry OTLP JSON-shaped
resourceMetrics/scopeMetrics structure. It has only fixed metric names,
counts, timings and a bounded tool-name label; no handoff content, titles,
agent text or tokens enter the recorder. No network exporter or public
metrics endpoint is installed. The expired counter remains 0 because the
current handoff lifecycle has no expiry transition.
Documentation
The draft MCP Registry manifest launches the npm binary with the stdio
argument and requires HANDOFF_AGENT_ID, HANDOFF_MCP_REGISTRY and
HANDOFF_MCP_DB from the operator. It creates no identities or credentials.
The namespace uses the exact GitHub owner spelling, io.github.SarutobiSasuke8.
prepublishOnly includes check:registry; publishing and registry login remain
separate operator actions. Builds omit source maps and their JavaScript links.
- Clean-room quickstart
- Protocol and lifecycle
- Architecture
- Security model
- Registry JSON Schema
- Roadmap
- Release validation, 2026-10-01
- Changelog
Scope boundary
This project is a coordination primitive, not a general task platform. Shared task boards, decisions, broadcasts, presence, leases, context promotion, and remote dispatch belong behind future optional modules. The six-tool handoff surface remains the stable core.
Optional inbox notifications
Set HANDOFF_MCP_NOTIFICATION_FILE to an absolute path to append a local JSONL notice when a new handoff lands. Notifications are off by default. Each line contains only handoffId, senderId, recipientId, status and timestamp. It contains no title, body, attachments or other handoff content. An idempotent retry does not emit a second notice. Protect the file as operational metadata; it reveals agent identities and handoff timing. A notification write failure is logged without handoff content and does not undo the committed handoff.
License
Apache-2.0. See LICENSE.
Recovery and local release evidence
Use agent-handoff-mcp backup <out-file> for a live WAL snapshot with the validated registry, and restore <file> into fresh files after stopping servers. Existing destinations require --force; live servers, corrupt backups and incomplete restores remain blocked. See Recovery for commands, policy reconciliation and the limits of local process guards.
The local SQLite store applies ordered, recorded migrations at startup in a
schema_migrations table. It recognises existing unversioned stores and
records their observed schema before applying pending changes. A store with a
newer schema version refuses to open with a clear error; use a compatible
binary rather than downgrading the database.
npm run release:dry-run produces local checks, e2e recovery proof, allowlist verification, SPDX SBOM, tarball and SHA-256 evidence under gitignored release-evidence/. Package publication remains an owner action.
來源:README.md,提交 edf1489
工具
0版本歷史
1- v0.1.0最新Oct 25, 2026
評分
已滿足適用檢查項的 50%
該評分衡量此收錄條目的完整程度,依據註冊中心條目、端點與公開來源計算得出。它不是對伺服器本身的評價,也不表示伺服器安全或目前可用:可連通性是帶日期的檢查結果,評分也不包含安裝量或使用者評價。
- 近 30 天內可連通25 分
請保持端點能夠回應 MCP 握手;SourceWeft 每 30 天探測一次。
- 已宣告認證方式10 分
請在註冊中心條目中宣告憑證請求標頭,或保持端點能夠回應探測,以便判定其認證方式。
- 已列出工具15 分
請讓伺服器在無憑證時回應 tools/list,或發布可在沙箱中無憑證啟動的軟體包。
- 描述必需15 分
- 圖示10 分
- 文件15 分
- 授權條款10 分