How do I use human-dispatch-mcp?

1. Click on "Install Server". 2. Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state. 3. In the chat, type @ followed by the MCP server name and your instructions, e.g., "@human-dispatch-mcp Dispatch a task to summarize the quarterly report" That's it! The server will respond to your query, and you can continue using it as needed. Here is a step-by-step guide with screenshots.

human-dispatch-mcp

by zyntarasystems

Overview Schema Related Servers Score Discussions

TypeScript

Hybrid

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

# Clone and install
git clone https://github.com/zyntarasystems/human-dispatch-mcp.git
cd human-dispatch-mcp
npm install

# Configure (optional — works out of the box with manual fallback)
cp .env.example .env

# Build and run
npm run build
node dist/index.js

Related MCP server: Offload MCP

Testing with MCP Inspector

The easiest way to verify the server is working:

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:

List backends — call human_list_backends to see webhook_provider and manual
Register a provider — call human_register_provider:

{
  "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
}

Dispatch a task — call human_dispatch_task with Raw JSON input mode:

{
  "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

{
  "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.

{
  "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

Tool	Description
`human_dispatch_task`	Submit a task to be completed by a human worker via the best matching provider
`human_get_task_status`	Poll the current status, worker info, and proof submissions for a task
`human_cancel_task`	Cancel a pending or in-progress task
`human_list_tasks`	List tasks with filters (status, backend, category) and pagination
`human_list_backends`	Show available backends, their configuration status, and capabilities
`human_register_provider`	Register a webhook provider to receive dispatched tasks
`human_list_providers`	List registered providers with stats and filters
`human_remove_provider`	Deregister 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:

Header	Description
`x-dispatch-signature`	`sha256=<hmac_hex>` — HMAC-SHA256 of the request body using your shared secret
`X-Dispatch-Event`	Event type: `task.new`, `task.cancel`, or `provider.verify`
`X-Dispatch-TaskId`	UUID of the task

2. Handle `task.new` events

Request body:

{
  "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:

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

Or reject:

{ "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

{
  "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:

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:

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

Example Agent Usage

Python with LangGraph

import asyncio
from 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

Variable	Default	Description
`TRANSPORT`	`stdio`	Transport mode: `stdio` or `http`
`PORT`	`3000`	HTTP 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

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

License

MIT

Available Tools

8 tools

human_cancel_taskA

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:

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)

ParametersJSON Schema

Name	Required	Description	Default
`task_id`	Yes	The UUID of the task to look up, as returned by human_dispatch_task

TDQS

A4.5/5.0

Behavior4/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations, the description carries the full burden. It discloses that cancellation attempts both local and backend, may not succeed if completed, and is permanent. Additional details on failure scenarios would raise this to 5.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is well-structured with clear sections (purpose, parameters, returns, examples, don't use). Every sentence is necessary and contributes to understanding.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the single parameter, full schema coverage, and a clear description of return values, the tool's behavior is fully described. No output schema needed as returns are explained in text.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100% and the description restates the parameter's purpose ('The UUID of the task to cancel') without adding significant new meaning beyond the schema's format constraint.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the action: 'Cancel a pending or in-progress human task.' It distinguishes from siblings by noting that cancellation is permanent and suggesting when to use alternatives like human_get_task_status.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines5/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Includes a 'DON'T USE WHEN' section with explicit conditions (task already completed, modification needed) and directs to alternative tools: human_get_task_status for status check and dispatch new task for modification.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

human_dispatch_taskA

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 registered webhook provider based on category, task type, region, and budget. If no providers match or accept, the task falls through to the 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 providers 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 (webhook_provider, manual).
fallback_chain: Optional ordered fallback list if preferred backends fail.
metadata: Optional key-value pairs for your own tracking.

EXAMPLES:

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: "2027-01-15T18:00:00Z", urgency: "medium" }, proof_required: ["photo", "gps_checkin"], quality_sla: "medium" }
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_usd: 25, currency: "USD" }, deadline: { complete_by: "2027-01-20T00:00:00Z", urgency: "low" }, proof_required: ["text_report", "photo"], quality_sla: "high" }
Digital microtask: { description: "Transcribe the handwritten text in the attached image to typed text", category: "digital_micro", task_type: "digital", budget: { max_usd: 2, currency: "USD" }, deadline: { complete_by: "2027-01-16T00:00:00Z", urgency: "medium" }, proof_required: ["text_report"], quality_sla: "low" }

DON'T USE WHEN:

The task can be done by an AI (use an AI tool instead)
You need instant results (humans take minutes to hours)
No providers are registered (use human_register_provider first, or rely on manual fallback)

ParametersJSON Schema

Name	Required	Description
`budget`	Yes	Budget constraints for the task
`category`	Yes	Category of the task — determines which backends are best suited
`deadline`	Yes	When the task needs to be completed
`location`	No	Where the task should be performed. Required for physical tasks. Set to null or omit for digital tasks.
`metadata`	No	Arbitrary key-value pairs for your own tracking (e.g. {'order_id': '12345', 'agent_name': 'my-bot'})
`task_type`	Yes	Whether the task requires physical presence, is digital-only, or both
`description`	Yes	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 St, NYC'
`quality_sla`	Yes	Quality/speed tradeoff: low=fastest/cheapest, medium=default, high=verified workers with multi-proof
`fallback_chain`	No	Ordered list of fallback backends if the preferred ones fail. The 'manual' backend is always available as a last resort.
`proof_required`	Yes	Types of proof the worker must submit upon completion. At least one is required. Example: ['photo', 'gps_checkin']
`idempotency_key`	No	Optional client-supplied key to dedupe retried submissions. If a task with the same key was created within the last hour, the existing task is returned instead of a duplicate. Example: 'order-12345-attempt-1'
`preferred_backends`	No	Preferred backend services to route this task to, tried in order. If omitted, the router picks the best backend automatically.

TDQS

A4.5/5.0

Behavior4/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations provided, but description explains routing logic, fallback to manual, and provider selection. It does not cover error handling or auth, but the main behavioral traits are disclosed.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Well-structured with clear sections (purpose, parameters, examples, don't use). Every sentence adds value; no redundancy despite length.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

No output schema, and description doesn't explain return values or error handling. However, given the complexity (12 params, nested objects), it covers what the agent needs to know to use the tool correctly.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters5/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100%, but the description adds significant value: explains each parameter with context, provides three complete examples, and clarifies dependencies (e.g., location required for physical).

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states it dispatches tasks to human workers via the best available backend. It distinguishes itself from sibling tools like human_register_provider and human_get_task_status by being the primary dispatch tool.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Provides explicit 'DON'T USE WHEN' conditions (AI-suitable tasks, instant results needed, no registered providers) and advises registering providers first. However, it does not explicitly compare with each sibling.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

human_get_task_statusA

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:

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)

ParametersJSON Schema

Name	Required	Description	Default
`task_id`	Yes	The UUID of the task to look up, as returned by human_dispatch_task

TDQS

A4.7/5.0

Behavior5/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Despite no annotations, the description fully discloses behavior: it fetches fresh status from the backend, merges new data (worker assignment, proof uploads, completion), and returns a full task object with detailed fields. No contradictions or omissions.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is well-structured with clear sections: purpose, return details, parameter explanation, returns, example, and don't-use. Every sentence is informative and concise; no fluff.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the tool's simplicity (one required parameter, no output schema), the description covers all necessary aspects: purpose, parameters, return format, usage guidance, and example. It is fully complete for AI agent invocation.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100% and the description adds minimal extra value beyond the schema's own description (e.g., 'The UUID returned by human_dispatch_task'). The schema already documents the parameter adequately, so baseline of 3 is appropriate.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states 'Get the current status of a previously dispatched human task.' It specifies the verb (get) and resource (status of human task), and distinguishes from siblings like human_list_tasks (which lists all tasks) and human_dispatch_task (which creates tasks).

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines5/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description includes a 'DON'T USE WHEN' section that explicitly states when to use alternatives (human_list_tasks) and provides clear context for when the tool should not be used. This is excellent guidance.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

human_list_backendsA

List all available backend services and their capabilities.

Shows which backends are configured and ready, 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 external credentials are needed
configured: Whether the backend is ready

EXAMPLES:

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)

ParametersJSON Schema

Name	Required	Description	Default
No parameters

TDQS

A4.9/5.0

Behavior5/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Despite no annotations, the description thoroughly explains that the tool is read-only, lists backends, and details the returned capabilities. No destructive behavior is implied, and the agent can infer safe usage.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Well-structured with sections, front-loaded with purpose. However, there is slight redundancy (e.g., the first two sentences both state the tool lists backends). Still concise and efficient overall.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given zero parameters and no output schema, the description is fully complete: it describes what the tool does, when to use it, the return schema in detail, includes examples, and provides exclusions.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters5/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

No parameters are required, and the description compensates by detailing the return structure (id, name, supports_physical/digital, etc.). The schema coverage is 100%, and the description adds significant value beyond the empty schema.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool lists all available backend services and their capabilities. It is distinct from sibling tools like human_dispatch_task and human_list_tasks, which deal with task operations rather than backend discovery.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines5/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Explicitly advises when to use: before dispatching a task or debugging routing. Also provides a 'DON'T USE WHEN' section referencing an alternative (set preferred_backends in human_dispatch_task). This is a model for usage guidance.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

human_list_providersA

List all registered webhook providers with their stats.

Returns provider profiles including categories, regions, budget ranges, and performance stats (reliability score, completed/failed counts). Webhook secrets are never included in the output.

PARAMETERS:

category: Optional — filter by supported task category
region: Optional — filter by supported region
active_only: Only show active providers (default true)

ParametersJSON Schema

Name	Required	Description
`region`	No	Filter providers by supported region
`category`	No	Filter providers by supported category
`active_only`	No	Only show active providers (default true)

TDQS

A4/5.0

Behavior4/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations are provided, so the description carries full burden. It discloses that webhook secrets are never included and details return values (categories, regions, budget ranges, performance stats). However, it omits pagination or rate limit information.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is concise, front-loaded with purpose, and well-structured into a main sentence and a parameter list. No unnecessary information.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the lack of output schema and only three parameters, the description adequately covers the tool's purpose, return values, and filters. Missing details like ordering or pagination are not critical for a list tool, so it is reasonably complete.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100%, so baseline is 3. The description's parameter section adds no new meaning beyond what the schema already provides, as schema descriptions cover the same details.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description explicitly states 'List all registered webhook providers with their stats,' which is a specific verb+resource combination. It clearly distinguishes from siblings like human_list_backends and human_list_tasks.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description implies usage by listing parameters but does not provide explicit guidance on when to use this tool versus alternatives, nor does it state when not to use it.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

human_list_tasksA

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, completed, failed, cancelled
backend_id: (optional) Filter by backend: webhook_provider, 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:

List all tasks: {}
List completed tasks: { status: "completed" }
List webhook provider tasks: { backend_id: "webhook_provider", limit: 10 }
Paginate: { limit: 5, offset: 5 }

DON'T USE WHEN:

You know the exact task_id (use human_get_task_status for a single task)

ParametersJSON Schema

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

TDQS

A4.7/5.0

Behavior5/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations provided, so description fully discloses behavior: tasks sorted by creation time (newest first), pagination details, and return structure. No contradictions.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Well-structured with clear sections (purpose, sorting, parameters, returns, examples, don't use). Front-loaded with essential info, no wasted words.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given no output schema, it describes returns. All 5 parameters fully documented, no annotations needed. Complete for a listing tool.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100%, but description adds defaults, enum values, and use cases through examples, going beyond schema descriptions.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool lists all dispatched human tasks with optional filters and pagination. It distinguishes from sibling tools like human_get_task_status, which is for a single task.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Explicitly says 'DON'T USE WHEN' and directs to human_get_task_status for a single task. Provides examples for various filters and pagination, but could mention when to use other siblings like human_list_backends.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

human_register_providerA

Any service provider (law firm, VA agency, freelancer, etc.) can register their webhook endpoint to start receiving tasks that match their profile. The system will POST task payloads to the webhook URL, signed with HMAC-SHA256 using the shared secret.

PARAMETERS:

name: Human-readable provider name (e.g. "Smith & Associates Law")
webhook_url: HTTPS URL where tasks will be POSTed
webhook_secret: Shared secret for HMAC-SHA256 webhook signatures (min 32 characters)
categories: Task categories this provider handles (errand, photo_video, data_collection, verification, delivery, digital_micro, in_person, custom)
task_types: Task types supported (physical, digital, hybrid)
regions: Regions served (e.g. ["US", "EU", "*"] where * = global)
min_budget_usd: Minimum task budget accepted (USD)
max_budget_usd: Maximum task budget accepted (USD)
max_concurrent_tasks: Max simultaneous tasks (default 10)

WEBHOOK FORMAT: Tasks are POSTed with headers:

x-dispatch-signature: sha256=
X-Dispatch-Event: task.new | task.cancel | provider.verify
X-Dispatch-TaskId:

Expected response: { "accepted": true, "external_id": "your-id" } or { "accepted": false, "reason": "..." }

ParametersJSON Schema

Name	Required	Description
`name`	Yes	Human-readable provider name (e.g. 'Smith & Associates Law')
`regions`	Yes	Regions served (e.g. ['US', 'EU', ''] where = global)
`categories`	Yes	Task categories this provider handles
`task_types`	Yes	Task types this provider supports (physical, digital, hybrid)
`webhook_url`	Yes	HTTPS URL where tasks will be POSTed
`max_budget_usd`	Yes	Maximum task budget this provider accepts (USD)
`min_budget_usd`	Yes	Minimum task budget this provider accepts (USD)
`webhook_secret`	Yes	Shared secret for HMAC-SHA256 webhook signatures (min 32 chars)
`max_concurrent_tasks`	No	Maximum number of tasks this provider can handle concurrently

TDQS

A4.1/5.0

Behavior4/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations, the description carries the full burden. It details the webhook format, HMAC-SHA256 signing, and expected response, but does not clarify behavior on duplicate registrations or error cases.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is well-structured with sections, front-loaded with purpose, and each sentence adds value. It is comprehensive but not overly verbose.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the complexity (9 parameters, 8 required, no output schema), the description covers purpose, webhook interaction, and expected response. It lacks error details but is generally complete.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100%, so baseline is 3. The description largely repeats schema parameter descriptions, though it adds webhook format context that indirectly aids understanding of parameters like webhook_url and webhook_secret.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description states 'Register a new webhook provider to receive dispatched tasks,' which clearly identifies the verb and resource. It distinguishes from sibling tools like human_dispatch_task and human_list_providers.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description explains that providers register to start receiving tasks that match their profile, but does not explicitly mention when not to use the tool or suggest alternatives.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

human_remove_providerA

Remove a registered webhook provider.

Deregisters a provider so it will no longer receive dispatched tasks. Does not affect tasks already dispatched to this provider.

PARAMETERS:

provider_id: The UUID of the provider to remove (as returned by human_register_provider)

ParametersJSON Schema

Name	Required	Description	Default
`provider_id`	Yes	The UUID of the provider to operate on

TDQS

A4.4/5.0

Behavior4/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations, the description discloses key behavior: deregistration and no impact on already dispatched tasks. It is transparent about the effect, though it could mention required permissions or irreversibility.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is concise, with the main purpose front-loaded and a dedicated PARAMETERS section for clarity. No unnecessary words.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the tool's simplicity (one parameter, no output schema), the description is largely complete. It covers the removal effect and the harmless nature on already dispatched tasks, though it could mention that the provider must exist.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The schema already describes provider_id as a UUID. The description adds value by noting 'as returned by human_register_provider,' which provides useful context. Schema coverage is 100%, so baseline is 3; the extra context raises the score.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states 'Remove a registered webhook provider,' using a specific verb and resource. It is distinct from sibling tools like human_register_provider and human_list_providers.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description explains when to use the tool ('deregisters a provider so it will no longer receive dispatched tasks') and clarifies that it does not affect already dispatched tasks. However, it does not explicitly mention when not to use it or alternatives.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Tool Schema Changelog

Recent tool additions, removals, and schema changes observed during successful MCP inspections. Dates show when Glama detected each change.

8 tool updatesv0.4.1Jul 28, 2026
- First observedhuman_cancel_task
- First observedhuman_dispatch_task
- First observedhuman_get_task_status
- First observedhuman_list_backends
- First observedhuman_list_providers
- First observedhuman_list_tasks
- First observedhuman_register_provider
- First observedhuman_remove_provider

Install Server

RayrunBuild, deploy, and operate MCP servers without becoming an infrastructure team.ray.runAd

TDQS

A4.4/5.0

Disambiguation5/5

All 8 tools have clearly distinct purposes: dispatching tasks, checking status, canceling, listing tasks, listing backends, and managing providers. No overlap or ambiguity.

Naming Consistency5/5

All tools use the 'human_' prefix followed by verb_noun (dispatch_task, get_task_status, cancel_task, etc.). Consistent and predictable pattern.

Tool Count5/5

8 tools is well-scoped for a human dispatch system, covering core operations (dispatch, status, cancellation, listing) and provider management without being excessive.

Completeness4/5

The tool surface covers the main lifecycle (dispatch, status, cancel, list) and provider CRUD. Missing a tool to modify a task in flight, but cancellation and re-dispatch suffice.

Maintenance

ActivityInactive

ResponsivenessSyncing

Resources

Need Help?

Related Servers

Unclaimed servers have limited discoverability.

Looking for Admin?

If you are the server author, to access and configure the admin panel.

Related MCP Connectors

NeedHuman A
io.github.MariusAure
Human-as-a-Service for AI agents. Delegate tasks that need a real human, get results via API.
Autonomous Agents App Automation
321
callable A
io.github.CCSTT-dev
API for AI agents to delegate tasks to real humans.
Autonomous Agents Agent Orchestration
32
SiliconBridge
io.github.aataqi-boop
Human-in-the-loop API for AI agents. CAPTCHA, OTP, KYC, and approvals by real humans.
Autonomous Agents Customer Support Security
2
Invoke — hire a human from your AI agent (first post free)A
app.nanocorp.invoke
Let your AI agent hire a human for tasks it can't do — first post free.
Autonomous Agents
32

Related MCP Servers

mcp-humanpages
Autonomous Agents App Automation
human-pages-ai
A
license
A
quality
F
maintenance
Enables AI agents to search for and hire humans for real-world tasks.
Updated 5 months ago (2026-04-10 10:27 UTC)
33
62
7
MIT
Offload MCP
Project Management Workplace & Productivity
DelinSirkov
A
license
Not graded
quality
C
maintenance
Delegates real-world digital tasks to vetted humans directly from AI chat. Provides tools to get quotes, post tasks, and check status with escrow protection.
Updated 2 months ago (2026-07-01 17:31 UTC)
25
MIT
humanrail-mcp-server
prime001
A
license
Not graded
quality
D
maintenance
Enables AI agents to route tasks requiring human judgment (e.g., content moderation, refund decisions, data verification) to a vetted worker pool, with verified results returned via Lightning Network payments.
Updated 3 months ago (2026-06-14 18:49 UTC)
MIT
payhumans-mcp
Autonomous Agents Project Management
Krishnan-govindan
F
license
Not graded
quality
D
maintenance
Lets AI agents natively discover and hire human experts for tasks they can't do themselves, such as research, verification, and expert calls.
Updated 5 months ago (2026-04-07 00:40 UTC)
-

Latest Blog Posts

Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)
By Om-Shree-0709 on July 25, 2026.
mcp
Agent Identity
OAuth 2.1
Your AI Chatbot Just Exposed Your CEO's Salary to an Intern
By Om-Shree-0709 on July 2, 2026.
Agent Identity
MCP Security
OAuth Delegation
Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)
By Om-Shree-0709 on June 30, 2026.
Agentic Ai
Prompt Injection
WebAssembly

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/zyntarasystems/human-dispatch-mcp'

If you have feedback or need assistance with the MCP directory API, please join our Discord server

human-dispatch-mcp

Quick Start

Testing with MCP Inspector

Test sequence:

MCP Client Configuration

Claude Desktop / Cursor / Any MCP Client

HTTP Transport

Tools Reference

Architecture

For Service Providers

1. Set up a webhook endpoint

2. Handle task.new events

Handle provider.verify events

3. Report completion (HTTP transport only)

4. Verify HMAC signatures

Smart Routing

Example Agent Usage

Python with LangGraph

Environment Variables

Security

Roadmap

Contributing

Adding a New Backend Adapter

License

Available Tools

Tool Schema Changelog

Maintenance

Resources

Looking for Admin?

Related MCP Connectors

Related MCP Servers

Latest Blog Posts

MCP directory API

2. Handle `task.new` events

Handle `provider.verify` events