io.github.zyntarasystems/human-dispatch-mcp

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)

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…

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)

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)

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)