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.

Register providers first with human_register_provider, then dispatch tasks to them.

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:

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: "2027-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_usd: 25, currency: "USD" }, deadline: { complete_by: "2027-01-20T00:00:00Z", urgency: "low" }, proof_required: ["text_report", "photo"], quality_sla: "high" }

3. 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)

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)

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)

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:

1. List all tasks: {}

2. List completed tasks: { status: "completed" }

3. List webhook provider tasks: { backend_id: "webhook_provider", 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)

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:

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)

Register a new webhook provider to receive dispatched tasks.

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": "..." }

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)

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)