Human-only capabilities for AI agents: ground truth, verification, judgement and real-world action.
Scored across 10 tools
Each tool targets a distinct step in the job lifecycle: discovery (list_services), eligibility (policy_preflight), quoting (request_quote/get_quote), commitment (create_job), observation (get_job), interaction (reply_to_job), termination (cancel_job), and artifacts (list_evidence/list_expenses). The request_quote vs get_quote split (initiate vs poll) is clearly distinguished by their descriptions.
All ten tools follow a uniform human_ prefix with a consistent snake_case verb_noun pattern (get_job, create_job, request_quote, list_services, reply_to_job). No mixing of conventions.
Ten tools is well-scoped for an async human-task marketplace covering discovery, quoting, execution, and evidence retrieval. Each tool maps to a necessary lifecycle stage with no redundancy.
The surface covers the full lifecycle from discovery through quoting, job creation, status polling, messaging, cancellation, and evidence/expense retrieval. A list_jobs tool to enumerate prior jobs without an existing token is a minor gap, but core workflows are complete.
Cancel an unpaid job immediately, or request cancellation for work that may require refund/operator handling.
| Name | Required | Description | Default |
|---|---|---|---|
| job_id | Yes | ||
| reason | No | ||
| job_token | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full behavioral burden. It does disclose that cancellation may be immediate or may route to operator/refund handling, which is meaningful. However, it omits irreversibility, authorization requirements, and what happens to an in-flight job, leaving real gaps for a mutation tool.
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?
A single sentence that front-loads the primary action and then the conditional mode. No wasted words, though the terse phrasing packs two behaviors into one clause without structure that would help an agent branch cleanly.
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 mutation tool with no annotations, no output schema, and 0% parameter coverage, the description explains the behavioral fork but says nothing about parameters, auth, or the result of each path. It is minimally viable but leaves important gaps an agent needs before invoking.
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 0% for three parameters (job_id, reason, job_token), and the description mentions none of them. It never clarifies that reason is optional free text up to 2000 chars, nor why a job_token is required alongside job_id, so it fails to compensate for the documentation gap.
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 (cancel/request cancellation) on a specific resource (job) and distinguishes two modes: immediate cancellation for unpaid work versus a request path for work needing refund/operator handling. It does not name or differentiate itself from siblings like human_get_job or human_reply_to_job, so it falls short of a 5.
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 an explicit selection rule between the two modes based on payment state: 'unpaid job immediately' versus 'work that may require refund/operator handling.' That is actionable conditional guidance, though it offers no exclusions or prerequisites (e.g. who may cancel, what states are eligible).
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Accept the operator's offered commercial terms using the quote_token and create the asynchronous job. Store the returned job_token because it is required for later reads and control.
| Name | Required | Description | Default |
|---|---|---|---|
| quote_id | Yes | ||
| requester | No | ||
| quote_token | Yes | ||
| callback_url | No | ||
| idempotency_key | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden and does contribute real behavior: the job is asynchronous, a job_token is returned, and that token gates later reads and control. It omits idempotency/replay semantics, callback behavior, and error/permission conditions, so the mutation profile is only partially disclosed.
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 tight sentences, front-loaded with the action and precondition, and the retention guidance for job_token is placed where it matters. Nothing extraneous.
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?
A mutation tool with no annotations, no output schema, a nested object, and 5 undocumented parameters needs considerably more than two sentences. The job_token retention tip is useful, but idempotency, callback_url, and requester semantics are left with zero coverage anywhere.
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 0% across 5 parameters, so the description must compensate and largely does not. It mentions quote_token and the returned job_token, but leaves quote_id vs quote_token, idempotency_key, callback_url, and the nested requester object entirely unexplained.
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 names a specific verb+resource ('create the asynchronous job') and frames it as accepting offered commercial terms via quote_token, which separates it from human_request_quote and the get/list siblings. It stops short of explicitly contrasting with those siblings, but the action is unambiguous.
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?
Usage is only implied: the mention of accepting 'offered commercial terms' suggests a prior quote must exist, and 'store the returned job_token ... required for later reads and control' hints at the downstream workflow. No explicit when-to-use or when-not-to-use guidance, and no named alternatives among the nine siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Retrieve job status, messages, history, payment state, expense accounting, result and evidence.
| Name | Required | Description | Default |
|---|---|---|---|
| job_id | Yes | ||
| job_token | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It does not disclose that job_token is effectively an authorization credential, whether the call is read-only, whether it is idempotent, or whether the returned content changes over the job lifecycle. Only the returned facets are hinted at.
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?
A single front-loaded sentence with no wasted framing. The trailing comma-list of returned facets is efficient, though slightly run-on.
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 annotations, no output schema, and no parameter documentation, the description should do more. It partially compensates by listing the returned facets, but omits access/authorization expectations and any lifecycle or routing context an agent needs 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 0% for two required parameters. The description never mentions job_id or job_token, so it adds no meaning about the UUID format or the token's role as an access credential — meaning the schema's bare types and the description together still leave the parameters under-explained.
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 gives a clear verb ('Retrieve') and resource ('job'), and enumerates the facets returned (status, messages, history, payment state, expense accounting, result, evidence). It does not, however, distinguish this from sibling tools like human_list_evidence or human_list_expenses, which overlap on the same returned data.
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?
There is no statement of when to use this tool versus human_list_evidence, human_list_expenses, human_get_quote, or the other job siblings. The agent must infer the routing from the name alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Poll a human-reviewed quote. When status=offered, inspect the operator's service fee, expense authority and expiry. Creating the job accepts those terms. When declined, inspect the reason before deciding whether to resubmit.
| Name | Required | Description | Default |
|---|---|---|---|
| quote_id | Yes | ||
| quote_token | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations exist, so the description carries the full burden, and it does meaningfully disclose behavior: it is a polling operation, results are status-dependent, and 'creating the job accepts those terms' warns of a consequential downstream action implied by the returned terms. It omits auth expectations for the quote_token and any token expiry/polling-rate 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 sentences, front-loaded with the core purpose, then status-conditional guidance with no filler. Efficient, though the two conditional clauses could be tightened slightly.
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 annotations and no output schema, the description does a fair job of framing the status-dependent return semantics and the consequential creation step. However, it leaves both required parameters and the authentication model unexplained, which is a real gap for a 2-required-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 description coverage is 0% and neither quote_id nor quote_token is documented in the schema. The description never explains what these parameters are or where the token comes from, so it fails to compensate for the coverage gap.
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: 'Poll a human-reviewed quote.' That is clearly distinct from siblings like human_request_quote (which creates the quote) and human_get_job. It does not explicitly name those siblings, so it stops short of a 5.
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 tells the agent what to do with each status value (offered -> inspect fee/expiry, declined -> inspect reason), which is implied usage guidance. But it never states when to call this tool in the first place (e.g. after human_request_quote) nor when to prefer a sibling such as human_get_job.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List evidence artifacts and SHA-256 hashes for a secured human job. Download paths require the same job token.
| Name | Required | Description | Default |
|---|---|---|---|
| job_id | Yes | ||
| job_token | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It does disclose the auth model (job token required, and download paths inherit that token), which is genuinely useful. It omits read-only character, return shape, and whether listing itself is token-gated, so gaps remain.
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 tight sentences, front-loaded with the resource and immediately followed by the access constraint. Zero 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?
For a two-parameter, no-annotation, no-output-schema tool, the description covers what is listed and the token requirement, but is silent on what the artifacts/hash payload actually looks like and whether the list is paginated, leaving meaningful gaps.
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 0% for both required parameters. The description mentions the job token and implies the job via 'secured human job', but adds no format, source, or constraints beyond the schema's own field names, leaving the UUID and minLength requirements undocumented.
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 (List) and resource (evidence artifacts / SHA-256 hashes) scoped to a secured human job, so an agent can tell it apart from human_get_job or human_list_expenses. It does not explicitly name a sibling it competes with, but the resource is unambiguous.
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 implies usage context by tying the tool to 'a secured human job' and stating that download paths require the same job token, which signals this is the pre-download enumeration step. It gives no explicit when-not guidance or named alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List pass-through expense requests for a secured job, including exact amount, payment status and receipt metadata.
| Name | Required | Description | Default |
|---|---|---|---|
| job_id | Yes | ||
| job_token | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full disclosure burden, and it discloses little beyond the return contents. It doesn't clarify that this is a read-only operation, what authorization the job_token grants, whether results are paginated, or whether any state is affected.
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?
A single economical sentence that front-loads the verb and resource. It is appropriately sized, though the trailing field list ('exact amount, payment status and receipt metadata') is the least essential part.
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 two-parameter tool with no annotations, no output schema, and no parameter documentation, the definition is too thin. It does enumerate some returned fields but leaves authentication mechanics and parameter semantics entirely unexplained.
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?
With 2 required parameters and 0% schema description coverage, the description must compensate, but it mentions neither job_id nor job_token. The phrase 'secured job' loosely hints that credentials are needed but adds no meaning about which identifier to supply or where the token comes from.
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?
Specific verb 'List' plus a precise resource 'pass-through expense requests' scoped to 'a secured job', which clearly separates it from the other list tools (evidence, services). It stops short of naming siblings explicitly, so an agent must still infer the distinction from the resource noun.
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 never states when to use this versus human_list_evidence, human_get_job, or the quote tools. 'For a secured job' implies a required job context but gives no conditions, prerequisites, or exclusions to route selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Discover agent-consumable capabilities that return human judgement, real-world ground truth, phone-sourced information or physical-world execution with structured results and evidence. If no listed capability fits, use custom-human-task as the fallback for any lawful, safe, well-scoped outcome that requires a human.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full disclosure burden. It describes what the discovered capabilities return ("structured results and evidence"), but says nothing about read-only/non-destructive nature, catalog stability, pagination, or permissions, leaving meaningful behavioral gaps for a no-annotation tool.
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 purpose and followed by fallback routing, with no filler. The phrasing is somewhat abstract ("agent-consumable", "lawful, safe, well-scoped") but each 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, no annotations, and no parameters, the description is nearly sufficient: it explains the discovery purpose, the kinds of capabilities returned, and the fallback path. It does not sketch the shape of a capability entry in the response, a minor gap given the absence of 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?
The tool takes zero parameters, which is the baseline-4 case. The description correctly adds no parameter detail, since there is nothing to disambiguate.
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 gives a clear verb+resource ("Discover agent-consumable capabilities") and enumerates the domains those capabilities cover (human judgement, ground truth, phone-sourced info, physical execution), which lets an agent distinguish it from the job-lifecycle siblings. It never states outright that it returns a catalog/list of service types, so the enumeration is left slightly implicit.
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 explicitly routes the agent to an alternative when this tool does not apply: "If no listed capability fits, use custom-human-task as the fallback." That is concrete when-not guidance, though it does not contrast this tool against siblings such as human_request_quote or human_create_job.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Check whether a proposed human task is eligible before requesting a quote or spending funds.
| Name | Required | Description | Default |
|---|---|---|---|
| objective | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full behavioral burden. It implies a read-only gate but never states that the call is free/side-effect-free, whether it caches, or what the result looks like (eligible flag, reasons, denial codes). For a tool that gates spending, that is a significant gap.
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?
A single front-loaded sentence with zero filler. The eligibility check and the timing constraint are both delivered before any padding.
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 annotations, no output schema, and an undocumented parameter, the description should at minimum hint at the return value and the objective format. It implies a yes/no eligibility outcome, which is partial coverage, but leaves the agent under-informed about both input and result for a funds-gating call.
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 is one parameter, 'objective', with 0% schema description coverage, so the schema explains nothing. The description hints that it concerns a 'proposed human task' but never defines what the objective string should contain, its granularity, or how it is evaluated. The agent must guess the input format.
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 states a specific verb and resource: checking eligibility of a proposed human task. It distinguishes itself implicitly from human_request_quote by positioning itself as the pre-step. It stops short of naming sibling tools, so it is clear but not fully differentiated.
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 a clear when-to-use condition: before requesting a quote or spending funds. That routes the agent to run this ahead of human_request_quote. It does not, however, state what to do if the check fails or name the alternative path explicitly.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Send additional information to the operator, including when a job is waiting for agent input.
| Name | Required | Description | Default |
|---|---|---|---|
| job_id | Yes | ||
| message | Yes | ||
| job_token | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden of behavioral disclosure. It mentions sending information and a timing condition, but does not explain authentication needs (job_token), rate limits, whether the message replaces or appends to existing input, or what happens after sending.
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 a single, front-loaded sentence with no filler. It is appropriately terse, though given the 3-parameter required schema and zero annotation coverage, a slightly more structured explanation would still be concise.
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 tool is a mutation-like action with three required parameters, no annotations, no output schema, and no parameter descriptions. The description leaves major gaps around authentication (job_token), message format, and what the agent should expect after sending, so it is not complete enough for reliable invocation.
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 0%, so the description must compensate for all three required parameters. It only loosely maps 'additional information' to the message parameter and gives no explanation of job_id, job_token, or message constraints (such as length limits).
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 states a clear verb ('Send') and resource ('additional information to the operator'), and adds a usage condition tied to a waiting job. It is clearer than the title alone, but it does not explicitly distinguish itself from sibling tools or mention the reply-to-job framing beyond the name.
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 phrase 'including when a job is waiting for agent input' gives an implied usage context, so an agent can infer one valid scenario. However, it provides no guidance on when not to use this tool or how it relates to alternatives like human_create_job or human_get_job.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Request a priced human-only capability outcome. Submit the result your agent needs, expected deliverables and constraints. If no named service matches, set service_slug to custom-human-task. HumanEndpoint reviews feasibility and returns explicit commercial terms. The response is pending_review and includes a quote_token; poll until offered or declined.
| Name | Required | Description | Default |
|---|---|---|---|
| objective | Yes | ||
| requester | No | ||
| constraints | No | ||
| deadline_at | No | ||
| deliverables | Yes | ||
| service_slug | Yes | ||
| max_budget_usdc | No | ||
| max_expenses_usdc | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full behavioral burden and does well: it discloses that HumanEndpoint reviews feasibility, returns explicit commercial terms, and that the initial response is pending_review with a quote_token that must be polled. It omits auth requirements, rate limits, and whether requesting a quote incurs any charge.
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 four sentences, front-loaded with the core purpose, and each sentence adds useful information about inputs or lifecycle. It avoids repetition and waste.
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 an 8-parameter mutation/request tool with no annotations and no output schema, the description adequately covers the review-and-poll lifecycle and the custom service fallback. It is incomplete on half the parameters and does not explain the commercial terms object in enough detail, so an agent would still have gaps.
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 0% and there are 8 parameters, so the description must compensate but only partially does. It clarifies service_slug with the custom-human-task fallback and loosely maps objective, deliverables, and constraints, but says nothing about requester, deadline_at, max_budget_usdc, or max_expenses_usdc.
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 states a specific verb and resource: request a priced human-only capability outcome, and it explains that HumanEndpoint reviews feasibility. It distinguishes the request step from the later polling for a quote, but it does not explicitly differentiate itself from siblings such as human_get_quote or human_list_services.
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 provides some conditional guidance: use service_slug=custom-human-task when no named service matches. It also says to poll until the quote is offered or declined. However, it does not state when to prefer this tool over siblings like human_get_quote or human_policy_preflight, nor does it mention prerequisites or exclusions.
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.
human_cancel_jobhuman_create_jobhuman_get_jobhuman_get_quotehuman_list_evidencehuman_list_expenseshuman_list_serviceshuman_policy_preflighthuman_reply_to_jobhuman_request_quoteHuman capability for AI agents - real-world action and human judgment.
Lets AI agents use a real human as a tool: visual checks, taste, phone calls, unblocking, approvals
Human judgment for AI agents: discover capabilities, get quotes, and track paid human tasks.
Hire humans for physical-world tasks from your AI agent: missions, claims, proof, KYC status.
Add one secure layer between your agents and this server.
