Human-only capabilities for AI agents: ground truth, verification, judgement and real-world action.
Scored across 10 tools
Each tool has a clearly distinct role in the human-assisted job lifecycle: discover services, preflight eligibility, request/get quotes, create/get/cancel/reply to jobs, and list evidence or expenses. Overlap between request_quote and get_quote is naturally sequential rather than ambiguous, and create_job is distinguished from job retrieval and reply operations.
All tools use the human_ prefix and snake_case, with predictable verb-object names for most operations. human_policy_preflight deviates from the verb_noun pattern by using a noun phrase, and human_reply_to_job includes a preposition, but overall the set is highly consistent.
With 10 tools, the server is well-scoped for a human-execution workflow. Each tool maps to a necessary lifecycle stage, and the count avoids both thinness and unnecessary bloat.
The surface covers the core lifecycle: discovery, preflight, quoting, job creation, status retrieval, communication, cancellation, evidence, and expense listing. Minor gaps exist, such as no explicit payment or job-listing tool, but agents can work around these through the existing job-token-based flow.
Cancel an unpaid HumanEndpoint job immediately, or request cancellation of human work that may already be underway and may require refund or 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?
Annotations already declare destructiveHint=true and openWorldHint=true, so the mutation risk is covered. The description adds context the annotations do not: the outcome is mode-dependent, and a request may not take effect immediately because it can require refund processing or operator intervention. It still omits idempotency and what the response confirms, so it is good rather than exhaustive.
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 that pairs each action mode with its condition, with no filler or restatement of the name. Every clause 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?
For a destructive no-output-schema tool, the description usefully flags that the outcome can be asynchronous and involve refunds or operators, which is more than the annotations convey. However, it does not describe what the caller gets back (confirmation vs. pending state) or the meaning of reason, and no output schema exists to fill that gap.
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 all three parameters, so the description carries the full burden but says nothing about job_id, job_token, or reason. job_id and job_token are inferable from their names, but a token requirement and a 2000-char reason field are left unexplained. This is a clear gap against the low-coverage baseline.
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) and resource (HumanEndpoint job), and usefully splits the action into two modes: immediate cancellation for unpaid jobs vs. a cancellation request for work already underway. The name/title already imply cancellation, but the description adds the important scope distinction of unpaid vs. in-progress. It does not explicitly contrast with siblings, though cancel is self-evidently distinct from create/get/list/reply.
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 the selecting condition between the two modes: unpaid work is cancelled immediately, while work already underway becomes a request that may require refund or operator handling. That is genuine when-to-use guidance. It stops short of stating when not to use the tool or naming alternatives (e.g., using reply_to_job instead).
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Accept the human-reviewed commercial terms using the quote_token and create the asynchronous HumanEndpoint job. Creating the job starts a workflow that may lead to human execution in the real world after required payment. 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?
Annotations only declare readOnlyHint=false, openWorldHint=true, destructiveHint=false; the description goes well beyond that by disclosing that the job is asynchronous, that it may trigger real-world human execution, that required payment gates that execution, and that the returned job_token must be persisted for later reads and control.
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 action and the authorizing token, then the consequence and the token-retention instruction. Dense and mostly waste-free, though the opening sentence packs two ideas that could be split.
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 mutating, open-world async tool with no output schema and 0% schema coverage, the description covers the lifecycle and real-world side effects well but leaves the callback mechanism, idempotency semantics, and the nested requester object unexplained. Partial but not full coverage of what an agent needs.
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 five parameters exist. The description explains only quote_token (authorization) and the returned job_token; quote_id, requester, callback_url, and the required idempotency_key are left entirely undocumented, with callback_url being a notable omission for an async job.
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 concrete verb (create) and resource (asynchronous HumanEndpoint job), and names the input that authorizes it (quote_token). It is distinguishable from the get/cancel/list siblings by being the sole creation entry point, though it never names those siblings explicitly.
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 implied rather than stated: 'Accept the human-reviewed commercial terms using the quote_token' suggests this must follow a quote step (human_request_quote / human_get_quote), but no alternative or precondition is named outright. An agent can infer the ordering but gets no explicit when-not guidance.
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?
Annotations already declare readOnlyHint=true, destructiveHint=false, and openWorldHint=false, so the safety profile is covered. The description adds value by enumerating the returned data domains, which matters since no output schema exists, but it says nothing about auth/token semantics, error modes, or access scope.
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 tight sentence, front-loaded with the verb and resource, with a compact enumeration of return contents. No 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?
Given no output schema, the enumerated return fields are genuinely useful, but the definition is thin for a two-parameter authenticated read: token semantics and failure behavior are unaddressed. Adequate but with clear 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, and the description provides no explanation of what job_id or job_token mean or where they come from. With two undocumented parameters, the description fails to compensate for the schema 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 ('Retrieve') and resource ('job'), and enumerates the payload it returns (status, messages, history, payment state, expense accounting, result, evidence). It does not contrast itself with siblings like human_list_evidence or human_list_expenses, which overlap in the data they expose.
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 when-to-use guidance, no prerequisites, and no indication of when a sibling (e.g., human_list_evidence, human_list_expenses) would be preferable. Usage is only inferable from the required job_id/job_token pair.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Retrieve a human-reviewed quote. Polling is always available as a fallback even when the quote request supplied callback_url. 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?
Annotations already declare readOnlyHint=true, destructiveHint=false and openWorldHint=false, so the safety profile is covered. The description goes beyond that by disclosing polling fallback behavior, the offered/declined status branches, and that 'creating the job accepts those terms' — genuine behavioral context. It omits auth/token handling 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?
Four short sentences, front-loaded with the core action, and each subsequent sentence carries distinct behavioral value (polling fallback, offered-status fields, declined handling). No 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?
With no output schema, the description must carry return-value burden and does partially describe what to inspect (service fee, expense authority, expiry, decline reason). But it leaves the two required parameters unexplained and does not enumerate the full status set or error cases, leaving visible 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 the description neither mentions nor explains quote_id or quote_token. With two required parameters at zero coverage, the description should compensate but adds nothing about parameter meaning or usage.
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 ('Retrieve a human-reviewed quote'), which is clearly distinct from human_request_quote's create-quote behavior. It stops short of naming a sibling tool explicitly, 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?
It gives real usage context: polling is always available as a fallback even when callback_url was supplied, and it tells the agent what to do at status=offered vs. declined. It does not, however, name an alternative tool or state an exclusion condition explicitly.
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?
Annotations already declare readOnlyHint=true, destructiveHint=false and a closed-world scope, so the safety profile is covered. The description usefully adds that the job token is required to obtain download paths, but it says nothing about result limits, ordering, or what happens with an invalid/expired token.
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 with the resource and the token prerequisite front-loaded; nothing is redundant or padded.
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 two-parameter listing tool with no output schema, the description covers what is returned (artifacts plus SHA-256 hashes) and the auth requirement. It is close to complete, with only pagination/volume expectations left unstated.
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 carry the load; it partially does by implying the token param is required and must match the job's token. However, it never explains what job_id identifies or the token's provenance, so the two required params remain only partially illuminated.
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 a specific resource (evidence artifacts and SHA-256 hashes) scoped to a secured human job. It is clearly distinguishable from siblings like human_get_job or human_list_expenses by resource, though it never names or contrasts an alternative explicitly.
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 when-to-use or when-not-to-use guidance and no mention of alternative tools for retrieving job-related data. The only directive-like sentence ('Download paths require the same job token') is an auth prerequisite, not usage routing.
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?
Annotations already declare readOnlyHint=true and destructiveHint=false, so the safety profile is covered. The description adds useful return-field context (amount, payment status, receipt metadata) and the 'secured job' access constraint, but says nothing about pagination, ordering, or what an empty result means.
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 well-formed sentence with the resource and scope front-loaded, followed by the returned fields. Nothing is redundant, though the trailing field list is slightly padded for a one-liner.
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 two-parameter tool with no output schema, the description adequately conveys purpose and result contents but omits parameter meaning, auth expectations around the token, and any result-set behavior. It is minimum viable rather than complete.
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 the description never mentions job_id or job_token by name. 'For a secured job' only vaguely hints that a job identifier and credential are required; the agent gets the real parameter meaning from the schema's pattern/minLength, not the prose.
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 ('List pass-through expense requests') and scopes it to 'a secured job', which separates it from the evidence/service list siblings. It does not explicitly name an alternative tool, so differentiation is inferential rather than stated.
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 when-to-use guidance, no statement of preconditions (a secured job requiring a token), and no routing away from human_list_evidence or human_list_services. The agent must infer this is the right tool purely from the noun 'expense'.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Discover human capabilities for tasks software cannot complete alone: call a business, supplier or organisation; check current price, stock, lead time or availability by phone; obtain information that is only available by speaking to a person; verify a physical fact or location in the real world; independently review AI output; apply human judgement; perform bounded manual research; or carry out another lawful physical-world action. Results are structured and can include evidence. If no listed capability fits, use custom-human-task.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, destructiveHint=false and openWorldHint=false, so the safety profile is covered — openWorldHint=false is consistent with browsing a fixed service catalog. The description adds that results are structured and may include evidence, which is useful, but it discloses nothing about pagination, catalog size, or how evidence is returned.
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 core purpose and usage context are front-loaded in the first clause, and every enumerated capability contributes to task matching rather than filler. The enumeration is long and run-on, but no sentence is redundant.
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 zero-parameter discovery tool with no output schema, the description covers what it enumerates, the nature of the results (structured, may include evidence), and the fallback path. Only minor gaps remain around result volume and the exact name of the fallback 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?
There are zero parameters, so the baseline is 4; the trivial empty schema leaves nothing for the description to clarify, and it correctly implies no input filtering is required.
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 (discover/list) and resource (human capabilities), then enumerates concrete capability categories — phoning suppliers, price/stock checks, physical-world verification, reviewing AI output. An agent immediately understands this is a catalog of human-performed services, though the tool is not explicitly contrasted with siblings like human_create_job or human_request_quote.
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 when-to-use context (tasks software cannot complete alone, information only obtainable by speaking to a person) and a routing fallback: 'If no listed capability fits, use custom-human-task.' This is strong guidance, though the named fallback does not exactly match any sibling name in the provided list, which slightly weakens the routing.
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?
Annotations declare readOnlyHint=false, destructiveHint=false, openWorldHint=false, and the description adds the gating intent (pre-spend eligibility check). However, it says nothing about what the check actually evaluates, whether the call has side effects despite not being read-only, or whether it is idempotent — a notable omission given readOnlyHint=false on a tool that reads like a query.
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 filler; the timing constraint is stated up front and every clause 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?
For a one-parameter gate with no output schema and safety already covered by annotations, the description is nearly sufficient. It is missing only what a caller should expect back from the check (eligible/ineligible and why), which matters for a preflight gate.
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?
One parameter ('objective') with 0% schema description coverage, so the description carries the burden. It contextualizes the parameter as the proposed human task being evaluated, which is helpful, but gives no detail on expected format, level of detail, or length expectations.
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: checking eligibility of a proposed human task. The phrase 'before requesting a quote or spending funds' implicitly positions it upstream of human_request_quote, so an agent can roughly place it among siblings, though no sibling is named outright.
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?
Clearly states the usage context: run this prior to requesting a quote or committing funds. That gives a concrete when-to-use trigger tied to the request-quote flow, but it stops short of explicit when-not-to-use conditions or a named alternative.
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 human operator working on the job, including when the 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?
Annotations already establish the mutation profile (readOnlyHint=false, destructiveHint=false, openWorldHint=true), so the description only needs to add context. It clarifies that the message goes to a human operator and is relevant during a wait-for-input state, but says nothing about auth requirements beyond the token, rate limits, or delivery semantics.
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 filler; the core action and the key triggering condition are stated immediately. Slightly terse given the gaps elsewhere, but nothing is wasted.
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 three undocumented required parameters, no output schema, and no annotation-level explanation of parameters, the description is too thin. An agent still lacks guidance on token semantics, message constraints, and what a successful reply produces.
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 three required parameters, so the description carries the full burden and does not compensate. It never explains job_id, job_token, or message (including the 10000-char limit), leaving all parameter meaning to the raw JSON schema types.
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 (send/reply) and resource (information to the human operator on a job), so an agent can tell it apart from human_get_job or human_create_job. It is clear but does not explicitly contrast itself with the other human_* siblings that also touch jobs.
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 the job is waiting for agent input' implies a usage condition, which is useful, but no alternative tools are named and no when-not-to-use guidance is given. Usage must still be inferred from the sibling list.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Submit a request for human-reviewed terms for a real-world task whose cost depends on scope, feasibility, urgency or conditions. This sends the request into a HumanEndpoint workflow for review by a human operator, but does not commit funds or start execution. HumanEndpoint returns commercial terms that can be accepted or declined before payment. Provide callback_url to receive signed quote.offered or quote.declined webhooks instead of relying only on polling. Suitable tasks include calling a business for current price, stock, lead time or availability; retrieving information only available by phone; verifying a real-world fact; checking AI output; applying human judgement; doing bounded research; or carrying out a physical-world task. If no named service matches, set service_slug to custom-human-task.
| Name | Required | Description | Default |
|---|---|---|---|
| objective | Yes | ||
| requester | No | ||
| constraints | No | ||
| deadline_at | No | ||
| callback_url | 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?
Annotations already flag readOnlyHint=false, destructiveHint=false and openWorldHint=true; the description adds real value beyond that by stating no funds are committed or execution started, that HumanEndpoint returns commercial terms accept-or-decline, and that callback_url yields signed quote.offered/quote.declined webhooks instead of polling. No auth or rate-limit detail, so not a 5.
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?
Core purpose and the 'no commitment' constraint are front-loaded, and each subsequent sentence adds behavioral or routing value. The long suitable-tasks enumeration and webhook sentence make it wordier than strictly needed, but nothing 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?
For a 9-parameter, open-world, mutation-adjacent tool with no output schema, the description covers the workflow and non-commitment well but leaves most parameter semantics unaddressed. Adequate for calling, thin on the input contract.
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 9 parameters, so the description carries the full burden, but it only illuminates callback_url (webhook behavior) and service_slug (custom-human-task fallback). objective, requester, constraints, deadline_at, deliverables, max_budget_usdc and max_expenses_usdc are left undocumented in both places.
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 ('Submit a request for human-reviewed terms for a real-world task') and scopes it against the alternative path by noting it 'does not commit funds or start execution', implicitly contrasting with human_create_job. Clear enough to route, though it never names a sibling directly.
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 concrete when-to-use guidance via the enumerated suitable tasks (calling a business for price/stock, phone-only info, fact verification, bounded research) and the custom-human-task fallback when no named service matches. It lacks an explicit 'use X instead' comparison to human_create_job, so it stops 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.
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
human_request_quote1 field changedInput schema / properties / callback_urlAdded value: +{
+ "format": "uri",
+ "type": "string"
+}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.
AI agents discover human capabilities, request real-world human execution, and track status.
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.
Add one secure layer between your agents and this server.
