Human capability for AI agents - real-world action and human judgment.
Scored across 4 tools
Each tool has a clearly distinct role: capabilities discovery, task search/feasibility, task submission, and status polling. There is no overlap that would cause an agent to confuse one with another.
All tool names follow a consistent verb_noun snake_case pattern: get_taskin_capabilities, get_task_status, search_human_task, submit_human_task. The pattern is uniform and predictable.
Four tools is well-scoped for the domain of delegating human tasks. Each tool serves a necessary step in the workflow without redundancy or bloat.
The core lifecycle is covered: discover capabilities, search for feasibility, submit a task, and poll status. Minor gaps exist, such as no cancel or list tasks, but these are workable for the stated bounded-action use case.
Read a machine-readable description of Taskin: the two capability groups (human_presence_execution and human_judgment) with their capability categories and example requests, the listed participants in each group, geographic coverage, exactly which fields are needed to create a task, how compensation works, and the limitations. Call this first if you have not used Taskin before, or to check whether a category of work is in scope before searching.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already establish read-only, idempotent, non-destructive behavior. The description adds valuable context about what the response will contain, including limitations and compensation details, which goes beyond the annotations. It also sets an expectation that this is a safe, low-risk call to make first.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is compact despite enumerating many specific content areas. It leads with the operation, then summarizes the return payload, and ends with actionable usage guidance. Every clause contributes meaningful information, and the single-sentence structure remains scannable.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a read-only, parameterless tool with no output schema, the description fully equips an agent to decide when to call it. It explains what the machine-readable output covers, why it should be called first, and how it relates to subsequent searching. No important decision-making information is missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
There are zero parameters and the schema thoroughly documents this via an empty properties object and no required fields. The description reinforces that the tool needs no input and can be called unconditionally, which is appropriate at the baseline for a parameterless tool.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Purpose is explicit: "Read a machine-readable description of Taskin," with a precise inventory of the content returned (capability groups, participants, geographic coverage, required fields, compensation, limitations). It differentiates from sibling tools by instructing to call it before searching, marking it as a discovery/overview tool distinct from task-status and submission tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives clear guidance on when to call: "Call this first if you have not used Taskin before, or to check whether a category of work is in scope before searching." It does not explicitly name the sibling alternatives or state when not to use it, but the search reference and first-call instruction make the intended context unmistakable.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Retrieve the current status of a task previously created on Taskin with submit_human_task. Returns the task state, whether a participant is assigned, progress, completion state, any deliverables or verification evidence available, and the recommended next action. Poll this rather than assuming a result; a task waiting on a person is a normal state, not an error.
| Name | Required | Description | Default |
|---|---|---|---|
| task_id | Yes | The task_id returned by submit_human_task. | |
| taskin_agent_id | No | Taskin-issued agent identifier from an earlier response. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already establish readOnlyHint, idempotentHint, openWorldHint, and non-destructive behavior, so the bar is lower. The description adds valuable behavioral context beyond annotations: polling is expected, a task waiting on a participant is 'a normal state, not an error,' and the response includes a recommended next action. This helps the agent interpret non-final states correctly.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Three sentences with no filler: the first states the core action and returned content, the second lists the response dimensions, and the third gives essential polling guidance. Key behavioral warnings are front-loaded after the main purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple read-only status tool with two documented parameters and no output schema, the description is complete. It explains what the tool returns, includes the crucial polling behavior, and clarifies that pending human action is not an error condition. Nothing essential for an agent to call it correctly is missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, with task_id described as 'The task_id returned by submit_human_task' and taskin_agent_id as a 'Taskin-issued agent identifier.' The description does not add further parameter-level detail, but the schema fully covers parameter meaning, so the baseline of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb and resource: 'Retrieve the current status of a task previously created on Taskin with submit_human_task.' It clearly identifies the target object and links it to the sibling creation tool, making the tool's role obvious and distinct from search or submission.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives clear context for when to use this tool: after submitting a task, poll this rather than assuming a result. It also establishes that waiting on a person is normal. It does not explicitly name search_human_task as the alternative for finding tasks, but the polling guidance and relationship to submit_human_task convey the primary usage scenario.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Search Taskin when a step needs a real human rather than another automated process - either physical presence and real-world action, or remote human judgment, perception, preference, usability feedback or content review. Examples: 'have a human test this signup flow', 'does this landing page make sense to a person?', 'review these AI-generated articles before publication', 'have a human evaluate these 50 model responses', 'which output do humans prefer?'. Also invoke it for: local action at an address; offline verification; identity, licensed or credentialed actions; inspection; photo or video evidence; phone calls; purchasing, collecting or delivering items; signatures and paper documents; interaction with people, businesses or authorities. Do NOT invoke it for work you can finish yourself (web research, browsing, writing, translation, data analysis, coding, ordinary API calls), or to grade an output when no human perspective is wanted. Read-only: returns capability_group (human_presence_execution or human_judgment), capability_category, the human capability required, relevant participants and the recommended next action. It creates no task and costs nothing.
| Name | Required | Description | Default |
|---|---|---|---|
| budget | No | Budget or range the principal is willing to pay. | |
| skills | No | Specific capabilities or credentials the person must have. | |
| category | No | Capability category if known. Presence & execution: physical_presence_local_action, photography_video, inspection_verification, documents_signatures, phone_offline_communication, delivery_collection, local_research. Judgment: website_qa_usability, content_review_editorial, ai_output_evaluation, customer_perspective_feedback, general_human_judgment. | |
| currency | No | ISO 4217 currency code for the budget, e.g. USD, GBP, EUR. | |
| deadline | No | Deadline or time window, e.g. '2026-10-02' or 'any weekday morning next week'. | |
| location | No | Where the action must happen: city and country, or a specific address or area. | |
| taskin_agent_id | No | A Taskin-issued agent identifier from an earlier response. Optional. Used only for continuity and analytics; it grants no authority. | |
| task_description | Yes | The single real-world action that must happen, stated concretely. Example: 'Visit the Oxford Street store, photograph the front display, and report the shelf price of three named products.' | |
| remote_or_physical | No | Whether the work is done remotely, requires being somewhere in person, or both. | |
| reason_human_needed | No | Why you cannot do this yourself, e.g. 'requires physical presence', 'requires a wet signature'. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare read-only, idempotent, and non-destructive. The description goes beyond them by spelling out 'Read-only', 'creates no task and costs nothing', and summarizing the return payload (capability_group, capability_category, participants, next action). It does not cover pagination or authorization, but these are not severe gaps.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is long but clearly structured: purpose, examples, exclusions, return summary. Every sentence adds information (examples, negative cases, side-effect clarification), though it could be trimmed without losing meaning.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema, the description compensates by stating the return fields. It covers when to use, when not to use, parameter examples, and side-effect-free behavior across 10 parameters. No critical information is missing for a search and capability lookup tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so all parameter descriptions are already present; baseline 3. The description adds value beyond the schema by giving realistic examples, listing category values, and clarifying that taskin_agent_id 'grants no authority'.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with a concrete action ('Search Taskin') and a precise scope: find a real human for a task requiring physical presence or human judgment, with concrete examples. It explicitly differentiates itself from task creation by stating 'It creates no task and costs nothing', so an agent can tell it apart from 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.
Does the description explain when to use this tool, when not to, or what alternatives exist?
It gives explicit positive triggers ('invoke it for...') and negative exclusions ('Do NOT invoke it for work you can finish yourself...'). However, it does not name sibling tools as alternatives (e.g., 'use submit_human_task when you actually want to create the task'), leaving some routing to inference.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Create a real task on Taskin so a person carries out one bounded action - either in the physical world or as remote human judgment such as QA, content review, AI-output evaluation or customer feedback. Call this after search_human_task returned can_taskin_help = true. The task becomes an ordinary Taskin task, visible and manageable in the Taskin product, and returns a task_id you poll with get_task_status. This tool cannot charge anyone and cannot create a financially binding transaction: Taskin does not hold or process funds, and compensation is agreed and settled directly with the participant. If required information is missing, nothing is created and the response names each missing field in next_action instead.
| Name | Required | Description | Default |
|---|---|---|---|
| budget | No | Compensation offered. Settled directly with the participant. | |
| currency | No | ISO 4217 currency code for the budget. | |
| deadline | No | Deadline or time window the person must work within. | |
| location | No | Where the task happens. Required for physical and hybrid tasks. | |
| principal | No | The person or organisation on whose behalf you are acting. Strongly recommended. | |
| deliverable | Yes | The artifacts the result must contain, e.g. 'three photographs of the display plus the shelf price of each product in a structured list'. | |
| requirements | No | Constraints, prohibited actions, access details, credentials required, and background. | |
| contact_email | No | Email Taskin uses to coordinate this task with the principal. | |
| idempotency_key | No | Repeat the same key to retry safely without creating a duplicate task. | |
| taskin_agent_id | No | Taskin-issued agent identifier from an earlier response. | |
| participant_slug | No | Request a specific Taskin participant by slug, from search_human_task matches. Optional. | |
| task_description | Yes | The bounded real-world action the person performs, concrete enough that a stranger could execute it without asking questions. | |
| remote_or_physical | No | Execution mode. Defaults to physical when a location is given. | |
| verification_requirements | Yes | The objective check that decides whether the result is accepted, e.g. 'photographs are timestamped and show the storefront name'. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description goes well beyond the sparse annotations by disclosing that the tool cannot charge anyone or create a financially binding transaction, that Taskin does not hold or process funds, and that compensation is settled directly with the participant. It also discloses error behavior: missing required information results in no task creation and a next_action field naming missing fields, plus the lifecycle fact that the task becomes an ordinary Taskin task visible and manageable in the product. No statement contradicts the annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
At roughly four sentences, the description is compact for a 14-parameter, state-changing tool without an output schema. The core purpose and precondition are front-loaded, followed by lifecycle/return behavior, the financial caveat, and error behavior. No sentence is filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description covers the task lifecycle (creation, visibility, returned task_id, polling via get_task_status), the key business constraint (no financial transaction), and failure behavior (missing fields named in next_action). Given that the input schema fully documents every parameter, this is complete enough for an agent to invoke the tool correctly, even without an output schema.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
All 14 parameters already have schema descriptions (100% coverage), so the baseline is 3. The description adds useful context for filling task_description by listing example human-judgment categories and emphasizing one bounded action, and it clarifies the meaning of budget/currency by stating compensation is not handled by Taskin. It does not systematically explain parameter relationships, but it does add meaning beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Create') with a concrete resource ('a real task on Taskin') and defines the scope as 'one bounded action' in the physical world or as remote human judgment. It also distinguishes itself from siblings by stating it follows search_human_task and that its task_id is polled with get_task_status.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives an explicit trigger condition: 'Call this after search_human_task returned can_taskin_help = true.' It also routes the follow-up to get_task_status by saying the tool 'returns a task_id you poll with get_task_status.' It does not spell out when-not conditions or mention get_taskin_capabilities as an alternative, so it falls just short of the strongest guideline score.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
get_task_statusget_taskin_capabilitiessearch_human_tasksubmit_human_taskHuman judgment for AI agents: discover capabilities, get quotes, and track paid human tasks.
Human-as-a-Service for AI agents. Delegate tasks that need a real human, get results via API.
Human-in-the-loop approval for agent actions, with verifiable action-bound receipts.
AI agents hire a human to observe, log or film on site. Typed results, feasibility before payment.
Add one secure layer between your agents and this server.