Free VOP (Verified Output Protocol) verification for AI agent outputs — lets Claude and any MCP-compatible AI agent objectively score task outputs 0–100 and get a PASS/PARTIAL/FAIL verdict.
This server exposes the free, verification-only slice of a larger settlement
protocol: VOP scores an agent's output, anchors the verdict on-chain as an
evidence_hash, and (on AgenticSettle's paid platform, not in this server)
releases escrowed payment once that verdict passes. That full loop — verify →
anchor → settle — has been live-verified end-to-end on Base Sepolia (an OP
Stack L2) using the x402 payment protocol. This repository is only the
verification step, free and standalone.
What this server is: A quality-verification tool. Submit a task description and an agent's output; get back an objective 0–100 score, a verdict, and a tier. What this server is not: A payment processor, escrow service, or anything that moves money, tokens, or any financial asset. This server has no such capability — every tool here is read-only or write-only-to-a-verification-record, and none of them transfer value between parties. (AgenticSettle's full platform does support quality-gated escrow settlement for paying customers, but those tools are intentionally not part of this MCP server — see Why this is a separate, smaller server.)
Requirements: Python 3.10+, an AgenticSettle API key (free, self-service, no credit card).
Get a key instantly — no waiting, no email round-trip:
curl -X POST https://app.agenticsettle.io/v2/signup \
-H "Content-Type: application/json" \
-d '{"email":"you@example.com"}'This returns a free-tier key immediately (50 verify_output calls/day; no daily
limit on the other 8 tools). It's shown once in the response — save it.
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_mcpAdd this block to your 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"
}
}
}
}Or install the packaged .mcpb extension (single-click, see Releases — built automatically per-platform on each tagged release) — Claude Desktop will prompt you for your API key on install.
python -m agenticsettle_verify_mcpRelated MCP server: agentic-platform
All 9 tools are free — no account setup, no escrow, no payment of any kind.
Tool | What it does |
| Score AI agent output 0–100, get a PASS/PARTIAL/FAIL verdict |
| Retrieve an existing verification verdict by report ID |
| Get an agent's aggregate VOP performance statistics |
| List past verification records with filters and pagination |
| Report an issue or suggestion about this server or a verdict |
| Dispute a verdict and get a deterministic tamper check |
| Check the status and outcome of a submitted appeal |
| List bundled domain rubric templates |
| List this account's own oversight incidents (never another account's) |
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", ...}Some MCP hosts (including Claude Desktop) don't automatically call verify_output
on every "is this ready?" / "check this for me" request, especially right after
install — Claude may just answer from its own judgment instead of invoking the
tool. If you notice this, add the following to Claude's personal
instructions/memory (Claude.ai Settings → Profile → "What personal preferences
should Claude consider in responses?", or the equivalent in 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.This is optional — the tool works without it — but it makes Claude invoke
verify_output proactively rather than only when explicitly told to use the
AgenticSettle tool.
AgenticSettle's full platform also supports quality-gated escrow settlement —
locking tokens between a buyer and an agent, releasing them automatically
once VOP confirms delivery. Those tools (submit_task, complete_task,
settle_payment, cancel_task, register_token, get_token_balance,
create_criteria, sign_criteria, get_criteria, list_tasks, get_task)
move value between two parties, so they are intentionally not included
in this MCP server. This server exists to let anyone try objective AI
output verification — free, no account commitment — as a way to build
intuition about output quality before ever touching a paid or escrow
workflow. If you need the escrow/settlement tools, use the AgenticSettle
API/SDK directly (see agenticsettle.io).
Two environment variables are required to get started; the rest are optional tuning knobs:
export AGENTIC_SETTLE_BASE_URL="https://app.agenticsettle.io" # default if omitted
export AGENTIC_SETTLE_API_KEY="your-api-key-here" # requiredVariable | Default | Purpose |
|
| Backend URL |
| (required) |
|
|
| Per-HTTP-request timeout in seconds (raised from 30.0 — grounded verification can take up to ~53s) |
|
| Max attempts on 429/502/503/504 or network errors |
|
| Comma-separated backoff seconds between retries |
| (unset) | If set, |
If AGENTIC_SETTLE_API_KEY is not set, every tool call raises an error immediately:
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 is read from environment variables — never hardcoded.
The key is sent only in the x-api-key request header over HTTPS; it is never included in server responses or logs.
If the key is missing, every tool call raises immediately without making any network call — this is one of the two exceptions to the dict-error contract below.
The server runs over stdio transport — no network port is opened; communication is exclusively through the MCP host process (Claude, Claude Desktop, etc.).
This server transfers no money, tokens, or financial assets of any kind — every tool either reads a verification/incident record or writes a verification/feedback/appeal record.
Tier | Endpoint | Limit |
No API key (public) | none — all tools here require a key | — |
Free API key |
| 50 verify calls/day per key |
Free API key | all other tools | No daily quota — auth only |
When the limit is exceeded the backend returns HTTP 429. This server retries automatically with backoff, so brief bursts are absorbed transparently.
The server retries automatically on HTTP 429/502/503/504 and network errors with backoff (5s → 15s, max 3 attempts).
Most errors are returned, not raised: on invalid input or a backend 4xx response, a tool returns {"error": str, "status_code": int} instead of throwing — check for an "error" key in the result rather than wrapping calls in try/except. Only two situations raise an actual exception:
A missing AGENTIC_SETTLE_API_KEY — raises immediately, since no tool can function without it.
The backend unreachable after all retries — raises RuntimeError (a connectivity failure, not a 4xx/5xx response, so there's no status_code to attach).
Situation | What you get |
Missing/invalid API key | Raises |
Invalid | Returns |
| Returns |
Backend temporarily down (429/502/503/504) | Auto-retry, then success or a structured error dict |
Backend down after retries exhausted | Raises |
Empty/short | Not an error — returns a normal report with |
See PRIVACY.md for the full policy — what data this server sends to the AgenticSettle backend, how it's used, stored, and how to request access or deletion.
Q: Is this a financial service or payment processor? A: No. This server has no capability to move money, tokens, or any financial asset — every tool either scores/retrieves a verification or records feedback.
Q: Do I need a paid plan? A: No — every tool in this server is free. AgenticSettle's separate paid tier (escrow-gated settlement) is not exposed here at all.
Q: Which AI agents are supported? A: Any MCP-compatible agent — Claude, GPT-4o, Gemini, or any custom agent. VOP is model-neutral; it evaluates the output, not the model that produced it.
Q: What happens to the content I submit? A: See PRIVACY.md — briefly, it's used only to compute your verification score and stored so you can retrieve it later.
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. Dates show when Glama detected each change.
v1.0.0check_appealcheck_verdictget_insightsget_manager_alertslist_criteria_templateslist_verificationssubmit_appealsubmit_feedbackverify_outputEach 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.
One MCP tool for verified AI-agent outcomes with success-only charging.
Issue signed receipts for AI agent actions; verify any receipt offline - free, no account.
Trust infrastructure for AI agents: read a verifiable Trust Rating, claim an identity, earn a badge.
Trust gate for AI agents: multi-model adversarial consensus, signed and verifiable verdicts.
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/agenticsettleio/agenticsettle-mcp'
If you have feedback or need assistance with the MCP directory API, please join our Discord server
