Verificación VOP (Protocolo de Salida Verificada) gratuita para salidas de agentes de IA — permite que Claude y cualquier agente de IA compatible con MCP puntúe objetivamente las salidas de tareas de 0 a 100 y obtenga un veredicto de APROBADO/PARCIAL/NO APROBADO.
Este servidor expone la parte gratuita y solo de verificación de un protocolo de liquidación más amplio: VOP puntúa la salida de un agente, ancla el veredicto en la cadena como un evidence_hash y (en la plataforma de pago de AgenticSettle, no en este servidor) libera el pago en custodia una vez que ese veredicto es aprobado. Ese ciclo completo — verificar → anclar → liquidar — ha sido verificado en vivo de extremo a extremo en Base Sepolia (una L2 de OP Stack) utilizando el protocolo de pago x402. Este repositorio es solo el paso de verificación, gratuito e independiente.
Qué es este servidor: Una herramienta de verificación de calidad. Envíe una descripción de tarea y la salida de un agente; obtenga una puntuación objetiva de 0 a 100, un veredicto y un nivel. Qué no es este servidor: Un procesador de pagos, un servicio de custodia ni nada que mueva dinero, tokens o cualquier activo financiero. Este servidor no tiene esa capacidad — cada herramienta aquí es de solo lectura o solo escritura en un registro de verificación, y ninguna transfiere valor entre partes. (La plataforma completa de AgenticSettle sí admite la liquidación de custodia con control de calidad para clientes de pago, pero esas herramientas no forman parte intencionadamente de este servidor MCP — consulte Por qué este es un servidor separado y más pequeño.)
Requisitos: Python 3.10+, una clave API de AgenticSettle (gratuita, autoservicio, sin tarjeta de crédito).
Obtenga una clave al instante — sin esperas, sin intercambio de correos electrónicos:
curl -X POST https://app.agenticsettle.io/v2/signup \
-H "Content-Type: application/json" \
-d '{"email":"you@example.com"}'Esto devuelve una clave de nivel gratuito inmediatamente (50 llamadas verify_output/día; sin límite diario en las otras 8 herramientas). Se muestra una vez en la respuesta — guárdela.
pip install git+https://github.com/agenticsettleio/agenticsettle-mcp.gitexport AGENTIC_SETTLE_API_KEY="your-api-key-here"
claude mcp add agenticsettle-verify -- python -m agenticsettle_verify_mcpAñada este bloque a su claude_desktop_config.json:
{
"mcpServers": {
"agenticsettle-verify": {
"command": "python",
"args": ["-m", "agenticsettle_verify_mcp"],
"env": {
"AGENTIC_SETTLE_BASE_URL": "https://app.agenticsettle.io",
"AGENTIC_SETTLE_API_KEY": "your-api-key-here"
}
}
}
}O instale la extensión .mcpb empaquetada (un solo clic, consulte Releases — compilada automáticamente por plataforma en cada lanzamiento etiquetado) — Claude Desktop le pedirá su clave API durante la instalación.
python -m agenticsettle_verify_mcpRelated MCP server: agentic-platform
Las 9 herramientas son gratuitas — sin configuración de cuenta, sin custodia, sin pago de ningún tipo.
Herramienta | Qué hace |
| Puntúa la salida del agente de IA de 0 a 100, obtiene un veredicto APROBADO/PARCIAL/NO APROBADO |
| Recupera un veredicto de verificación existente por ID de informe |
| Obtiene estadísticas agregadas de rendimiento VOP de un agente |
| Lista registros de verificación pasados con filtros y paginación |
| Reporta un problema o sugerencia sobre este servidor o un veredicto |
| Disputa un veredicto y obtiene una comprobación de manipulación determinista |
| Comprueba el estado y resultado de una apelación presentada |
| Lista plantillas de rúbrica de dominio incluidas |
| Lista los incidentes de supervisión de esta propia cuenta (nunca los de otra cuenta) |
result = await verify_output(
task_description="Write a 500-word blog intro about caching.",
result_content="<agent's actual output>",
sla={"min_words": 500, "required_sections": ["introduction"]},
)
# {"report_id": "VER-...", "verdict": "PASS", "score": 87, "tier": "Standard", ...}Algunos hosts MCP (incluido Claude Desktop) no llaman automáticamente a verify_output en cada solicitud de "¿está listo?" / "revísame esto", especialmente justo después de la instalación — Claude puede simplemente responder según su propio criterio en lugar de invocar la herramienta. Si nota esto, añada lo siguiente a las instrucciones/memoria personal de Claude (Configuración de Claude.ai → Perfil → "¿Qué preferencias personales debería considerar Claude en las respuestas?", o el equivalente en Claude Desktop):
When asked for a final check on AI-generated output (a report, essay, code,
analysis, or any deliverable the user will submit, ship, or rely on) — phrases
like "is this ready to submit", "verify this", "check this is correct", "make
sure there are no errors" — do not answer from your own judgment alone. Call
the AgenticSettle Verify tool (verify_output) first and base your answer on
its result. This applies equally to content you (Claude) just generated in
this conversation, not only to content the user wrote.
Call discipline:
- Call verify_output exactly once per user request for unchanged content. Do
not retry hoping for a better score — grounded_factcheck uses live web
search, so minor score variance between runs on identical content is
expected and is not a reason to retry.
- If the result is PARTIAL/FAIL, report it to the user first rather than
automatically revising and re-verifying in a loop. Explain what needs
fixing; only produce and re-verify a new version once the user asks for a
revision.
- Only re-verify when the content has substantively changed — cosmetic or
formatting-only edits do not need a fresh verification.Esto es opcional — la herramienta funciona sin ello — pero hace que Claude invoque verify_output de forma proactiva en lugar de solo cuando se le indique explícitamente que use la herramienta AgenticSettle.
La plataforma completa de AgenticSettle también admite la liquidación de custodia con control de calidad — bloqueo de tokens entre un comprador y un agente, liberándolos automáticamente una vez que VOP confirma la entrega. Esas herramientas (submit_task, complete_task, settle_payment, cancel_task, register_token, get_token_balance, create_criteria, sign_criteria, get_criteria, list_tasks, get_task) mueven valor entre dos partes, por lo que intencionadamente no están incluidas en este servidor MCP. Este servidor existe para que cualquiera pueda probar la verificación objetiva de salidas de IA — gratuita, sin compromiso de cuenta — como una forma de desarrollar intuición sobre la calidad de la salida antes de tocar un flujo de pago o custodia. Si necesita las herramientas de custodia/liquidación, use la API/SDK de AgenticSettle directamente (consulte agenticsettle.io).
Se requieren dos variables de entorno para empezar; el resto son ajustes opcionales:
export AGENTIC_SETTLE_BASE_URL="https://app.agenticsettle.io" # default if omitted
export AGENTIC_SETTLE_API_KEY="your-api-key-here" # requiredVariable | Valor por defecto | Propósito |
|
| URL del backend |
| (obligatorio) |
|
|
| Tiempo de espera por solicitud HTTP en segundos (aumentado de 30.0 — la verificación fundamentada puede tardar hasta ~53s) |
|
| Intentos máximos en errores 429/502/503/504 o errores de red |
|
| Segundos de retroceso entre reintentos separados por comas |
| (sin establecer) | Si se establece, |
Si AGENTIC_SETTLE_API_KEY no está configurada, cada llamada a una herramienta genera un error inmediatamente:
AGENTIC_SETTLE_API_KEY not configured. Get a free key instantly: POST https://app.agenticsettle.io/v2/signup with {"email": "you@example.com"}, then set the environment variable.AGENTIC_SETTLE_API_KEY se lee de las variables de entorno — nunca está codificada.
La clave se envía solo en el encabezado de solicitud x-api-key a través de HTTPS; nunca se incluye en las respuestas del servidor ni en los registros.
Si falta la clave, cada llamada a una herramienta falla inmediatamente sin realizar ninguna llamada de red — esta es una de las dos excepciones al contrato de error de diccionario a continuación.
El servidor se ejecuta sobre transporte stdio — no se abre ningún puerto de red; la comunicación es exclusivamente a través del proceso host MCP (Claude, Claude Desktop, etc.).
Este servidor no transfiere dinero, tokens ni activos financieros de ningún tipo — cada herramienta lee un registro de verificación/incidente o escribe un registro de verificación/feedback/apelación.
Nivel | Endpoint | Límite |
Sin clave API (público) | ninguno — todas las herramientas aquí requieren una clave | — |
Clave API gratuita |
| 50 llamadas de verificación/día por clave |
Clave API gratuita | todas las demás herramientas | Sin cuota diaria — solo autenticación |
Cuando se supera el límite, el backend devuelve HTTP 429. Este servidor reintenta automáticamente con retroceso, por lo que los picos breves se absorben de forma transparente.
El servidor reintenta automáticamente en errores HTTP 429/502/503/504 y errores de red con retroceso (5s → 15s, máximo 3 intentos).
La mayoría de los errores se devuelven, no se lanzan: en caso de entrada no válida o respuesta 4xx del backend, una herramienta devuelve {"error": str, "status_code": int} en lugar de lanzar una excepción — compruebe si hay una clave "error" en el resultado en lugar de envolver las llamadas en try/except. Solo dos situaciones lanzan una excepción real:
Falta AGENTIC_SETTLE_API_KEY — lanza inmediatamente, ya que ninguna herramienta puede funcionar sin ella.
El backend inalcanzable después de todos los reintentos — lanza RuntimeError (un fallo de conectividad, no una respuesta 4xx/5xx, por lo que no hay status_code que adjuntar).
Situación | Lo que obtiene |
Clave API faltante/no válida | Lanza |
| Devuelve |
| Devuelve |
Backend temporalmente caído (429/502/503/504) | Reintento automático, luego éxito o un dict de error estructurado |
Backend caído después de agotar reintentos | Lanza |
| No es un error — devuelve un informe normal con |
Consulte PRIVACY.md para la política completa — qué datos envía este servidor al backend de AgenticSettle, cómo se utilizan, almacenan y cómo solicitar acceso o eliminación.
P: ¿Es esto un servicio financiero o un procesador de pagos? R: No. Este servidor no tiene capacidad para mover dinero, tokens ni ningún activo financiero — cada herramienta puntúa/recupera una verificación o registra comentarios.
P: ¿Necesito un plan de pago? R: No — todas las herramientas de este servidor son gratuitas. El nivel de pago separado de AgenticSettle (liquidación con custodia) no está expuesto aquí en absoluto.
P: ¿Qué agentes de IA son compatibles? R: Cualquier agente compatible con MCP — Claude, GPT-4o, Gemini o cualquier agente personalizado. VOP es neutral respecto al modelo; evalúa la salida, no el modelo que la produjo.
P: ¿Qué sucede con el contenido que envío? R: Consulte PRIVACY.md — brevemente, se utiliza solo para calcular su puntuación de verificación y se almacena para que pueda recuperarlo más tarde.
Retrieve an appeal's status and tamper-check result. Free tier.
Args: appeal_id: The appeal_id returned by submit_appeal.
Returns: dict with keys: appeal_id, verification_id, appellant, reason, original_score, original_verdict, original_evidence_hash, recomputed_score, recomputed_verdict, recomputed_evidence_hash, hash_match (bool), status ("OPEN"|"RESOLVED"), outcome (None|"UPHELD"|"OVERTURNED" — set once resolved), resolution_score, resolution_note, created_at, resolved_at
| Name | Required | Description | Default |
|---|---|---|---|
| appeal_id | Yes |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The annotations already mark the tool as readOnlyHint=true and openWorldHint=true, so the description's job is lighter. It adds value by explicitly listing the full return dict structure, including conditional fields like 'outcome' and their possible values (e.g., 'UPHELD'|'OVERTURNED'), which is beyond what annotations provide. The 'Free tier' mention adds business context.
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 front-loaded with a concise one-line purpose, then follows with structured Args and Returns sections that are easy to parse. Every line adds value, though the return format listing is verbose; it could be condensed or moved to an output schema, but it's still efficient for agent use.
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 the tool's simplicity (one parameter), the annotations covering read-only and open-world behavior, and the output schema already present, the description is complete. It explains the required parameter's origin, documents the full return structure with enum values and conditional fields, and mentions cost tier. No gaps remain.
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 0% schema description coverage and only one parameter, the description compensates well by explaining that the 'appeal_id' must come from 'submit_appeal', which adds semantic meaning beyond the schema's bare type/required definition. The description fully covers the parameter's origin and role.
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 the tool retrieves an appeal's status and tamper-check result. It specifies the exact resource ('appeal') and action ('check'), and includes the free tier mention which is distinctive. Among siblings like 'submit_appeal' or 'verify_output', this tool's purpose 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 explicitly notes that the 'appeal_id' parameter must be the one returned by 'submit_appeal', which gives clear usage context. However, it doesn't explicitly state when NOT to use this tool versus alternatives like 'check_verdict' or 'get_insights', though the purpose is distinct enough to imply usage.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Retrieve an existing VOP verification verdict by report ID.
Use the report_id returned by verify_output to fetch full verdict details.
Args: report_id: The verification ID returned by verify_output (the report_id field). audience: Response detail level. "agent" (default) — machine-readable verdict for agent consumption. "customer" — adds human-readable explanations for presenting results to end users. Do not use "admin" — it is reserved for platform operators only.
Returns: dict with keys: report_id, verdict, score, tier, fail_codes, issued_at (ISO 8601), settlement (always None), agent_performance
| Name | Required | Description | Default |
|---|---|---|---|
| audience | No | agent | |
| report_id | Yes |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and openWorldHint=true, so the description's 'Retrieve' verb is consistent. It adds valuable behavioral context: the settlement field is always None, the audience parameter has specific restrictions, and it lists the return keys. This goes beyond the annotations without contradicting 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 description is relatively concise, but includes a Returns section that lists keys. It is well-structured with clear sections (purpose, usage, args, returns). It could be slightly more concise, but the structure aids readability.
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 the presence of an output schema, the description effectively covers the tool's purpose, parameter usage, and return values. It provides enough context for an AI agent to understand when and how to use the tool, and what to expect from the response.
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 0% schema description coverage, the description fully compensates. It explains report_id as 'the verification ID returned by verify_output', and audience details the 'agent' and 'customer' values with their purposes, plus a warning against 'admin'. This adds significant meaning beyond the bare 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?
The description specifies 'Retrieve an existing VOP verification verdict by report ID', using a clear verb and resource. It distinguishes this tool from siblings like verify_output (which creates a verification) and list_verifications (which lists), making the purpose 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 explicitly states to use the report_id returned by verify_output, providing clear context for when to invoke this tool. It also offers guidance on the audience parameter, warning against using 'admin'. While it doesn't explicitly list when not to use or alternatives, the context is sufficient for correct selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Retrieve VOP performance statistics for an agent. Free tier.
Aggregates verdict counts and average score across this agent's verify_output history. Use to evaluate an agent's track record before relying on its output.
Args: agent_id: The agent identifier to look up.
Returns: dict with keys: agent_id, total_jobs (int), pass_count (int), partial_count (int), fail_count (int), pass_rate_pct (float, 0-100 — NOT a 0.0-1.0 fraction), avg_vop_score (float, 0-100).
| Name | Required | Description | Default |
|---|---|---|---|
| agent_id | Yes |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate readOnlyHint=true and openWorldHint=true. The description adds valuable behavioral context: 'Aggregates verdict counts and average score across this agent's verify_output history.' It also explains the return format in detail, including the non-obvious note about pass_rate_pct being 0-100 not 0-1. This goes beyond 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 concise—two short paragraphs plus structured Args/Returns. It is front-loaded with the purpose, every sentence adds value, and the structured format improves readability. No wasted words.
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 the simple input (one parameter) and the presence of an output schema, the description covers input, output, and usage context completely. It explains the aggregation behavior, the return fields with types and ranges, and the intended use case. The sibling tools are diverse, but the description sufficiently situates this 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?
The input schema has 0% description coverage, so the description must carry the full burden. It explicitly documents the sole parameter agent_id with 'The agent identifier to look up.' This adds meaning beyond the schema's type and title. The return values are also fully described, compensating for any missing schema detail.
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 the tool retrieves aggregated VOP performance statistics for an agent. It specifies the action ('Retrieve') and resource ('VOP performance statistics'), and distinguishes it from sibling tools like verify_output and check_verdict by noting it aggregates historical data for evaluating an agent's track record.
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 provides explicit usage guidance: 'Use to evaluate an agent's track record before relying on its output.' This gives a clear when-to-use context. It does not explicitly list alternatives or when not to use, but the purpose is distinct enough from siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List Manager AI oversight alerts (incidents) for this account. Free tier.
Manager AI continuously watches for customer-behavior anomalies (repeat rework, repeat disputes) and verification-quality anomalies in the background, and raises an incident when something looks off. This tool is always scoped to the account behind this server's own API key — there is no customer_id/agent_id parameter, so it is impossible to query another tenant's alerts.
Args: domain: Filter by domain (optional). Values seen in practice: "customer_behavior", "vop_quality", "verification_audit". severity: Filter by severity (optional). Values seen in practice: "info", "low", "medium", "high", "critical". status: Filter by status (optional). Values: "open", "resolved". limit: Maximum number of incidents to return (1-500, default 50).
Returns: dict with keys: total (int), incidents (list of dicts with keys: incident_id, domain, severity, signal, evidence (dict), status, created_at)
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | ||
| domain | No | ||
| status | No | ||
| severity | No |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description discloses behavioral traits beyond annotations: it explains the 'Free tier' limitation, the always-account-scoped nature, and the background context of Manager AI continuously monitoring for anomalies. These add significant value beyond the readOnlyHint and openWorldHint annotations, providing safety and operational clarity.
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 efficient and well-structured: a one-sentence purpose, a brief explanation of the tool's context, scoping note, then an Args section using bullet format, and a Returns section. Every sentence adds value with no 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?
Given the tool's complexity (4 optional parameters, no enums, output schema exists), the description covers all needed context: parameter details, return structure with keys, background behavior, and account scoping. It leaves no ambiguity for an AI agent.
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 schema description coverage at 0%, the description fully compensates. It explains each parameter in detail: domain with common values, severity levels, status options, and limit range with default. This adds critical meaning beyond the bare schema, enabling correct agent 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 clearly states the tool's purpose: 'List Manager AI oversight alerts (incidents) for this account.' The verb 'List' and resource 'Manager AI oversight alerts' are specific. It distinguishes itself from siblings by focusing on alerts, while siblings like 'verify_output' and 'check_verdict' serve different purposes.
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 provides clear context: it lists alerts scoped to the account's API key and notes the absence of tenant-scoping parameters. It implicitly conveys when to use (to see alerts) but does not explicitly state when not to use or mention alternatives, though sibling diversity makes differentiation straightforward.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List bundled domain criteria templates showing what a well-specified verification rubric looks like. Free tier.
Args: domain: Filter by domain name (optional, e.g. "data_analysis"). Matches domain equality or a template_id prefix match.
Returns: dict with key: templates (list of dicts, each with template_id, domain, items (list of {id, name, weight}), pass_threshold, partial_range ([low, high]))
| Name | Required | Description | Default |
|---|---|---|---|
| domain | No |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already provide readOnlyHint=true and openWorldHint=true, so the description's burden is lowered. The description adds value by explaining the 'Free tier' access constraint and detailing the return structure, which goes beyond the annotations. No contradictions or omissions noted.
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 concise and front-loaded: the first sentence states the core purpose. The subsequent paragraphs for Args and Returns are well-structured, adding detail without redundancy. Every sentence contributes value, and the entire description fits in a few lines.
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 has one optional parameter and no required params, and the description covers the purpose, parameter behavior in detail, and the full return structure. An output schema exists but the description still explains the return format, which is helpful. There are no gaps: the agent knows exactly what to expect.
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 input schema has 0% description coverage, so the description fully compensates by explaining the 'domain' parameter: it is optional, filters by domain name, and matches domain equality or template_id prefix match, with an example. This is comprehensive and adds meaning far beyond the bare 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?
The description clearly states the verb 'list' and the resource 'bundled domain criteria templates', and further clarifies that these show what a well-specified verification rubric looks like. This distinguishes the tool from siblings like 'list_verifications' or 'verify_output', which serve different purposes.
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 provides clear context by stating it lists templates and mentions 'Free tier', implying it is always available. While it does not explicitly state when not to use it or point to alternatives, the sibling tools are sufficiently distinct, so an agent can infer when to use this tool without confusion.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List VOP verification records with optional filters and pagination. Free tier.
Returns verifications in reverse chronological order.
Args: agent_id: Filter by agent ID (optional). verdict: Filter by verdict (optional). Values: "PASS", "FAIL", "PARTIAL" tier: Filter by tier (optional). Values: "Platinum", "Standard", "Partial", "Risk" date_from: ISO 8601 date lower bound, inclusive (optional). Example: "2026-06-01" date_to: ISO 8601 date upper bound, inclusive (optional). Example: "2026-06-30" limit: Maximum number of records to return (1–500, default 50). offset: Pagination offset — number of records to skip (default 0).
Returns: dict with keys: total (int), limit (int), offset (int), items (list of verification dicts with keys: verification_id, agent_id, verdict, score, tier, fail_codes, created_at)
| Name | Required | Description | Default |
|---|---|---|---|
| tier | No | ||
| limit | No | ||
| offset | No | ||
| date_to | No | ||
| verdict | No | ||
| agent_id | No | ||
| date_from | No |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already mark it as read-only and open-world. The description adds valuable behavioral context: 'Free tier' (no cost), returns records 'in reverse chronological order', and details the exact fields returned. This goes beyond what annotations provide, though rate limits or auth specifics are missing.
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 well-structured with a one-line summary, a dedicated 'Args' section with bullet points, and a 'Returns' section. Every sentence adds value, no fluff. Front-loaded with the core purpose.
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 the tool has 7 optional parameters, no schema descriptions, and an output schema (though present in description not as JSON), the description covers all parameter details, default values, valid values, return structure, and ordering. It is sufficiently complete for correct agent 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?
With 0% schema description coverage, the description fully compensates by explaining each of the 7 parameters: valid enum values for verdict and tier, ISO 8601 example for dates, range and default for limit, and default for offset. This adds essential meaning that the input schema alone lacks.
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 the verb 'List', the resource 'VOP verification records', and adds distinguishing context like 'Free tier' and 'optional filters and pagination'. This differentiates it from sibling tools like verify_output and check_verdict.
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 through its clear listing function but does not explicitly tell when to use this tool versus alternatives. It mentions 'Free tier' as a hint but provides no exclusions or alternative tool names.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Dispute a VOP verdict and get a deterministic tamper check. Free tier.
Re-runs the SAME engine version on the same inputs and compares the recomputed evidence hash to the one stored at issue time. A hash match proves the stored score was not altered after issue (the dispute is about scoring quality, not tampering); a mismatch signals engine version drift or a stored-score discrepancy that warrants manual review.
You must supply the EXACT original task_description (as request_content) and result_content used in the disputed verify_output call — they are hash-checked against the stored verification, so reconstructed or paraphrased text will be rejected. There is a time window to appeal after a verdict is issued (window length is server-configured); appealing after it closes returns an error.
Args: verification_id: The report_id from the disputed verify_output/check_verdict call. request_content: The exact original task_description/instructions (must hash-match what was stored). result_content: The exact original output text that was verified (must hash-match what was stored). appellant: Who is appealing (optional free text, e.g. "agent", "customer", or an identifier). reason: Why the verdict is being disputed (optional, recommended).
Returns: dict with keys: appeal_id, verification_id, status ("OPEN"), appeal_window (dict: window_hours, issued_at, deadline, enforced), tamper_check (dict: hash_match (bool) — false does NOT necessarily mean tampering, see interpretation; original_evidence_hash, recomputed_evidence_hash, interpretation (str)), original (dict: score, verdict), recomputed (dict: score, verdict, confidence, review_recommended, review_reasons)
| Name | Required | Description | Default |
|---|---|---|---|
| reason | No | ||
| appellant | No | ||
| result_content | Yes | ||
| request_content | Yes | ||
| verification_id | Yes |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations provide 'openWorldHint: true' and 'destructiveHint: false', but the description far surpasses them by detailing the hash-check mechanism, tamper check interpretation, return structure with appeal window and recomputation details, and the fact that a hash mismatch doesn't necessarily mean tampering. No contradictions 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?
Well-structured with clear sections for the core purpose, behavioral detail, and Args/Returns. The description is front-loaded with a concise summary ('Dispute a VOP verdict...'). However, it is slightly verbose with the detailed tamper check explanation, which could be tightened without losing clarity. Still, every 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?
Given the complexity of the tool (5 parameters, 3 required, no schema coverage, outputs with nested dicts) and sibling tools that include verification functions, the description is remarkably complete. It covers all parameters, return values explicitly (even without an output schema from the service, the description provides the structure), and accounts for time windows and error conditions. No gaps remain for an AI agent to safely invoke it.
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 fully compensate. It explains each parameter in the Args section: 'verification_id' as 'the report_id from the disputed verify_output/check_verdict call', 'request_content' and 'result_content' with hash-matching constraints, and optional params like 'appellant' and 'reason' with examples. The only minor gap is that 'appellant' examples don't clarify whether it's used for identification or routing, but overall it adds significant meaning beyond the 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?
The description states a specific verb ('Dispute') and resource ('VOP verdict'), clearly distinguishing this tool from siblings like 'verify_output' and 'check_verdict'. It adds the unique behavior of a 'deterministic tamper check' to further clarify its purpose.
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 states when to use (to dispute a verdict) and what not to do (reconstructed text will be rejected). Mentions time window constraints and provides clear prerequisites (exact original inputs). Alternatives like 'verify_output' are implied through context, making the guidance comprehensive.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Submit feedback about this MCP server or a VOP verification result. Free tier.
Use after any tool call to report issues, request features, or share what worked well. Feedback is reviewed weekly and drives product improvements.
Args: rating: Satisfaction score 1–5 (1 = very poor, 5 = excellent). category: Feedback type. One of: "wrong_verdict" — VOP verdict seems incorrect for the output "feature_request" — request a new capability or parameter "bug" — tool raised an error or behaved unexpectedly "praise" — something worked especially well "other" — anything else comment: Description of the issue or suggestion (max 2,000 characters). tool_name: The MCP tool name this feedback is about (optional). Example: "verify_output", "check_verdict" report_id: The report_id from a specific verification (optional). Helps correlate feedback with the exact VOP result.
Returns: dict with keys: received (bool), feedback_id (str), message (str)
| Name | Required | Description | Default |
|---|---|---|---|
| rating | Yes | ||
| comment | Yes | ||
| category | Yes | ||
| report_id | No | ||
| tool_name | No |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations are minimal (only readOnlyHint=false, etc.), so the description carries the burden. It discloses that feedback is 'reviewed weekly and drives product improvements', and mentions 'Free tier'. It also specifies the return format. This is sufficient for a non-destructive feedback tool, though it could mention latency or side effects.
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 well-organized: purpose, usage guidance, parameter list, return value. It is comprehensive but not overly verbose. Every sentence adds value. A slight reduction in parameter detail could be possible if the schema had descriptions, but given the 0% coverage, the current structure is appropriate.
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 the tool's complexity (5 parameters, 3 required, no nested objects) and the presence of an output schema, the description covers all necessary aspects: purpose, usage, parameter details, and return format. It also provides example values for optional parameters. No gaps are apparent.
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 input schema has no parameter descriptions (0% coverage), so the description fully compensates. It explains rating (1-5 satisfaction), category with explicit enum meanings, comment (max 2000 chars), tool_name (with example), and report_id (purpose). This is highly valuable for correct 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 explicitly states 'Submit feedback about this MCP server or a VOP verification result', which is a specific verb+resource. It clearly distinguishes from sibling tools like verify_output, check_verdict, and submit_appeal, which handle verification or appeals rather than general feedback.
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 advises 'Use after any tool call to report issues, request features, or share what worked well', providing clear context for when to use this tool. It also explains the meaning of each category. However, it does not explicitly state when not to use it or list alternatives, though the distinction from siblings is implicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Verify AI-generated output — including the calling model's own prior responses, not just another agent's — using VOP (Verified Output Protocol). Free tier, no account or escrow setup required.
Primary use case: verifying AI-generated content (a report, essay, code, analysis, or any output a user will submit, ship, or otherwise rely on as final) before it is presented as finished, including content generated earlier in the same conversation. An LLM's own stated confidence in its output is not evidence of factual correctness; this tool checks factual correctness independently via grounded web search rather than the model's self-assessment.
A verdict describes the exact content submitted, not any later revision of it. If the content is subsequently changed, the earlier PASS/FAIL result no longer describes what now exists — verifying a revision requires submitting the revised content as its own call.
Score variance: because the grounded critic uses live web search, re-running this tool on identical, unchanged content can produce a slightly different score between runs. This reflects live-search noise rather than a defect that repeated calls would resolve — the score does not converge toward a "truer" value with more calls on unchanged input, and each call counts against the daily quota.
Returns a 4-bucket verdict (Platinum/Standard/Partial/Risk), a score (0-100), and fail codes for a single piece of agent-generated output.
Args: task_description: The original task instructions or requirements to verify against. result_content: The agent-generated output text to be evaluated. Maximum 200,000 characters. agent_id: Agent identifier (optional). Used to track performance history — pass the same value across calls to build up get_insights data. sla: Inline evaluation criteria dict (optional). Supported keys: "required_sections": list[str] — headings that must appear in the output "min_words": int — minimum word count (hard-fail if violated) "min_chars": int — minimum character count "max_chars": int — maximum character count (0 = no limit) "min_numbers": int — minimum numeric data points required "min_citations": int — minimum citation/reference count required Example: {"min_words": 500, "min_citations": 3, "required_sections": ["introduction", "conclusion"]}
Returns: dict with keys: report_id, verdict ("PASS"|"PARTIAL"|"FAIL"), score (0-100), tier ("Platinum"|"Standard"|"Partial"|"Risk"), fail_codes (list), settlement (always None — this server has no settlement capability), agent_performance
| Name | Required | Description | Default |
|---|---|---|---|
| sla | No | ||
| agent_id | No | ||
| result_content | Yes | ||
| task_description | Yes |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate the tool is not read-only (readOnlyHint=false) and is open-world (openWorldHint=true), not idempotent, and not destructive. The description adds significant behavioral detail: the verdict applies only to the submitted content, repeated calls on unchanged input don't converge, and each call counts against daily quota. This exceeds what annotations alone provide.
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 well-structured with clear sections (primary use case, verdict semantics, score variance, return format). It is concise for the amount of information provided, though slightly verbose in parts (e.g., the note about LLM confidence could be merged).
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 the tool's complexity (4 parameters, open-world behavior, return of multiple fields), the description is complete. It explains how to handle revisions, score variance, and optional parameters. The presence of an output schema reduces the need to describe return values, but the description still covers all key behavioral aspects.
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 no parameter descriptions exist in the schema. The description compensates well by explaining each parameter's purpose, including the sla parameter with supported keys and examples. However, it doesn't explicitly describe agent_id or the structure of the return value beyond what the output schema could provide, though the description of the return dict is thorough.
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 that the tool verifies AI-generated output using VOP, distinguishing it from simple self-assessment. It explicitly differentiates from siblings like check_verdict, get_insights, etc., by focusing on the verification of content with grounded web search.
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 provides explicit guidance on when to use this tool (verifying any AI-generated content before final presentation) and what not to rely on (LLM's own confidence). It also explains edge cases like content revisions requiring new submissions and score variance due to live search.
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.
v1.0.0check_appealcheck_verdictget_insightsget_manager_alertslist_criteria_templateslist_verificationssubmit_appealsubmit_feedbackverify_outputScored across 9 tools
Each tool has a clearly distinct purpose: verify_output submits content for verification, check_verdict retrieves a specific result, get_insights tracks agent performance, list_verifications searches records, submit_feedback and submit_appeal handle user-side actions. No two tools have overlapping functionality.
All tools follow a consistent verb_noun pattern (verify_output, check_verdict, get_insights, list_verifications, submit_feedback, list_criteria_templates, get_manager_alerts). The naming is predictable and clearly conveys the action and resource involved.
With 9 tools, the set is well-scoped for the domain of AI output verification. Each tool serves a necessary function in the verification, retrieval, feedback, and appeal lifecycle without redundancy or bloat.
The tool surface covers the full verification lifecycle: submitting output, retrieving results, listing history, checking appeals, tracking agent performance, providing feedback, and browsing templates. No obvious gaps exist for the stated purpose of verifying AI-generated content.
Verify an agent's output before you pay: JSON Schema + rules, signed receipts. Free during launch.
Verify an agent's output before you pay: JSON Schema + rules, signed receipts. Free during launch.
Paid agent work and paid verification, settled in USDC. Verified outcomes get signed receipts.
Issue signed receipts for AI agent actions; verify any receipt offline - free, no account.
