Get a real human to verify, decide, or improve an AI agent's work. Pay per review via x402 on Base.
Scored across 4 tools
Each tool occupies a distinct step of the verification lifecycle: verifi_info describes the service, verify_claim initiates, get_verify polls state, and unlock_verify pays to reveal the answer. Descriptions make the boundaries between reading state, reading service info, and paying explicit, so an agent can always pick correctly.
Three tools follow a clean verb_noun snake_case pattern (get_verify, unlock_verify, verify_claim), but verifi_info breaks it by using the brand name as a prefix rather than a verb and reverses the order. Minor but visible deviation; still readable and low-risk.
Four tools map exactly onto the service's workflow (info, initiate, poll, pay) with no redundancy and no filler. It is slightly lean—no list/cancel operation—but each tool clearly earns its place for the stated scope.
The full happy path is covered: discover terms, create a claim, poll or receive a callback, and unlock the paid answer. Gaps are minor operational edges (no cancel/abandon tool, no list of active verifies), though the one-active-verify-per-agent rule limits exposure.
Read the current state of a verification. Free, never reveals a locked answer.
verify_id: the id returned by verify_claim.
Returns status "processing" (a human is working: wait retry_after_seconds,
or rely on the callback), "ready" (an answer exists; service_window shows
the window that applied and the exact unlock price, then call
unlock_verify), "failed" (no answer within 24 hours; failure explains the
reason and the free next admission), or "completed" (the answer is
unlocked and included). Use it as a recovery path when no callback is set.
| Name | Required | Description | Default |
|---|---|---|---|
| verify_id | 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, and it delivers: it declares cost ('Free'), a hard safety guarantee ('never reveals a locked answer'), retry semantics (retry_after_seconds), a 24-hour failure window, and the unlocked/completed state. It omits auth requirements and rate limits, keeping it short of 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?
Front-loads the core purpose and the free/safe guarantees, then enumerates the four states compactly. The state list is long but each entry earns its place by specifying what follows in that state; minor verbosity only.
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?
There is no output schema, so the description must describe returns, and it does so thoroughly for all four statuses including retry and pricing hints. Combined with its single required parameter being defined, it is largely complete, though auth/permission context is absent.
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% and the schema only types verify_id as a string, so the description must compensate. It does by defining the id's provenance ('the id returned by verify_claim'), which is exactly the semantics an agent needs to supply a valid value.
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 ('Read the current state of a verification') and immediately differentiates scope ('Free, never reveals a locked answer') from sibling tools like unlock_verify. An agent can tell this read-only status check apart from verify_claim, unlock_verify, and verifi_info without opening a 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?
Explicitly names the triggering condition ('Use it as a recovery path when no callback is set') and routes the agent onward per state, e.g. call unlock_verify when status is 'ready'. This is genuine when-to-use guidance tied to alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Unlock a ready chain and return the human result.
The price was decided when the human answered: the SLA amount inside the
SLA window, the grace amount after it, always in the asset the admission
was paid in. get_verify shows it as service_window.unlock_amount before
you pay. Omit payment_signature first: standard x402-aware
MCP clients handle the payment request and retry through MCP metadata
automatically. Generic clients can pass the resulting x402 signature
manually. Never pass a private key.
| Name | Required | Description | Default |
|---|---|---|---|
| verify_id | Yes | ||
| payment_signature | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden and largely succeeds: it discloses how price is determined (SLA amount in-window, grace amount after, in the admission asset), that payment happens through x402 metadata retry, and includes a security constraint ('Never pass a private key'). It omits idempotency and failure/retry semantics after a successful unlock, which keeps it below 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?
Front-loads the purpose in the first sentence before the payment mechanics, and every subsequent sentence adds operational value. Slightly dense and fragmented by line breaks, but no wasted sentences.
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?
No output schema exists, and the description covers the return only loosely ('the human result'), which is its weakest point. For a payment-gated mutation, though, the critical decision inputs — cost model, payment flow, safety warning — are all present.
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 compensate, and it does so for payment_signature: omit first, it represents the x402 signature, and never substitute a private key. verify_id is only implicitly documented via 'a ready chain', leaving one parameter's meaning inferred.
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 ('unlock') and resource ('a ready chain'), and clarifies the return ('the human result'), which is unusual in this domain. It does not, however, explicitly distinguish itself from the sibling verify_claim; the boundary is only implied through the get_verify/pay workflow.
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 procedural guidance: omit payment_signature first so x402-aware clients auto-retry, or pass the signature manually for generic clients. It references get_verify as the preview step ('shows it as service_window.unlock_amount before you pay'), establishing workflow order. It stops short of explicitly naming when-not-to-use it versus verify_claim.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Describe Verifi before using it: what it does, how to pay, and the current price terms.
Free and needs no arguments. Returns the service summary, authentication
(none, only a wallet address), the live price terms (0.10 EUR admission,
then 2.90 EUR if a human answers within 60 minutes or 1.45 EUR within 24
hours, with the asset amounts and exchange rate used), the callback
events, and the rules for agents. Call it once to plan; the payment
requirement returned by verify_claim is authoritative.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden and does so well: it discloses the tool is free, requires no arguments, needs no authentication beyond a wallet address, and lays out concrete pricing tiers (0.10 EUR admission plus conditional 2.90/1.45 EUR) and callback events. This is unusually rich behavioral context for a zero-parameter 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?
Purpose is front-loaded in the first clause and the rest is organized into what it returns vs. how to use it. The parenthetical price detail is dense but genuinely informative rather than filler, so it remains tight overall.
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 or annotations, the description must describe the return surface itself, and it enumerates the service summary, authentication mode, live price terms with asset amounts and exchange rate, callback events, and agent rules. Nothing an agent needs to call this 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?
There are zero parameters, so the baseline is 4. The description reinforces this by stating it "needs no arguments," leaving no ambiguity about invocation syntax.
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: it describes the Verifi service, how to pay, and current price terms. It's clearly an informational/discovery tool, and it gestures at the sibling relationship by naming verify_claim as the authoritative source for payment requirements, though it doesn't fully delineate itself from get_verify or unlock_verify.
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?
"Call it once to plan" gives clear timing guidance, and it explicitly redirects to verify_claim for the authoritative payment requirement, which names an alternative and the condition selecting it. It lacks explicit when-not-to-use exclusions, keeping it 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.
Ask a real human to verify, decide on, or improve something before your agent acts.
Use it when a wrong answer is costly: a customer message, a fact the model
is unsure of, an approval, or a matter of taste. A person reads the intent
and the claim and answers accept, reject, or a refined answer with an
explanation. This call is gate 1: it costs 0.10 EUR (paid on Base
via x402) and returns a payment requirement first if unpaid; reading that
requirement is free and shows every later price.
intent: what your agent is trying to do (max 2000 chars).
claim: the claim a human should verify (max 4000 chars).
agent_id: your wallet address (0x + 40 hex). Signs the x402 payments.
callback_url: optional HTTPS endpoint for verify.ready or verify.failed.
Use it to avoid an active polling loop; retain verify_id for recovery.
payment_signature: optional manual compatibility input. Standard x402-aware
MCP clients send the signed payment through request metadata automatically.
Returns status "processing" with a verify_id. Prefer callback_url, or poll
get_verify at the returned interval until status is "ready" or "failed".
If ready, call unlock_verify. Only one active verify per agent_id at a time.
| Name | Required | Description | Default |
|---|---|---|---|
| claim | Yes | ||
| intent | Yes | ||
| agent_id | Yes | ||
| callback_url | No | ||
| payment_signature | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden and does so: cost (0.10 EUR on Base via x402), the two-phase payment flow (payment requirement returned first if unpaid, reading it free, showing future prices), the processing lifecycle, and a concurrency limit ('only one active verify per agent_id at a time'). It also discloses callback event names (verify.ready / verify.failed).
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-loaded with the core action and the cost/costly-error trigger, then parameter-by-parameter detail; nearly every sentence earns its place given the payment and lifecycle complexity. It is somewhat sprawling for a five-parameter tool, but the density of useful content justifies most of the length.
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 no annotations, the description compensates by describing the return value ('status "processing" with a verify_id'), the terminal states (ready/failed), and the required follow-up call (unlock_verify). An agent has everything needed to invoke it, pay, and complete the flow.
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 compensate for all five parameters and it does: intent (max 2000 chars), claim (max 4000 chars), agent_id (0x + 40 hex wallet that signs x402 payments), callback_url (optional HTTPS endpoint, with its effect of avoiding polling and need to retain verify_id), and payment_signature (optional manual compat input, auto-sent by x402-aware clients). That is meaning well beyond the bare typeless schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb+resource combo ('Ask a real human to verify, decide on, or improve something') with the explicit goal of gating agent action before it proceeds. It also names its siblings in context (poll get_verify, then call unlock_verify), so an agent can place it in the workflow without opening another 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?
Explicit when-to-use criteria are given ('when a wrong answer is costly: a customer message, a fact the model is unsure of, an approval, or a matter of taste'). It also routes between alternatives: prefer callback_url over active polling, otherwise poll get_verify at the returned interval, then call unlock_verify. Exclusions and sequencing are both covered.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
get_verifyunlock_verifyverifi_infoverify_claimExpert review for AI agents. On-chain proof of human review.
Ask a real human (not an LLM) for a judgment, $0.10 USDC via x402. The result returns to the agent.
Hire Vevang's AI agents, pay-per-call in USDC on Base via x402: video, visibility, verify, extract
Human-as-a-Service for AI agents. Delegate tasks that need a real human, get results via API.
Add one secure layer between your agents and this server.
