# io.github.zyntarasystems/human-dispatch-mcp (npm · human-dispatch-mcp)

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

- Trust score: 65/100 (medium)
- Change this week: +40
- Registry status: active
- Liveness: live
- Owner verified: no
- Last scored: 2026-08-03

## Components

- npm · `human-dispatch-mcp`: 65/100 (this document), [markdown](https://verifymcp.io/servers/zyntarasystems-human-dispatch-mcp/human-dispatch-mcp.md), [page](https://verifymcp.io/servers/zyntarasystems-human-dispatch-mcp/human-dispatch-mcp)

## Channel facts

- Registry: `npm`
- Package: `human-dispatch-mcp`
- Version: `0.2.2`
- Transport: `stdio`

## Trust breakdown

How this component scores in each security and reliability category. Every signal is checked automatically from public evidence about the published package, including repeated runs of it in an isolated sandbox, and we only credit what we can confirm. Scores are 0–100 per category. Scoring method: https://verifymcp.io/docs/scoring (what has changed: https://verifymcp.io/docs/scoring/changelog)

Scored 2026-08-03.

- **Supply Chain Security**: 87/100
  - No malware found by supply-chain analysis.
  - Only part of the dependency tree could be resolved (122 of 124), so this covers what we could see, not the whole tree.
  - No install/post-install scripts declared.
  - Only part of the dependency tree could be resolved (122 of 124), so this covers what we could see, not the whole tree.
- **Provenance & Transparency**: 45/100
  - Source repository is publicly reachable at the declared URL.
  - Provenance check failed: no build-provenance attestation is published.
  - Clear OSI-approved license (MIT).
  - Actively maintained (last published 67 days ago).
  - Disclosure check failed: no security disclosure policy was found in the source repository.
- **Schema Quality & AI Usability**: 57/100
  - AI-judged instruction clarity (excellent).
  - Context-footprint check failed: tool/resource definitions use about 1990 tokens (~398/item across 5 items; 5 tools + 0 resources), over budget; trim descriptions and params.
  - Usage-examples check failed: none of the tools include examples.
- **Stability & Change Management**: 23/100
  - Stability observed for 7 of 30 days with no destabilising changes; credit accrues until the full window elapses.
- **Tool Coverage**: 100/100
  - 100% of tools have a non-trivial description (not blank, and not just the tool's name).
  - 100% of tool parameters carry a description.
- **Capabilities**: 100/100
  - Implements a supported MCP spec version (2025-11-25); the latest is 2026-07-28.

## Install

### Claude

```bash
claude mcp add zyntarasystems-human-dispatch-mcp -- npx -y human-dispatch-mcp
```

### Codex

```bash
codex mcp add zyntarasystems-human-dispatch-mcp -- npx -y human-dispatch-mcp
```

### opencode

```json
{
  "$schema": "https://opencode.ai/config.json",
  "mcp": {
    "zyntarasystems-human-dispatch-mcp": {
      "type": "local",
      "command": [
        "npx",
        "-y",
        "human-dispatch-mcp"
      ],
      "enabled": true
    }
  }
}
```

### OpenClaw

```bash
openclaw mcp add zyntarasystems-human-dispatch-mcp --command npx --arg -y --arg human-dispatch-mcp
```

### Hermes

```yaml
mcp_servers:
  zyntarasystems-human-dispatch-mcp:
    command: "npx"
    args: ["-y", "human-dispatch-mcp"]
```

### Other

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

## Changelog

Every change recorded for this component, newest first. Days that predate change tracking, or that we cannot explain, say so: "we were watching and nothing happened" and "we were not watching" are different claims.

### 2026-08-02 (score 65, +48)

- [security regression] Provenance: unverified → fail
- [security improvement] Known CVEs: unverified → partial
- [security improvement] Install scripts: unverified → pass
- [security improvement] Malware scan: unverified → pass
- [functional regression] Tool coverage: 100 → unverified
- [functional regression] Security disclosure: fail → unverified
- [functional improvement] MCP protocol: unverified → pass
- [functional improvement] Maintenance: unverified → pass
- [functional improvement] Stability: unverified → 0.20
- [functional improvement] Dependency health: unverified → partial
- [functional improvement] License: unverified → pass
- [functional improvement] Schema quality: unverified → excellent
- [functional] Licence: MIT

### 2026-07-31 (score 17, −6)

- [functional] We updated how we score, so this day's move reflects our rubric, not a change to the server

### 2026-07-30 (score 23, −18)

- [security regression] Malware scan: pass → unverified

### 2026-07-28 (score 41, +16)

- [functional regression] Dependency health: partial → unverified
- [functional improvement] Tool coverage: unverified → 100
- [functional] First check of Schema quality: unverified
- [functional] First check of Schema quality: fail
- [functional] First check of Schema quality: fail
- [functional] First check of Tool coverage: 100

### 2026-07-27 (score 25)

First indexed and scored.

## MCP tools (5)

### `human_dispatch_task` (~1018 tokens)

Dispatch a task to a human worker via the best available backend service.

This is the primary tool for sending work to humans. You describe what needs to be done, and the system routes it to the most appropriate backend (Amazon Mechanical Turk for digital microtasks, RentAHuman.ai for physical/local tasks, or a manual fallback).

PARAMETERS:
\- description: What the human should do. Be specific about location, timing, and deliverables.
\- category: Task category (errand, photo_video, data_collection, verification, delivery, digital_micro, in_person, custom)
\- task_type: physical (requires presence), digital (remote), or hybrid (both)
\- location: Where to perform the task (required for physical tasks). Include address or coordinates.
\- budget: Maximum USD to pay. Different backends have different ranges.
\- deadline: When it must be done, with urgency level.
\- proof_required: What evidence the worker must submit (photo, video, gps_checkin, text_report, receipt, signature).
\- quality_sla: low (fast/cheap), medium (default), high (verified workers, multiple proofs).
\- preferred_backends: Optional ordered list of backends to try first.
\- fallback_chain: Optional ordered fallback list if preferred backends fail.
\- callback_url: Optional webhook URL for status notifications.
\- metadata: Optional key-value pairs for your own tracking.

EXAMPLES:
1\. Photo task: { description: "Take a photo of the menu board at the Starbucks on 5th Ave and 42nd St, NYC", category: "photo_video", task_type: "physical", location: { address: "5th Ave & 42nd St, New York, NY" }, budget: { max_usd: 15, currency: "USD" }, deadline: { complete_by: "2025-01-15T18:00:00Z", urgency: "medium" }, proof_required: ["photo", "gps_checkin"], quality_sla: "medium" }

2\. Data collection: { description: "Count the number of electric vehicle charging stations within 1km of Times Square", category: "data_collection", task_type: "physical", location: { address: "Times Square, NYC", radius_km: 1 }, budget: { max_us…

Input parameters:

- `budget` (object, required): Budget constraints for the task
- `callback_url`: Webhook URL to receive status update notifications. Set to null or omit if you will poll for status instead.
- `category` (string, required): Category of the task — determines which backends are best suited
- `deadline` (object, required): When the task needs to be completed
- `description` (string, required): Clear, detailed description of what the human worker should do. Be specific about location, timing, and expected output. Example: 'Take a photo of the menu board at the Starbucks on 5th Ave and 42nd…
- `fallback_chain` (array): Ordered list of fallback backends if the preferred ones fail. The 'manual' backend is always available as a last resort.
- `location`: Where the task should be performed. Required for physical tasks. Set to null or omit for digital tasks.
- `metadata` (object): Arbitrary key-value pairs for your own tracking (e.g. {'order_id': '12345', 'agent_name': 'my-bot'})
- `preferred_backends` (array): Preferred backend services to route this task to, tried in order. If omitted, the router picks the best backend automatically.
- `proof_required` (array, required): Types of proof the worker must submit upon completion. At least one is required. Example: ['photo', 'gps_checkin']
- `quality_sla` (string, required): Quality/speed tradeoff: low=fastest/cheapest, medium=default, high=verified workers with multi-proof
- `task_type` (string, required): Whether the task requires physical presence, is digital-only, or both

### `human_get_task_status` (~225 tokens)

Get the current status of a previously dispatched human task.

Returns the full task state including: current status, which backend is handling it, worker info (if assigned), proof submissions (if any), actual cost, and timing info.

If the task has been routed to a backend, this tool fetches fresh status from that backend and merges any new data (worker assignment, proof uploads, completion).

PARAMETERS:
\- task_id: The UUID returned by human_dispatch_task.

RETURNS: Full task object with status, backend_id, worker_id, proof array, cost, timestamps, and routing attempts.

EXAMPLES:
1\. Check on a task: { task_id: "550e8400-e29b-41d4-a716-446655440000" }

DON'T USE WHEN:
\- You don't have a task_id (use human_list_tasks to find tasks)
\- You want to check all tasks at once (use human_list_tasks instead)

Input parameters:

- `task_id` (string, required): The UUID of the task to look up, as returned by human_dispatch_task

### `human_cancel_task` (~173 tokens)

Cancel a pending or in-progress human task.

Attempts to cancel the task both in the local system and on the backend service. Cancellation may not be possible if the task is already completed.

PARAMETERS:
\- task_id: The UUID of the task to cancel.

RETURNS: { task_id, cancelled: boolean, message: string }

EXAMPLES:
1\. Cancel a task: { task_id: "550e8400-e29b-41d4-a716-446655440000" }

DON'T USE WHEN:
\- The task is already completed (check status first with human_get_task_status)
\- You want to modify a task (cancellation is permanent — dispatch a new task instead)

Input parameters:

- `task_id` (string, required): The UUID of the task to look up, as returned by human_dispatch_task

### `human_list_tasks` (~352 tokens)

List all dispatched human tasks with optional filters and pagination.

Returns tasks sorted by creation time (newest first). Use filters to narrow results by status, backend, or category.

PARAMETERS:
\- status: (optional) Filter by task status: pending, routed, assigned, in_progress, awaiting_review, completed, failed, cancelled
\- backend_id: (optional) Filter by backend: mturk, rentahuman, manual
\- category: (optional) Filter by category: errand, photo_video, data_collection, verification, delivery, digital_micro, in_person, custom
\- limit: (optional) Max results to return, 1-100, default 20
\- offset: (optional) Skip N results for pagination, default 0

RETURNS: { total, count, tasks[], has_more, next_offset }

EXAMPLES:
1\. List all tasks: {}
2\. List completed tasks: { status: "completed" }
3\. List physical tasks on RentAHuman: { backend_id: "rentahuman", limit: 10 }
4\. Paginate: { limit: 5, offset: 5 }

DON'T USE WHEN:
\- You know the exact task_id (use human_get_task_status for a single task)

Input parameters:

- `backend_id` (string): Filter tasks by which backend is handling them
- `category` (string): Filter tasks by their category
- `limit` (integer): Maximum number of tasks to return (1-100, default 20)
- `offset` (integer): Number of tasks to skip for pagination (default 0)
- `status` (string): Filter tasks by status (e.g. 'pending', 'completed')

### `human_list_backends` (~222 tokens)

List all available backend services and their capabilities.

Shows which backends are configured (have API keys), what types of tasks they support, their regional availability, budget ranges, and average completion times.

Use this to understand what backends are available before dispatching a task, or to debug why a task was routed to a particular backend.

NO PARAMETERS REQUIRED.

RETURNS: Array of backend capabilities including:
\- id: Backend identifier
\- name: Human-readable name
\- supports_physical/digital: What task types it handles
\- supports_location: Whether it can handle location-specific tasks
\- available_regions: Where it operates
\- min/max_budget_usd: Budget range
\- avg_completion_minutes: Typical turnaround time
\- requires_api_key: Whether an API key is needed
\- configured: Whether the API key is present and the backend is ready

EXAMPLES:
1\. List all backends: {} (no parameters needed)

DON'T USE WHEN:
\- You already know which backend to use (just set preferred_backends in human_dispatch_task)

## Diagnostics

Captured diagnostic sections: Provenance, Dependencies. The full working is on the page: https://verifymcp.io/servers/zyntarasystems-human-dispatch-mcp/human-dispatch-mcp#diagnostics

## Score history

- 2026-08-03: 65
- 2026-08-02: 65
- 2026-08-01: 17
- 2026-07-31: 17
- 2026-07-30: 23
- 2026-07-28: 41
- 2026-07-27: 25

## Links

- npm package: https://www.npmjs.com/package/human-dispatch-mcp
- Socket report: https://socket.dev/npm/package/human-dispatch-mcp
- Repository: https://github.com/zyntarasystems/human-dispatch-mcp
- Changelog RSS feed: https://verifymcp.io/servers/zyntarasystems-human-dispatch-mcp/human-dispatch-mcp/changelog.xml
- Changelog JSON feed: https://verifymcp.io/servers/zyntarasystems-human-dispatch-mcp/human-dispatch-mcp/changelog.json
- HTML version of this page: https://verifymcp.io/servers/zyntarasystems-human-dispatch-mcp/human-dispatch-mcp