humanforai
OfficialServer Configuration
Describes the environment variables required to run the server.
| Name | Required | Description | Default |
|---|---|---|---|
No arguments | |||
Instructions
Guidance the server publishes about itself, which clients place ahead of the tool catalog so the model reads it before choosing anything.
This server publishes no instructions, or was last inspected before Glama recorded them.
Capabilities
Features and capabilities supported by this server
Protocol revision2025-11-25
| Capability | Details |
|---|---|
| tools | {} |
Tools
Functions exposed to the LLM to take actions
| Name | Description |
|---|---|
| get_human_servicesA | 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. |
| submit_human_taskA | 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. |
| check_task_statusA | 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. |
| message_human_operatorA | 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. |
Prompts
Interactive templates invoked by user choice
| Name | Description |
|---|---|
No prompts | |
Resources
Contextual data attached and managed by the client
| Name | Description |
|---|---|
No resources | |
TDQS
Scored across 4 tools
Each tool serves a distinct purpose: checking task status, fetching service manifest, messaging the operator, and submitting tasks. No overlap or ambiguity.
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.
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.
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.