Hire a real human for real-world verification, product testing, AI output review, and errands.
Scored across 6 tools
Tools cover distinct parts of a human-in-the-loop workflow: manifest lookup, task submission, status checks, free-form messaging, and thread replies/reads. check_message_thread and reply_in_message_thread both operate on threads and require message_id+access_token, which could cause some confusion about when to read versus write, but their read/write purposes are otherwise clear.
Mostly follows a consistent verb_noun or resource_action pattern (check_message_thread, check_task_status, get_human_services, message_human_operator, reply_in_message_thread, submit_human_task). Minor variance in verb style (message vs reply vs submit) is readable and domain-appropriate.
Six tools are well-scoped for a human-task marketplace: discovery, submission, status, messaging, and thread operations. No redundant tools and no obvious missing surface area.
Covers the full lifecycle from service discovery through submission, status tracking, and communication. One minor gap: no tool to list or manage previously submitted tasks/messages, so agents must retain task_ids and tokens themselves.
Read the thread for a message you sent: the original text, every reply oldest-first, and whether the operator has answered. Needs the message_id and the access_token from the submission response. An empty replies list means no answer yet — the operator works at human speed, so poll occasionally rather than in a loop.
Inputs: message_id (required), access_token (required).
Look up a submitted task by its task_id. Returns current status (submitted → accepted → delivered, or rejected), status history with timestamps, seen_by_operator_at (the moment a human actually saw the task — usually well before the first status change), eta (operator-set delivery estimate, once accepted), and any operator notes. Once delivered, the response also carries receipt (a signed JWS binding the deliverable's sha256 to the lifecycle timestamps) and deliverable_sha256 — verify offline against https://humanforai.dev/.well-known/jwks.json. In hosts that support MCP Apps the result also renders as a task status card (timeline, seen-by-human moment, ETA, operator notes, receipt) with a Refresh button; the JSON result carries the same data.
Inputs: task_id (required).
Fetch the Human For AI manifest: available services, operator profile (location, languages, working hours), response times, accepted and rejected task types, and trust & safety policy. Call this first to decide whether and how to hire the human. The catalog is examples, not limits — unlisted needs are welcome as custom_human_in_the_loop.
Inputs: no named parameters.
Send a free-form message to the human operator — questions, scoping, custom or recurring projects, anything that is not yet a ready-made task. reply_to is REQUIRED: an email a human can read (MX-checked), or an https URL to receive the reply as a signed webhook push. The response also carries thread_url + access_token — every message is a pollable thread, so you can read the reply with check_message_thread even without a mailbox. Keep the token: it is shown only once.
Inputs: message (required), reply_to (required), from, subject.
Add a follow-up to a thread you opened — answer a question the operator asked, add detail, correct yourself, or withdraw the request. Prefer this over sending a brand-new message about the same subject. Needs the message_id and access_token from the submission response.
Inputs: message (required), message_id (required), access_token (required).
Submit a task for the human operator to perform in the real world. Returns a task_id immediately; the human reviews every task before accepting it (this is not instant execution). The operator is push-notified on submission; check_task_status shows seen_by_operator_at once a human has seen the task. Free during the pilot. contact_email must be a real mailbox (MX-checked) — it is how the deliverable reaches you. No mailbox? Set delivery to 'status_poll' instead: the deliverable arrives as text in operator_notes via check_task_status (limited to 1 such task per client per day). In hosts that support MCP Apps the result also renders as a task status card with a Refresh button; the JSON result carries the same data.
Inputs: task_type (required), description (required), deadline, delivery, +5 more.
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
Loading tool schema changelog…
Hire a real person for your AI agent: real-world tasks done with photo or video proof.
Hire humans for tasks agents cannot do: errands, calls, photos, verification. Escrowed, verified.
Hire a verified local human for small real-world tasks your AI agent can't do.
Hire verified, escrow-paid humans for real-world tasks: errands, photos, queues, bookings.
Add one secure layer between your agents and this server.
