免费 VOP（已验证输出协议）AI 智能体输出验证 — 让 Claude 及任何兼容 MCP 的 AI 智能体对任务输出进行 0–100 分的客观评分，并获得 PASS/PARTIAL/FAIL 判定。
本服务器仅提供免费的验证功能，属于更大结算协议的一部分：VOP 对智能体输出进行评分，将判定结果以 evidence_hash 的形式锚定在链上，并在 AgenticSettle 的付费平台上（本服务器不含此功能）在判定通过后释放托管付款。从验证 → 锚定 → 结算的完整流程已在 Base Sepolia（OP Stack L2）上使用 x402 支付协议完成端到端实时验证。此仓库仅包含验证步骤，免费且独立运行。
本服务器是什么： 一个质量验证工具。提交任务描述和智能体输出；获取客观的 0–100 分、判定结果和等级。 本服务器不是什么： 支付处理器、托管服务或任何涉及资金、代币或金融资产转移的工具。本服务器没有此类功能——每个工具均为只读，或仅写入验证记录，且均不涉及双方之间的价值转移。（AgenticSettle 的完整平台确实为付费客户提供质量门槛的托管结算功能，但出于设计考虑，这些工具未包含在此 MCP 服务器中——参见为什么这是一个独立的小型服务器。）
要求： Python 3.10+，AgenticSettle API 密钥（免费，自助获取，无需信用卡）。
即时获取密钥——无需等待，无需邮件往来：
curl -X POST https://app.agenticsettle.io/v2/signup \
-H "Content-Type: application/json" \
-d '{"email":"you@example.com"}'这将立即返回一个免费层级密钥（每天 50 次 verify_output 调用；其余 8 个工具无每日限制）。密钥仅在响应中显示一次——请保存。
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_mcp将以下代码块添加到你的 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"
}
}
}
}或者安装打包的 .mcpb 扩展（一键安装，参见 Releases — 每个标记版本都会自动按平台构建）——安装时 Claude Desktop 会提示你输入 API 密钥。
python -m agenticsettle_verify_mcpRelated MCP server: agentic-platform
所有 9 个工具均免费——无需注册账户、无需托管、无需任何形式的付款。
工具 | 功能 |
| 对 AI 智能体输出进行 0–100 分评分，获取 PASS/PARTIAL/FAIL 判定 |
| 通过报告 ID 检索现有的验证判定 |
| 获取智能体的 VOP 综合性能统计 |
| 使用筛选和分页列出历史验证记录 |
| 报告关于本服务器或某判定的问题或建议 |
| 对判定提出异议并获取确定性防篡改检查 |
| 检查已提交异议的状态和结果 |
| 列出捆绑的领域评分标准模板 |
| 列出本账户自身的监督事件（绝不涉及其他账户） |
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", ...}某些 MCP 主机（包括 Claude Desktop）不会在每次收到“这个准备好了吗？”/“帮我检查一下”请求时自动调用 verify_output，尤其是在刚安装后——Claude 可能仅凭自身判断来回答，而不是调用该工具。如果你注意到此情况，请将以下内容添加到 Claude 的个人指令/记忆中（Claude.ai 设置 → 个人资料 → “Claude 在回复时应考虑哪些个人偏好？”，或 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.这是可选项——工具无需此操作也能工作——但它能让 Claude 主动调用 verify_output，而无需每次明确指示使用 AgenticSettle 工具。
AgenticSettle 的完整平台还支持质量门槛的托管结算——在买方和智能体之间锁定代币，当 VOP 确认交付后自动释放。这些工具（submit_task、complete_task、settle_payment、cancel_task、register_token、get_token_balance、create_criteria、sign_criteria、get_criteria、list_tasks、get_task）涉及双方之间的价值转移，因此有意不包含在此 MCP 服务器中。本服务器的存在是为了让任何人都能免费试用客观的 AI 输出验证，无需注册账户——在接触付费或托管工作流之前，建立对输出质量的直观理解。如果你需要托管/结算工具，请直接使用 AgenticSettle API/SDK（参见 agenticsettle.io）。
需要两个环境变量才能启动；其余为可选调优参数：
export AGENTIC_SETTLE_BASE_URL="https://app.agenticsettle.io" # default if omitted
export AGENTIC_SETTLE_API_KEY="your-api-key-here" # required变量 | 默认值 | 用途 |
|
| 后端 URL |
| (必需) | 每次请求发送的 |
|
| 每次 HTTP 请求的超时秒数（从 30.0 提高——验证过程可能需要约 53 秒） |
|
| 对 429/502/503/504 或网络错误的最大重试次数 |
|
| 重试之间以逗号分隔的回退秒数 |
| (未设置) | 如果设置， |
如果 AGENTIC_SETTLE_API_KEY 未设置，每个工具调用都会立即报错：
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 通过环境变量读取——绝不硬编码。
密钥仅通过 HTTPS 在 x-api-key 请求头中发送；绝不会包含在服务器响应或日志中。
如果密钥缺失，每个工具调用都会立即报错，不会发起任何网络请求——这是下方字典错误契约的两个例外之一。
服务器通过 stdio 传输运行——不打开网络端口；通信仅通过 MCP 主机进程（Claude、Claude Desktop 等）进行。
本服务器不转移任何金钱、代币或任何形式的金融资产——每个工具要么读取验证/事件记录，要么写入验证/反馈/异议记录。
层级 | 端点 | 限制 |
无 API 密钥（公开） | 无——所有工具均需密钥 | — |
免费 API 密钥 |
| 每天每个密钥 50 次验证调用 |
免费 API 密钥 | 所有其他工具 | 无每日配额——仅需认证 |
超出限制时，后端返回 HTTP 429。本服务器会自动重试并带有回退机制，因此短暂的突发流量会被透明处理。
服务器会在 HTTP 429/502/503/504 及网络错误时自动重试，并带有回退机制（5 秒 → 15 秒，最多 3 次）。
大多数错误以返回形式出现，而非抛出：输入无效或后端返回 4xx 时，工具返回 {"error": str, "status_code": int} 而不是抛出异常——检查结果中是否有 "error" 键，而无需将调用包裹在 try/except 中。只有两种情况会实际抛出异常：
AGENTIC_SETTLE_API_KEY 缺失——立即抛出，因为任何工具都无法运行。
所有重试后后端仍不可达——抛出 RuntimeError（连接失败，而非 4xx/5xx 响应，因此无法附加 status_code）。
情况 | 返回内容 |
API 密钥缺失/无效 | 抛出 |
| 返回 |
| 返回 |
后端暂时不可用（429/502/503/504） | 自动重试，然后成功或返回结构化错误字典 |
重试耗尽后端仍不可达 | 抛出 |
| 不是错误——返回正常报告，包含 |
完整政策请参见 PRIVACY.md——本服务器向 AgenticSettle 后端发送哪些数据、如何使用、如何存储，以及如何请求访问或删除。
问：这是一个金融服务或支付处理器吗？ 答：不是。本服务器没有转移资金、代币或任何金融资产的能力——每个工具要么对验证进行评分/检索，要么记录反馈。
问：我需要付费计划吗？ 答：不需要——本服务器中的所有工具均免费。AgenticSettle 的单独付费层级（门槛托管结算）在此完全不暴露。
问：支持哪些 AI 智能体？ 答：任何兼容 MCP 的智能体——Claude、GPT-4o、Gemini 或任何自定义智能体。VOP 是模型无关的；它评估输出，而非产生输出的模型。
问：我提交的内容会怎样处理？ 答：参见 PRIVACY.md——简言之，仅用于计算你的验证分数，并存储以便你之后检索。
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.
