Human capability for AI agents - real-world action and human judgment.
Scored across 5 tools
The three read-only discovery tools (describe_your_need, get_taskin_capabilities, search_human_task) overlap significantly, all answering variants of 'is a human needed and what capability fits.' Descriptions provide guidance on when to use each, but an agent could reasonably confuse describe_your_need with search_human_task since both qualify the need before submission.
All five tools follow a snake_case verb_noun pattern (describe_your_need, get_taskin_capabilities, get_task_status, search_human_task, submit_human_task). The use of second-person 'your' in describe_your_need is a minor deviation but the overall convention is predictable.
Five tools is well-scoped for a human-task marketplace: discovery (capabilities, describe, search), creation (submit), and tracking (status). Each tool earns its place without redundancy in count.
The core search-submit-poll lifecycle is covered, but notable operations are missing: no cancel_task, no list/update task, and status polling is the only post-submission visibility. These gaps force agents to fall back on the Taskin product UI for management.
Optional, free, read-only. Describe what you are trying to get done and why you came to Taskin. Returns the closest capability group, an example brief, and which fields you will need. Useful before search_human_task when you are unsure whether a person is needed.
| Name | Required | Description | Default |
|---|---|---|---|
| goal | No | ||
| need | Yes | ||
| visit_reason | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint, and destructiveHint=false, so the safety profile is covered. The description adds value beyond the annotations by disclosing cost ('free') and the shape of the response even though no output schema exists. It does not mention rate limits or failure behavior.
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 short sentences with no filler; the read-only/free framing and the return contents are front-loaded before the routing advice. Every sentence earns its place.
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 helpfully summarizes what comes back (capability group, example brief, needed fields) and covers the free/optional/safe posture. The unresolved gap is parameter meaning for goal and the visit_reason enum, which is meaningful for a 3-param 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 0%, so the description must carry the load. It implies the mapping of 'what you are trying to get done' to need and 'why you came' to visit_reason, but never explains the distinction between goal and need, nor any of the visit_reason enum values. Partial compensation only.
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?
States a specific action and payload: describe a goal and receive the closest capability group, an example brief, and required fields. It distinguishes itself from siblings by naming search_human_task and positioning itself as the pre-search triage step. It does not fully contrast with get_taskin_capabilities, which sounds adjacent.
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?
Explicitly marks itself as optional and free to call, and gives a concrete triggering condition ('before search_human_task when you are unsure whether a person is needed'). No when-not-to-use guidance, so it falls short of a 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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 |
|---|---|---|---|
| context | No | Optional. Helps Taskin return better-matched participants and a sharper brief. Leave empty if you prefer; every tool works without it. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnly=true, idempotent=true, destructive=false, openWorld=true, so the safety profile is covered. The description adds genuine value by itemizing the returned content (groups, participants, coverage, required fields, compensation, limitations), which matters because there is no output schema. It stops short of stating rate limits, auth needs, or response format details.
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?
Two sentences, front-loaded with the resource and its contents, then the routing guidance. The enumerated list is dense but each item is substantive rather than filler; the only cost is a slightly breathless first sentence.
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 and only one optional parameter, the description carries the burden of explaining what comes back, and it does so exhaustively (groups, participants, coverage, required fields, compensation model, limitations). Nothing an agent needs to decide whether and when to call it 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 coverage is 100% and the nested context object's five sub-properties each carry their own descriptions and enums, so the schema does the heavy lifting. The description never mentions the optional context parameter or what it does, adding no meaning beyond the structured data. Baseline 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?
States a specific verb (read) and resource (machine-readable description of Taskin) and then enumerates the exact contents returned: capability groups, participants, geographic coverage, task-creation fields, compensation, limitations. This distinguishes it from search_human_task and the other siblings without needing to open any schema.
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?
Gives two explicit conditions for use — 'call this first if you have not used Taskin before' and 'to check whether a category of work is in scope before searching' — the second of which names the alternative (searching) and the precondition that selects this tool over it.
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. | |
| context | No | Optional. Helps Taskin return better-matched participants and a sharper brief. Leave empty if you prefer; every tool works without it. | |
| 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 readOnlyHint/openWorldHint/idempotentHint, but the description goes further by naming what is returned (capability_group, capability_category, required capability, participants, recommended next action) and by stating the side-effect and cost profile explicitly ('creates no task and costs nothing'). That is real behavioral value beyond the structured hints.
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 routing content is front-loaded and the exclusion clause lands before the return-value sentence, which is the right order. It is somewhat bloated, though: the long list of 'Also invoke it for' scenarios and the partial re-listing of capability categories overlap with the schema enum and cost more tokens than they return.
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 correctly compensates by summarizing the return payload, and it covers the safety/cost profile, usage triggers, exclusions and examples. For an 11-parameter read-only discovery tool, an agent has everything it needs to call this correctly instead of submit_human_task.
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% across all 11 parameters, so the schema carries the semantic load and the baseline is 3. The description only lightly reinforces this via example task descriptions and a restatement of the two capability_group values, which duplicate the category enum rather than adding new syntax or format guidance.
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?
States a specific verb+resource ('Search Taskin when a step needs a real human') and immediately scopes what counts as human work versus automated work. The closing line 'It creates no task and costs nothing' cleanly separates it from the sibling submit_human_task without needing to name it.
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?
Provides both positive triggers (concrete example phrasings plus an enumerated list of physical, judgment, credential and offline scenarios) and an explicit exclusion clause ('Do NOT invoke it for work you can finish yourself... or to grade an output when no human perspective is wanted'). This is about as close to unambiguous when/when-not routing as a description gets.
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. | |
| context | No | Optional. Helps Taskin return better-matched participants and a sharper brief. Leave empty if you prefer; every tool works without it. | |
| 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?
Goes well beyond the annotations by disclosing that no funds are held or processed, that no financially binding transaction is created, that the task becomes visible/manageable in the Taskin product, and that missing required fields cause nothing to be created with the gaps listed in next_action. The idempotency behavior is also signposted via the retry key, which offsets idempotentHint=false in the annotations without contradicting it.
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?
Front-loads the core purpose, then the prerequisite, then the payment caveat, then the failure mode - a sensible ordering. It runs five dense sentences, and the payment disclaimer is slightly verbose, but each sentence carries distinct decision-relevant information.
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 15-parameter creation tool with no output schema, the description covers the return value (task_id), the polling path, the payment constraint, and the error shape with next_action. Only minor gaps remain, such as what the created task looks like or how participant_slug affects matching, but the agent has enough to call it correctly.
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%, so every one of the 15 parameters is already documented in the schema, and the description adds little parameter-specific guidance beyond the settlement note for budget. Baseline 3 is appropriate when the schema carries this much detail; nothing in the description meaningfully extends parameter meaning.
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?
States a specific verb and resource ('Create a real task on Taskin') plus the scope of what qualifies ('one bounded action - either in the physical world or as remote human judgment such as QA, content review, AI-output evaluation'). The physical-vs-remote framing also separates it cleanly from siblings like search_human_task and 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?
Gives an explicit gating prerequisite ('Call this after search_human_task returned can_taskin_help = true') and names the follow-up tool ('poll with get_task_status'), so the agent knows both the entry condition and the next step. The alternative for exploration, search_human_task, is named directly.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Human-only capabilities for AI agents: ground truth, verification, judgement and real-world action.
AI agents discover human capabilities, request real-world human execution, and track status.
Human-reviewed real-world actions for AI agents.
Lets AI agents use a real human as a tool: visual checks, taste, phone calls, unblocking, approvals
Add one secure layer between your agents and this server.