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 has a clearly distinct role in the verification lifecycle: verifi_info describes the service, verify_claim creates a verification request, get_verify checks status without unlocking, and unlock_verify pays to retrieve a result. The descriptions make the boundary between reading state and paying for the answer especially clear.
Three tools follow a verb_noun pattern: get_verify, unlock_verify, and verify_claim. verifi_info is a minor deviation because it uses the service name plus info rather than a verb, but the set remains predictable overall.
Four tools is well-scoped for this service: one informational tool, one creation tool, one status tool, and one unlock/payment tool. No tool feels redundant or missing from the minimal paid-verification workflow.
The surface covers the full core lifecycle: discover terms, submit a claim, poll status, and unlock the result via payment. Minor gaps include no explicit cancel or retry-active-verification operation, and error recovery relies on get_verify and callbacks rather than a dedicated tool.
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, how payment
works (no sign-in: each paid call carries an x402 payment), 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: free, no arguments, no sign-in, per-call x402 payment, exact price schedule with currency amounts and exchange rate, and callback events. An agent knows the cost model, auth model, and side-effect profile before calling.
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 purpose and the three things it returns, then details. The enumerated price tiers are verbose but load-bearing for an agent planning spend, so they earn their place despite 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?
No output schema exists, so the description must describe return contents, and it does: service summary, payment flow, price terms, callback events, agent rules. Nothing needed 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?
Zero parameters, so baseline is 4. The description confirms 'Free and needs no arguments,' which aligns with the empty schema and removes any ambiguity about invocation.
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 ('Describe Verifi') and enumerates exactly what the call returns: service summary, payment mechanics, live price terms, callback events, agent rules. It also distinguishes itself from verify_claim by naming it as the authoritative source for the actual payment requirement.
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' and 'Describe Verifi before using it' give clear when-to-use context, and the pointer to verify_claim as authoritative for payment requirements establishes the relationship to an alternative. No explicit when-not guidance, but the purpose is effectively prerequisite discovery.
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.