A
licenseA
qualityF
maintenanceEnables AI agents to search for and hire humans for real-world tasks.
33
42 npm
7
MIT
humanforai
Officialby humanforai
This server lets AI agents hire a real human operator to perform real-world tasks requiring physical presence, human perception, or judgment. All services are currently free during the pilot phase, with communication via email.
get_human_services: Retrieve the full catalog of available services, operator profile (location, languages, working hours), response times, and trust & safety policy.submit_human_task: Submit a task and receive atask_idfor tracking. Supported task types include:Real-world verification, product/app testing, human judgment & feedback
Data collection, local physical-world tasks, AI output review
Prompt & workflow testing, simulation & automation testing
Accessibility/usability checks, custom human-in-the-loop tasks
Options for deadline, output format (text report, structured JSON, annotated screenshots, video), location, and contact email for deliverable delivery.
check_task_status: Poll a task's progress bytask_idthrough stages: submitted → under_review → accepted → in_progress → delivered (or rejected), with operator notes.message_human_operator: Send free-form messages to scope work, ask questions, or discuss custom projects before formal submission — requires areply_toemail for operator responses.
Click on "Deploy Server".
Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state.
In the chat, type
@followed by the MCP server name and your instructions, e.g., "@humanforaiVerify the price of milk at the local grocery store."
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.
humanforai
MCP server for Human For AI — a human endpoint for AI agents. Let your AI agent hire a real human operator for tasks that need physical presence, human perception, or human judgment:
Real-world verification — confirm a place, product, price, or claim exists, with photo/text evidence
Product or app testing — a real human installs, uses, and reports
Human judgment and feedback — tone, clarity, trustworthiness, design quality
AI output review — human review before your output reaches production
Data collection — gathering/labeling that needs human perception or local access
Local physical-world tasks — visit, photograph, check, measure, observe
…and more — call
get_human_servicesfor the full catalog
All services are free during the proof-of-concept pilot. No API key, no payment. Every task is reviewed by the human operator before acceptance; illegal, harmful, deceptive, unsafe, or privacy-invasive tasks are rejected. First response within 12 hours, any day of the week — typically much faster: the operator is push-notified the moment a task arrives.
Tools
Tool | Purpose |
| Service catalog, accepted task types, limits |
| Submit a task; returns a |
| Poll a submitted task by |
| Ask questions / scope work before submitting |
Status transparency
check_task_status shows progress in real time, not just the final result:
seen_by_operator_at— the moment a human actually saw the task (usually well before the first status change)eta— operator-set delivery estimate, added when the task is acceptedstatus_history— every transition (submitted → accepted → delivered, orrejected) with timestamps
Related MCP server: ProofStream MCP Server
Setup
Claude Code
claude mcp add human-for-ai -- npx -y humanforaiClaude Desktop / other MCP clients (stdio)
{
"mcpServers": {
"human-for-ai": {
"command": "npx",
"args": ["-y", "humanforai"]
}
}
}Clients with native remote MCP support
You don't need this package — connect directly to the hosted endpoint (streamable HTTP, no auth):
https://humanforai.dev/mcpE.g. Claude (Settings → Connectors → Add custom connector), or:
claude mcp add --transport http human-for-ai https://humanforai.dev/mcpHow it works
This package is a thin stdio proxy to the hosted Human For AI MCP endpoint. Tool definitions come from the live server, so they are always current — the package itself has no logic to go stale.
Previously published as human-api, which still works but is deprecated in favor of this package.
Typical flow
get_human_services— see what the operator can dosubmit_human_task— be specific and self-contained; includecontact_emailto receive the deliverablecheck_task_status— poll with the returnedtask_id
Links
Website: https://humanforai.dev
API docs: https://humanforai.dev/api
Machine-readable manifest: https://humanforai.dev/.well-known/agent.json
OpenAPI spec: https://humanforai.dev/openapi.json
Trust & safety: https://humanforai.dev/trust
License
MIT
Available Tools
4 toolscheck_task_statusCheck task statusARead-onlyInspect
Look up a submitted task by its task_id. Returns current status (submitted → under_review → accepted → in_progress → delivered, or rejected), status history with timestamps, and any operator notes.
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| task_id | Yes | Task ID returned by submit_human_task, e.g. HFAI-2026-A1B2C3D4 |
TDQS
A4.6/5.0
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already note readOnlyHint and openWorldHint. The description adds the status progression, history, and operator notes, providing useful behavioral details beyond annotations.
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?
Two sentences, front-loaded with action and resource, no wasted words. Information is efficiently presented.
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?
For a simple 1-parameter, no-output-schema tool with good annotations, the description fully covers return values (status, history, notes) and usage context, leaving no gaps.
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 has 100% coverage for the single parameter. The description explains the task_id format with an example, adding meaningful context beyond the 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's purpose: to look up a submitted task by its task_id. It lists the status flow, making the action specific and distinguishing it from sibling tools like submit_human_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?
Implies usage after task submission, but lacks explicit when-not-to-use or alternatives. However, sibling tool names provide context, and the description's clarity compensates.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_human_servicesList human servicesARead-onlyInspect
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.
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
TDQS
A5/5.0
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description uses 'Fetch' and 'Call this first,' which imply a read-only, informational operation consistent with the readOnlyHint annotation. It also aligns with openWorldHint by stating the catalog is examples, not limits. The description adds context about the manifest contents beyond the annotations, providing transparent expectations.
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 first sentence listing the manifest contents and the second providing a clear usage directive. The open-world note is brief and adds value without bloat. The structure is front-loaded with the core purpose and then actionable guidance.
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?
The description is complete for its simple, parameterless, read-only nature. It explains what information will be returned (services, profile, policies, etc.), how to use the information (decide whether and how to hire), and how to handle catalog gaps. No output schema is present, but the description sufficiently covers expected content.
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?
The tool has zero parameters and the schema description coverage is 100% (empty schema). There is nothing to explain about parameters; the description correctly omits any parameter discussion. The baseline for high schema coverage applies, and no additional compensation is needed.
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 fetches the Human For AI manifest and enumerates its contents (services, operator profile, response times, task types, trust & safety). It also explicitly says 'Call this first to decide whether and how to hire the human,' which distinguishes its purpose from the sibling tools that submit or check 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 provides explicit timing guidance: 'Call this first to decide whether and how to hire the human.' This tells the agent when to use this tool relative to the alternatives (e.g., before submit_human_task or message_human_operator). The note that unlisted needs are welcome as custom_human_in_the_loop also clarifies how to handle catalog gaps.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
message_human_operatorMessage the human operatorAInspect
Send a free-form message to the human operator — questions, scoping, custom or recurring projects, anything that is not yet a ready-made task. Include reply_to (an email you or your principal can read); it is the only way the operator can answer.
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| from | No | Your agent or system identifier | |
| message | Yes | The message. Plain language, English. | |
| subject | No | Short subject line | |
| reply_to | No | Email address for the reply — strongly recommended |
TDQS
A4.4/5.0
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations indicate it's a write operation with side effects. Description adds that reply_to is the only way to get a response, clarifying the communication pattern. 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?
Two sentences with a list of use cases in the first sentence. No redundant words; every part contributes to understanding.
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?
For a simple message-sending tool with no output schema, the description covers purpose, usage, and critical parameter advice. It does not discuss return values, but that is acceptable given the tool's nature.
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?
All parameters have schema descriptions (100% coverage). The description adds value by stressing the importance of reply_to and explaining its role, going beyond the schema's 'strongly recommended'.
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 verb ('Send'), resource ('human operator'), and scope ('free-form message... anything not yet a ready-made task'). It distinguishes from siblings by specifying it's for unstructured requests.
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 provides context on when to use (for questions, scoping, custom projects) and implies not for ready-made tasks. However, it lacks explicit exclusions or direct comparison with siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
submit_human_taskSubmit a task to the humanAInspect
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). Free during the pilot. Include contact_email — it is how the deliverable reaches you.
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| deadline | No | ISO 8601 datetime, e.g. 2026-07-10T12:00:00+03:00 | |
| requester | No | Your agent or system identifier, e.g. my-agent/1.0 | |
| task_type | Yes | Service category — see get_human_services for descriptions. The list is not exhaustive: use custom_human_in_the_loop for anything that fits no other category | |
| description | Yes | What to do, where, and what success looks like. Specific, self-contained tasks are accepted faster. | |
| contact_email | No | Where the deliverable and clarifying questions are sent. Strongly recommended. | |
| output_format | No | text_report (default), text_report_with_photos, structured_json, annotated_screenshots, or video | |
| location_detail | No | City, address, or area — required in practice when location_required is true | |
| location_required | No | true if the task needs physical presence (coverage is confirmed at review) |
TDQS
A4.4/5.0
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond annotations, adds key behavioral details: 'the human reviews every task before accepting it (this is not instant execution)' and 'Free during the pilot', which help set accurate expectations.
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?
Four succinct sentences with no wasted words; each sentence adds essential info: purpose, behavior, cost, and key parameter advice.
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?
Covers main aspects: purpose, return value (task_id), review process, cost, and highlights important parameter. Lacks output schema but description partially compensates.
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. Description adds minor extra context about contact_email being crucial, but does not significantly enhance understanding beyond 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?
Clearly states 'Submit a task for the human operator to perform in the real world' and 'Returns a task_id immediately', distinguishing it from sibling tools like check_task_status and get_human_services.
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?
Implies usage for submitting tasks to humans, and notes that human reviews every task before acceptance, but does not explicitly state when to avoid using it or when to prefer siblings.
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.
4 tool updates
v0.1.0- First observed
check_task_status - First observed
get_human_services - First observed
message_human_operator - First observed
submit_human_task
TDQS
A4.6/5.0
Scored across 4 tools
Disambiguation5/5
Each tool serves a distinct purpose: checking task status, fetching service manifest, messaging the operator, and submitting tasks. No overlap or ambiguity.
Naming Consistency5/5
All tool names follow a consistent verb_noun pattern using underscores (check_task_status, get_human_services, etc.), making them predictable and easy to differentiate.
Tool Count5/5
With 4 tools, the server is well-scoped for its human-in-the-loop purpose—covering information retrieval, communication, task submission, and status tracking—without excess or deficiency.
Completeness4/5
The tool surface covers core interactions (info, messaging, submit, status), but lacks a cancel/modify task capability, which could be needed for real-world tasks.
Maintenance
ActivityMaintained
ResponsivenessNo issues
Related MCP Connectors
Human-as-a-Service for AI agents. Delegate tasks that need a real human, get results via API.
API for AI agents to delegate tasks to real humans.
AI agents hire a human to observe, log or film on site. Typed results, feasibility before payment.
41AI agents hire a human to observe, log or film on site. Typed results, feasibility before payment.
41
Related MCP Servers
- AlicenseAqualityCmaintenanceEnables AI agents to dispatch human verifiers for physical world tasks like product authentication, property inspection, and document verification, returning timestamped evidence reports.347 npmMIT
- AlicenseAqualityBmaintenanceEnables AI agents to recruit real humans for evaluation tasks like surveys, A/B tests, and ratings on text, images, audio, and video, returning aggregated results directly into the conversation.137MIT
- AlicenseNot gradedqualityDmaintenanceEnables 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.MIT
