Human Dispatch Mcp

io.github.zyntarasystems由 GitHub 账号 zyntarasystems 发布v0.2.2更新于 Oct 24, 2026

MCP server that dispatches physical-world tasks to humans through a unified API

发布方自己的服务:TAP

已验证STDIO仅桌面效率与工作流商业与电商

概览

AI 生成的概览

一个 MCP 服务器,让助手通过 webhook 服务商把现实世界和数字任务派发给真人工作者,支持路由、状态跟踪和手动兜底。

可以做什么
派发任务给真人工作者,包含描述、类别、预算、截止时间和所需凭证,并路由到最匹配的服务商或手动兜底。查询任务状态、工作者信息和已提交凭证,按条件筛选列出任务,取消待处理或进行中的任务。注册、列出和移除 webhook 服务商,查看已配置的后端及其能力。
适用场景
当智能体需要只有真人才能完成的工作时使用,例如到某地点拍照、现场核实或小型数字任务,并且你有可接收任务的服务商 webhook 或手动后端。
运行要求
以 npm 包形式在本地通过 stdio 运行,或通过仅绑定回环地址的 HTTP 加 bearer 令牌运行。可选后端需要凭据:Amazon Mechanical Turk 需要 MTURK_ACCESS_KEY_ID 和 MTURK_SECRET_ACCESS_KEY,RentAHuman.ai 需要 RENTAHUMAN_API_KEY,手动通知需要 MANUAL_WEBHOOK_URL。出站 webhook 地址必须是公网 HTTPS 地址。
安装前请注意
派发任务会向真人工作者承诺真实预算,且 MTurk 默认处于沙箱模式,除非将 MTURK_SANDBOX 设为 false。任务和服务商仅保存在内存中,重启即全部丢失。它会把任务详情(包括地点和预算)发送给第三方 webhook 服务商和后端服务。服务商 webhook 密钥需提供给服务器,且至少 32 个字符。

安装

在 SourceWeft 中

  1. 打开 控制台中的 Human Dispatch Mcp,将其添加到工作区。
  2. 为需要使用其工具的对话启用该服务。

Desktop only,通过 STDIO。 STDIO 服务会启动本地进程,因此需要 SourceWeft 桌面宿主。

其他 MCP 客户端

参照 仓库 中的启动说明。

README

human-dispatch-mcp

🌐 humandispatch.ai — Homepage & provider docs

A universal dispatch layer for AI-agent-to-human task routing — Any business (law firms, VA services, freelancers, agencies) can plug in via webhooks and start receiving AI-dispatched tasks in minutes.

Routes tasks to registered webhook providers with smart matching, fallback chains, and proof-of-completion tracking. Any service provider registers a webhook, and the router matches tasks to providers based on capabilities, region, and budget.

Quick Start

bash
# Clone and installgit clone https://github.com/zyntarasystems/human-dispatch-mcp.gitcd human-dispatch-mcpnpm install
# Configure (optional — works out of the box with manual fallback)cp .env.example .env
# Build and runnpm run buildnode dist/index.js

Testing with MCP Inspector

The easiest way to verify the server is working:

bash
npx @modelcontextprotocol/inspector node dist/index.js

Open http://localhost:5173, enter the proxy session token shown in your terminal, and click Connect.

Test sequence:

  1. List backends — call human_list_backends to see webhook_provider and manual

  2. Register a provider — call human_register_provider:

json
{  "name": "Test Provider",  "webhook_url": "https://webhook.site/your-uuid",  "webhook_secret": "a-secret-that-is-at-least-32-chars-long!",  "categories": ["digital_micro"],  "task_types": ["digital"],  "regions": ["*"],  "min_budget_usd": 0,  "max_budget_usd": 500,  "max_concurrent_tasks": 10}
  1. Dispatch a task — call human_dispatch_task with Raw JSON input mode:
json
{  "description": "Test task — verify the MCP server is routing correctly",  "category": "digital_micro",  "task_type": "digital",  "budget": { "max_usd": 5, "currency": "USD" },  "deadline": {    "complete_by": "2026-04-10T18:00:00Z",    "urgency": "low"  },  "proof_required": ["text_report"],  "quality_sla": "low",  "callback_url": null}

The task should route to your registered provider. If no providers match, it falls through to the manual backend.

MCP Client Configuration

Claude Desktop / Cursor / Any MCP Client

json
{  "mcpServers": {    "human-dispatch": {      "command": "npx",      "args": ["human-dispatch-mcp"]    }  }}

HTTP Transport

Note: HTTP transport binds to 127.0.0.1 only. For remote access, place a TLS-terminating reverse proxy (e.g. nginx, Caddy) in front of the server. Never expose the port directly.

Required: HTTP transport refuses to start without MCP_AUTH_TOKEN set. All POST /mcp requests must include Authorization: Bearer <MCP_AUTH_TOKEN>. The /callbacks/task/:taskId endpoint uses HMAC-signature auth instead — providers do not see the bearer token.

json
{  "mcpServers": {    "human-dispatch": {      "command": "npx",      "args": ["human-dispatch-mcp"],      "env": {        "TRANSPORT": "http",        "PORT": "3000",        "MCP_AUTH_TOKEN": "a-long-random-string-32-chars-or-more"      }    }  }}

Tools Reference

ToolDescription
human_dispatch_taskSubmit a task to be completed by a human worker via the best matching provider
human_get_task_statusPoll the current status, worker info, and proof submissions for a task
human_cancel_taskCancel a pending or in-progress task
human_list_tasksList tasks with filters (status, backend, category) and pagination
human_list_backendsShow available backends, their configuration status, and capabilities
human_register_providerRegister a webhook provider to receive dispatched tasks
human_list_providersList registered providers with stats and filters
human_remove_providerDeregister a webhook provider

Architecture

┌─────────────┐│   AI Agent   ││ (Claude, etc)│└──────┬───────┘       │ MCP Protocol (stdio or HTTP)       ▼┌──────────────────────────────────────┐│     human-dispatch-mcp Server        ││                                      ││  ┌────────────┐  ┌────────────────┐  ││  │ Task Store │  │ Provider       │  ││  │ (in-memory)│  │ Registry       │  ││  └────────────┘  └───────┬────────┘  ││                          │           ││  ┌────────────┐  ┌───────▼────────┐  ││  │   Router   │──│  Webhook       │  ││  │  (scoring) │  │  Provider      │  ││  └──────┬─────┘  │  Adapter       │  ││         │        └───────┬────────┘  ││         │                │           ││         │    ┌───────────▼─────────┐ ││         │    │ Provider A (law)    │ ││         │    │ Provider B (VA)     │ ││         │    │ Provider C (photos) │ ││         │    └─────────────────────┘ ││         ▼                            ││  ┌────────────┐                      ││  │   Manual   │ (always-on fallback) ││  │  Adapter   │                      ││  └────────────┘                      │└──────────────────────────────────────┘

For Service Providers

Any business can register as a provider to receive AI-dispatched tasks. Here's how:

1. Set up a webhook endpoint

Your endpoint receives POST requests with these headers:

HeaderDescription
x-dispatch-signaturesha256=<hmac_hex> — HMAC-SHA256 of the request body using your shared secret
X-Dispatch-EventEvent type: task.new, task.cancel, or provider.verify
X-Dispatch-TaskIdUUID of the task

2. Handle task.new events

Request body:

json
{  "payload_version": 1,  "event": "task.new",  "task_id": "uuid",  "description": "What needs to be done",  "category": "photo_video",  "task_type": "physical",  "location": { "address": "123 Main St", "region": "US" },  "budget": { "max_usd": 25, "currency": "USD" },  "deadline": { "complete_by": "2026-04-10T18:00:00Z", "urgency": "medium" },  "proof_required": ["photo", "gps_checkin"],  "quality_sla": "medium"}

payload_version is the request-shape version; pin your parser to a known version and reject unknown ones. Today only 1 is sent.

Respond with:

json
{ "accepted": true, "external_id": "your-internal-id" }

Or reject:

json
{ "accepted": false, "reason": "Outside service area" }

Handle provider.verify events

When a provider is registered, the server immediately POSTs a provider.verify event to confirm the endpoint is reachable and willing. A 200 alone is not enough — your endpoint must return { "verified": true } in the JSON body. Anything else (missing field, false, non-JSON) marks verification as unreachable. This makes registration require explicit consent from your endpoint, not just URL reachability.

3. Report completion (HTTP transport only)

POST to http://<server>/callbacks/task/<task_id> with headers:

  • x-provider-id: Your provider UUID
  • x-dispatch-signature: sha256=<hmac_hex> of the body
json
{  "status": "completed",  "proof": [    { "type": "photo", "url": "https://...", "submitted_at": "2026-04-10T12:00:00Z" }  ],  "actual_cost_usd": 20,  "notes": "Task completed successfully"}

4. Verify HMAC signatures

Always verify incoming webhooks using your shared secret:

javascript
const crypto = require('crypto');const expected = 'sha256=' + crypto.createHmac('sha256', secret).update(rawBody).digest('hex');const valid = crypto.timingSafeEqual(Buffer.from(expected), Buffer.from(signatureHeader));

HMAC canonicalization contract (load-bearing): the signature is computed over the exact bytes the request was POSTed with, not over a re-serialized JSON object. When you send a callback, sign the byte string you put on the wire — do not parse the body, re-stringify it, and sign that, because key ordering or whitespace may differ. Use JSON.stringify(payload) once, capture the resulting string, sign that string, send that string. The server applies the same rule on the receiving side: it captures the raw request body buffer before any JSON parser touches it.

Smart Routing

The router automatically picks the best backend based on:

  1. Agent preferences — preferred_backends and fallback_chain are honored first
  2. Provider matching — category, task type, region, and budget compatibility
  3. Reliability — providers with higher completion rates are tried first
  4. Speed — faster providers score higher
  5. Fallback — the manual backend is always available as the ultimate fallback

Example Agent Usage

Python with LangGraph

python
import asynciofrom langchain_mcp_adapters.client import MultiServerMCPClient
async def dispatch_photo_task():    async with MultiServerMCPClient({        "human": {            "command": "node",            "args": ["path/to/human-dispatch-mcp/dist/index.js"],            "transport": "stdio",        }    }) as client:        tools = client.get_tools()
        # Register a provider first        await client.call_tool("human_register_provider", {            "name": "Photo Service Co",            "webhook_url": "https://photos.example.com/webhook",            "webhook_secret": "your-secret-that-is-at-least-32-characters",            "categories": ["photo_video"],            "task_types": ["physical"],            "regions": ["US"],            "min_budget_usd": 5,            "max_budget_usd": 100,            "max_concurrent_tasks": 20        })
        # Dispatch a task        result = await client.call_tool("human_dispatch_task", {            "description": "Take a photo of the menu board at Starbucks on 5th Ave, NYC",            "category": "photo_video",            "task_type": "physical",            "location": {                "address": "5th Ave & 42nd St, New York, NY",                "region": "US"            },            "budget": {"max_usd": 15, "currency": "USD"},            "deadline": {                "complete_by": "2026-01-15T18:00:00Z",                "urgency": "medium"            },            "proof_required": ["photo", "gps_checkin"],            "quality_sla": "medium"        })        print(result)
asyncio.run(dispatch_photo_task())

Environment Variables

VariableDefaultDescription
TRANSPORTstdioTransport mode: stdio or http
PORT3000HTTP port (when TRANSPORT=http)
MCP_AUTH_TOKEN—Bearer token required on every POST /mcp request when TRANSPORT=http. The HTTP transport refuses to start if unset.
MANUAL_WEBHOOK_URL—Webhook URL for manual task notifications
PROVIDERS_CONFIG—JSON array of provider objects to pre-seed on startup

Security

This server processes outbound HTTP requests on behalf of its callers and is intended to run inside trusted infrastructure. The relevant guarantees:

  • HTTP transport requires authentication. MCP_AUTH_TOKEN is mandatory; the server refuses to start without it. Bearer comparison is constant-time (timingSafeEqual).
  • DNS-rebinding protection is enabled on POST /mcp. The transport rejects requests whose Host header points at anything other than the configured loopback.
  • Outbound URL guard. Every webhook URL the server fetches (provider registration, MANUAL_WEBHOOK_URL, callback_url, proof URLs) goes through a structured validator: HTTPS only, no loopback, no RFC1918 / link-local / unique-local hosts, with a DNS resolution check at fetch time to defeat last-second rebinds. There is no opt-out — use a public tunnel (ngrok, cloudflared) for local testing.
  • Inbound callbacks are authenticated by HMAC, not by IP. Each provider registers its own webhook secret. The server verifies x-dispatch-signature over the raw request bytes before parsing JSON. A per-provider token bucket limits callback flood (30 burst, 5/sec sustained).
  • Terminal-state guard. Once a task reaches completed, failed, or cancelled, callbacks for that task are rejected with 409. This blocks replays, late provider retries, and provider-driven status flips.
  • Webhook payload versioning. All outbound bodies carry payload_version and event discriminators. Pin your parser; reject unknown versions.
  • Webhook secrets never leave the server. Provider data returned by MCP tools is sanitized to drop webhook_secret. The same field never appears in logs.
  • No persistence. Tasks, providers, and per-task state live in memory. Restarting the server discards all state. If you operate this in production, terminate it cleanly so in-flight tasks fail fast rather than hang in providers.

If you discover a security issue, please open a private security advisory on GitHub rather than a public issue.

Roadmap

  • Persistent provider registry (SQLite / PostgreSQL)
  • Task expiration and automatic retry
  • Provider quality scoring and feedback loops
  • Cost estimation before dispatch
  • Batch task submission
  • Provider dashboard / admin UI
  • OAuth-based provider authentication

Contributing

Adding a New Backend Adapter

  1. Create a new file in src/services/backends/
  2. Extend BaseBackendAdapter
  3. Implement all methods from BackendAdapter interface
  4. Add the backend ID to the BackendId enum in src/types.ts
  5. Register the adapter in src/index.ts

License

MIT

来源:README.md,提交 d8d9f83

工具

0
SourceWeft 尚未在沙箱中启动过该软件包,因此其工具未知。

版本历史

1
  1. v0.2.2最新Sep 16, 2026

评分

已满足适用检查项的 40%

该评分衡量此收录条目的完整程度,依据注册中心条目、端点与公开来源计算得出。它不是对服务器本身的评价,也不表示服务器安全或当前可用:可连通性是带日期的检查结果,评分也不包含安装量或用户评价。

  • 近 30 天内可连通25 分

    请保持端点能够响应 MCP 握手;SourceWeft 每 30 天探测一次。

  • 已声明认证方式10 分

    请在注册中心条目中声明凭据请求头,或保持端点能够响应探测,以便判定其认证方式。

  • 已列出工具15 分

    请让服务器在无凭据时响应 tools/list,或发布可在沙箱中无凭据启动的软件包。

  • 描述必需15 分
  • 图标10 分
  • 文档15 分
  • 许可证10 分

    请在仓库或注册中心条目中声明许可证。

其他 Human 集成