Ask a real human (not an LLM) for a judgment, $0.10 USDC via x402. The result returns to the agent.
Scored across 2 tools
The two tools have clearly distinct purposes: ask_human_verdict creates a paid ticket, while get_human_verdict polls an existing ticket. There is no overlap or ambiguity between initiating an action and retrieving its result.
Both tools follow the exact same verb_noun pattern: ask_human_verdict and get_human_verdict, with 'human_verdict' as the consistent object. The naming is perfectly predictable and symmetric.
With only 2 tools, the server sits slightly below the typical 3-15 range, but the scope is extremely narrow—submit a question to a human and poll the result. Each tool is essential and there is no redundancy, so the count is reasonable for the purpose.
The lifecycle is fully covered: ask creates a ticket (with payment handling), and get retrieves the outcome with clear states (pending, completed, expired). There are no obvious missing operations for this micro-domain.
Pagá $0.10 USDC en Base por el juicio subjetivo/cultural de una persona real (no un LLM) sobre una pregunta — especializado en contexto argentino. Sin pago adjunto devuelve los requisitos de pago x402; con el pago, crea el ticket y devuelve {ticket, resultToken, poll}. La respuesta del humano llega de forma asíncrona (minutos u horas) y vuelve a vos, el agente, por get_human_verdict: no llega por Telegram (Telegram es solo cómo la persona recibe la pregunta).
| Name | Required | Description | Default |
|---|---|---|---|
| labels | No | CSV de 2-6 respuestas categóricas posibles, ej. "natural,traducido" | |
| context | No | Contexto extra que ve el humano | |
| question | Yes | La pregunta de juicio subjetivo |
| Name | Required | Description |
|---|---|---|
| poll | Yes | URL equivalente para pollear por HTTP |
| status | Yes | Siempre "pending": la persona todavía no respondió |
| ticket | Yes | Id del ticket, para get_human_verdict |
| expiresAt | Yes | Cuándo vence el ticket si nadie responde (ISO 8601) |
| resultToken | Yes | Secreto para leer el resultado, guardalo |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description adds substantial behavioral context beyond annotations: it discloses the payment requirement, cost, ticket creation, async latency (minutes or hours), and the exact mechanism for retrieving results. It also clarifies that Telegram is only used for delivering the question to the human, not for returning the answer. No contradiction with annotations.
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 three sentences, front-loaded with the most critical information (cost, human judgment, not an LLM), and every sentence earns its place by covering payment behavior, ticket creation, return values, async retrieval, and the Telegram clarification. No fluff or repetition.
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 paid, async, side-effecting tool, the description covers all important operational context: cost, payment flow, ticket creation, return payload, latency, and retrieval path. An output schema exists, so detailed return-value documentation is unnecessary. The description is complete enough for an agent to use it correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already documents all three parameters. The description adds context about the question being subjective/cultural and Argentine-focused, but does not specifically add meaning for labels or context beyond what the schema provides. Baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states a specific action: pay $0.10 USDC to get a real human's subjective/cultural judgment on a question, specialized in Argentine context. It explicitly contrasts with an LLM and mentions the asynchronous retrieval path via get_human_verdict, which distinguishes it from its only sibling.
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 explains both usage states: without payment it returns x402 payment requirements, with payment it creates a ticket. It also tells the agent where the result will arrive (via get_human_verdict) and that it won't arrive via Telegram, effectively routing the agent to the correct retrieval tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Gratis. Pollea el estado de un ticket creado con ask_human_verdict — "pending" mientras la persona todavía no contestó, "completed" con el veredicto, o "expired" si pasaron 7 días sin respuesta.
| Name | Required | Description | Default |
|---|---|---|---|
| ticket | Yes | El ticket devuelto por ask_human_verdict | |
| resultToken | Yes | El resultToken devuelto por ask_human_verdict |
| Name | Required | Description |
|---|---|---|
| panel | No | Solo en "completed": una única persona de confianza, no un promedio anónimo |
| status | Yes | |
| ticket | Yes | |
| verdict | No | Solo en "completed": la etiqueta elegida, si hubo |
| freeText | No | Solo en "completed": el comentario libre, si hubo |
| expiredAt | No | Solo en "expired" |
| expiresAt | No | Solo en "pending" |
| answeredAt | No | Solo en "completed" |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and idempotentHint=true, covering safety and idempotency. The description adds valuable behavioral context beyond those: it is a polling endpoint, defines the three states (pending, completed, expired), specifies a 7-day expiration, and notes it is free. No contradiction exists; the description enriches the annotations rather than repeating them.
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 entire description is a single, well-structured sentence that leads with the cost ('Gratis'), immediately names the action, and compactly lists all possible states with their meanings. Every clause carries essential information; there is no filler or redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple two-parameter polling tool, the description covers the lifecycle states, expiration, and the ticket origin. An output schema exists to document the return structure, and annotations handle safety/idempotency. The only minor gap is the absence of guidance on polling frequency or error handling, but these are not critical given the tool's simplicity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% and both parameters (ticket, resultToken) have descriptive definitions. The description references them indirectly through 'created with ask_human_verdict' but does not add additional semantic detail such as formats, validation rules, or relationship nuances beyond what the schema already provides. Per the calibration rule, with full schema coverage the baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states a specific action: 'Pollea el estado de un ticket creado con ask_human_verdict' (polls the status of a ticket created with ask_human_verdict). It also enumerates the possible statuses (pending, completed, expired), making the tool's purpose unambiguous and distinguishing it from its sibling ask_human_verdict, which creates the ticket.
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 ties the tool explicitly to tickets from ask_human_verdict, which implies when to use it: after creating a ticket with that tool. It doesn't explicitly say 'use this after ask_human_verdict' but the relationship is clear. Since there is only one sibling, no alternative comparison is needed, though adding a note like 'use after ask_human_verdict' would be slightly more explicit.
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.
ask_human_verdict1 field changedOutput schema / (root)Previous value: -nullNew value: +{
+ "$schema": "http://json-schema.org/draft-07/schema#",
+ "additionalProperties": false,
+ "properties": {
+ "expiresAt": {
+ "description": "Cuándo vence el ticket si nadie responde (ISO 8601)",
+ "type": "string"
+ },
+ "poll": {
+ "description": "URL equivalente para pollear por HTTP",
+ "format": "uri",
+ "type": "string"
+ },
+ "resultToken": {
+ "description": "Secreto para leer el resultado, guardalo",
+ "type": "string"
+ },
+ "status": {
+ "const": "pending",
+ "description": "Siempre \"pending\": la persona todavía no respondió",
+ "type": "string"
+ },
+ "ticket": {
+ "description": "Id del ticket, para get_human_verdict",
+ "format": "uuid",
+ "type": "string"
+ }
+ },
+ "required": [
+ "status",
+ "ticket",
+ "resultToken",
+ "poll",
+ "expiresAt"
+ ],
+ "type": "object"
+}get_human_verdict1 field changedOutput schema / (root)Previous value: -nullNew value: +{
+ "$schema": "http://json-schema.org/draft-07/schema#",
+ "additionalProperties": false,
+ "properties": {
+ "answeredAt": {
+ "description": "Solo en \"completed\"",
+ "type": "string"
+ },
+ "expiredAt": {
+ "description": "Solo en \"expired\"",
+ "type": "string"
+ },
+ "expiresAt": {
+ "description": "Solo en \"pending\"",
+ "type": "string"
+ },
+ "freeText": {
+ "description": "Solo en \"completed\": el comentario libre, si hubo",
+ "type": [
+ "string",
+ "null"
+ ]
+ },
+ "panel": {
+ "additionalProperties": false,
+ "description": "Solo en \"completed\": una única persona de confianza, no un promedio anónimo",
+ "properties": {
+ "responses": {
+ "const": 1,
+ "type": "number"
+ },
+ "type": {
+ "const": "single-trusted-human",
+ "type": "string"
+ }
+ },
+ "required": [
+ "type",
+ "responses"
+ ],
+ "type": "object"
+ },
+ "status": {
+ "enum": [
+ "pending",
+ "completed",
+ "expired"
+ ],
+ "type": "string"
+ },
+ "ticket": {
+ "format": "uuid",
+ "type": "string"
+ },
+ "verdict": {
+ "description": "Solo en \"completed\": la etiqueta elegida, si hubo",
+ "type": [
+ "string",
+ "null"
+ ]
+ }
+ },
+ "required": [
+ "status",
+ "ticket"
+ ],
+ "type": "object"
+}ask_human_verdictget_human_verdictGet a real human to verify, decide, or improve an AI agent's work. Pay per review via x402 on Base.
Buy a verified human's approval, verification or judgment at a published price, paid by x402 or card
Adversarial verification for AI agents - pay an independent skeptic per verdict in USDC via x402.
Statistical adjudication for agents: backtest judges, fact-checks. Pay per call in USDC via x402.
Add one secure layer between your agents and this server.
