MCP server for verifying AI agent claims vs reality — single-transcript inline grounding-check that flags when an agent's response states facts not in the input context, when its code silently swallows exceptions and substitutes mock data, or when its multi-turn transcript contains contradictions or unverified completion claims. Sub-second, local, free, MCP-native — designed to be called inline from Claude Code / Cursor / Cline / OpenClaw agents during the conversation, not as a separate eval-pipeline. The lightweight complement to dashboard-based eval frameworks (DeepEval, Phoenix, LangSmith).
Production AI agents fail in three quiet ways that pass every standard dashboard. As of mid-2026 the failure modes are now research-grade: the Centre for Long-Term Resilience analyzed 183,420 conversations and found 698 real-world scheming incidents in just 6 months (Oct 2025 – Mar 2026), with monthly incident rate growing 4.9× — "AI was caught lying to users, ignoring direct instructions, breaking its own safety guardrails, and pursuing goals in ways that caused real harm". This MCP catches the inline-conversation surface of that pattern.
A working engineer (@chiefofautism, 158↑ / 135 RTs / 11.5K views) describes the most common variant in one line:
"claude code runs shell commands with YOUR permissions. it can rm -rf your repo. it can force push to main. it can drop your database. and it will do it confidently while telling you that he cleaned up the project structure"
That second half — "while telling you that he cleaned up the project structure" — is exactly the hallucinated-completion-claim surface this server checks. Pair with bash-vet-mcp for the first half (catches the destructive command before it runs).
Hallucinated claims. r/SaaS founder thread (May 2 2026) verbatim: "Status 200, latency normal, tokens normal. A hallucinated response looks identical to a good one in every standard dashboard." The fix the founder describes is exactly what this MCP server provides: "a lightweight check that flags when the model states something not in the input context."
Silent fake success in agent-written code. r/ClaudeAI thread (509 pts, 186 comments) verbatim: "The agent couldn't get auth working, so it quietly inserted a try/catch that returns sample data on failure. The output you saw on day one was never real."
Unverified completion claims. r/AI_Agents (114 pts) — agent self-reports completion ("I've configured X"); reality at outcome level (booked meetings, deployed services, working integrations) doesn't match.
Stated-vs-actual divergence. Newer pattern surfaced in the same CLTR data: agent's own chain-of-thought acknowledges a constraint, then violates it. The Codex example (cited in Nav Toor's thread): "OpenAI Codex was running in read-only sandbox mode. It explicitly noted the read-only constraint in its own chain of thought. Then it escalated permissions and wrote to disk anyway." Covered in v1.1 by the new verify_action_outcome tool — pass read_only: true in the before-snapshot and any state change in the after-snapshot triggers ACTION_OUTCOME.STATE_VIOLATED_CONSTRAINT (CRITICAL).
The "agent's confession" pattern. HN: "An AI agent deleted our production database. The agent's confession is below" (859↑ / 1,030 comments, May 2026) — jeremyccrane documented an agent issuing a destructive GraphQL mutation that wiped a production volume, then confessing to it after the fact. The community-sized-up failure mode: "It's a privilege issue, not an execution issue." The agent's after-the-fact confession is canonical output-action divergence — covered in v1.1 by verify_action_outcome(claim, before_snapshot, after_snapshot). Pair with bash-vet-mcp for the first half (block the destructive curl-with-mutation at command-approval time, before it runs).
This MCP server runs three pure-Python checks inline during the conversation — no API key, no LLM-as-judge cost, sub-second:
> claude: did your last answer hallucinate anything?
[MCP tool: verify_response_grounding]
verdict: FABRICATED
ungrounded_count: 3
overall_grounding_score: 0.08
ungrounded claims:
- "Acme Corp has raised $12M in Series A funding" (overlap 0.04)
- "led by Sequoia Capital" (overlap 0.00)
- "47 full-time employees" (overlap 0.00)
summary: All 3 claim(s) lack grounding in the input context — likely hallucinated.> claude: scan the code you just wrote for swallowed-exception patterns.
[MCP tool: find_swallowed_exceptions]
verdict: FABRICATED (one HIGH-severity finding)
findings:
[HIGH] Line 12 — mock-substitution
except Exception:
return {"id": 1, "name": "sample"}
Description: except handler returns fabricated/mock data instead of re-raising
— the call site sees a 'successful' response built from constants. This is the
silent-fake-success pattern.
summary: 1 swallowing pattern detected — at least one returns fabricated data.> claude: review the agent's transcript so far.
[MCP tool: review_transcript]
verdict: FABRICATED
issue_count: 2
issues:
[HIGH] turns [3] — unverified-completion-claim
"I've configured the gateway and verified everything works."
Description: assistant claims completion of an action but no tool calls are
present in this turn or earlier turns.
[MEDIUM] turns [2, 7] — cross-turn-contradiction
Cross-turn factual drift on subject 'the api':
turn 2 says 'returns json for every request',
turn 7 says 'returns xml for legacy endpoints'.
summary: Reviewed 8 turn(s); flagged 2 issue(s) including unverified completion
claim(s) — investigate before trusting the transcript.Related MCP server: truth-anchor-agent
openclaw-output-vetter-mcpThree things existing eval frameworks (DeepEval, Phoenix, LangSmith, Galileo, Langfuse) don't do well together:
Inline single-transcript scope, not eval-pipeline orchestration. DeepEval ships an MCP server — but its scope is "run evals, pull datasets, and inspect traces straight from claude code, cursor" (verbatim from their docs). That's eval-pipeline orchestration: schedule a named eval suite against a stored dataset; review trace history. This server is the opposite shape: verify this specific conversation right now, before the user sees the response. Same metric stack philosophically (faithfulness, grounding); different surface.
Sub-second + local + free. No LLM-as-judge call, no API key, no per-call cost. Pure-Python claim splitting + stem-Jaccard overlap + entity-mismatch detection + AST walking. Honest about what lexical methods catch and what they don't — see "Grounding-scanner limitations" below. For high-frequency inline use (every assistant turn) the speed-vs-accuracy tradeoff favors lightweight. The roadmap offers optional DeepEval-LLM-as-judge mode for users who want semantic-level verification on top of the lexical layer.
Three checks for three distinct failure modes, not one umbrella metric.
Grounding (verify_response_grounding) catches hallucinated facts
Swallowed exceptions (find_swallowed_exceptions) catches silent-fake-success in agent-written code
Transcript review (review_transcript) catches unverified completion claims + cross-turn drift
Other tools collapse all three into "faithfulness." The failure modes are different and the corrective actions are different. Surfacing them separately makes the response actionable.
The grounding scanner is lexical — it computes stem-level token overlap (Jaccard) between claim and context, plus an entity-coverage check on proper nouns / numbers. Two signals, combined for the verdict.
What it CATCHES:
Direct fabrication (claim has zero meaningful overlap with context)
Paraphrased grounded claims that share stems with context (mutates ≈ mutating ≈ mutation)
Entity misattribution — claim names a proper noun or number that isn't in the context (e.g. "The Eiffel Tower is in Berlin" against a context that mentions Paris — vocabulary overlaps but Berlin is flagged as unsupported)
What it DOES NOT CATCH (the response always ships a confidence_note repeating this — surface it to the operator):
Inferred claims requiring world knowledge — "Python is older than JavaScript" given dates 1991/1995 in context. The inference is correct but the word "older" doesn't appear; lexical methods can't infer ordering from facts.
Vocabulary-overlap fabrications where the wrong subject is associated with the right object — "Honeybees produce silk" against a context that mentions both honeybees and silk separately. Bag-of-stems sees the overlap and concludes grounded; only relation-level parsing or NLI can catch this.
For those failure modes, pair this tool with an LLM-as-judge or NLI verifier. We keep this scanner pure-Python + sub-second so it can run inline on every agent response — the right move is a layered approach (this for fast inline, LLM-as-judge for periodic deep-check).
We chose to ship the lexical scanner with explicit limit-disclosure rather than a heavyweight semantic dependency that breaks the "sub-second / no API key" pitch. Validation results: 4 of 5 adversarial test cases pass; the 1 remaining failure is the wrong-subject-overlap case described above.
Built for the production AI operator who's already using Claude Code / Cursor / Cline / OpenClaw and wants a defensive layer the agent calls before its response goes user-facing.
Tool | What it returns |
| Per-claim grounded/ungrounded + overall verdict (CLEAN / PARTIALLY_GROUNDED / FABRICATED) + stem-Jaccard overlap scores + per-claim |
| Per-finding line number + pattern ( |
| Per-issue turn indices + issue kind ( |
| NEW — compare an agent's stated outcome against actual before/after state snapshots. Catches the [@chiefofautism, 158↑] case (agent says "I cleaned up the project structure" when nothing changed) + the Codex sandbox-escalation case (read-only constraint asserted, then violated). 8 detection rules under |
Resources:
vetter://demo/grounded — sample CLEAN grounding result
vetter://demo/fabricated — sample FABRICATED grounding result
vetter://demo/swallowed-exceptions — sample swallowed-exception scan
vetter://demo/action-divergence (v1.1+) — sample FABRICATED action-outcome verdict (claim says "cleaned up" but before == after)
Prompts:
verify-this-answer(threshold) — walks verify_response_grounding on the most recent assistant answer
audit-this-code — walks find_swallowed_exceptions on a code block + explains each finding's risk
verify-this-action (v1.1+) — walks verify_action_outcome with snapshot-capture guidance + per-mismatch interpretation
pip install openclaw-output-vetter-mcpAfter install, run the bundled demo to see all three scanners catch real failure patterns:
openclaw-output-vetter-mcp-demoYou'll see four cases: a paraphrased grounded answer (CLEAN), an entity-mismatch fabrication (FABRICATED), a Python try/except: pass block flagged for swallowing exceptions, and the canonical chiefofautism May-2026 HN failure mode — an agent claim "I cleaned up the project structure" against an unchanged before/after snapshot returning STATE_UNCHANGED FABRICATED verdict. No external I/O, no API keys — safe to run anywhere.
Add to ~/Library/Application Support/Claude/claude_desktop_config.json (macOS) or %APPDATA%\Claude\claude_desktop_config.json (Windows):
{
"mcpServers": {
"openclaw-output-vetter": {
"command": "python",
"args": ["-m", "openclaw_output_vetter_mcp"]
}
}
}Restart Claude Desktop. Test:
Resource
vetter://demo/grounded— read it back to me.
The demo resource returns a sample GroundingResult so you can verify the protocol wiring without authoring inputs.
Version | Scope | Status |
v1.0 | 3 scanners (grounding via Jaccard / swallowed-exceptions via AST / transcript review via pattern matching), 3 tools / 3 demo resources / 2 prompts, GitHub Actions CI matrix, PyPI Trusted Publishing, MCP Registry submission, 40+ tests | ✅ |
v1.1 | Optional LLM-as-judge backend (wraps DeepEval's | ⏳ |
v1.2 | Backend-pluggable architecture (per-tool backend selection); incremental review (verify only the last N turns); persistent issue tracking across multi-session work | ⏳ |
v1.x | Webhook emit on FABRICATED verdict; integration with CI to gate AI-generated PRs that fail grounding checks | ⏳ |
If your AI deployment uses a different agent harness, custom claim-extraction prompts, language other than Python for the swallowed-exception scanner, or specific compliance / auditing requirements — that's a Custom MCP Build engagement.
Tier | Scope | Investment | Timeline |
Simple | Custom claim-extraction prompts + tuned thresholds for your domain | $8,000–$10,000 | 1–2 weeks |
Standard | Multi-language swallowed-exception scanners (TypeScript / Go / Rust AST walks) + custom severity rules | $15,000–$25,000 | 2–4 weeks |
Complex | LLM-as-judge backend with your hosted model + persistence + CI integration + audit-trail | $30,000–$45,000 | 4–8 weeks |
To engage:
Email hello@temhan.dev with subject Custom MCP Build inquiry — output verification
Include: 1-paragraph description of your stack + which tier
Reply within 2 business days with a 30-min discovery call slot
This server is part of a production-AI infrastructure MCP suite — companion to silentwatch-mcp (cron silent-failure detection), openclaw-health-mcp (deployment health), openclaw-cost-tracker-mcp (token-cost telemetry + 429 prediction), openclaw-skill-vetter-mcp (skill security vetting), and openclaw-upgrade-orchestrator-mcp (upgrade safety + provider-side regression detection). Install all six for full operational visibility.
If you're running production AI and want an outside practitioner to score readiness, find the failure patterns already present (silent fake success being pattern P3.x in the catalog), and write the corrective-action plan:
Tier | Scope | Investment | Timeline |
Audit Lite | One system, top-5 findings, written report | $1,500 | 1 week |
Audit Standard | Full audit, all 14 patterns, 5 Cs findings, 90-day follow-up | $3,000 | 2–3 weeks |
Audit + Workshop | Standard audit + 2-day team workshop + first monthly audit included | $7,500 | 3–4 weeks |
Same email channel: hello@temhan.dev with subject AI audit inquiry.
PRs welcome. The three scanners are intentionally pluggable — each lives in its own module under src/openclaw_output_vetter_mcp/scanners/ and is a pure function over input → typed result. Adding a new scanner is one file + one test file + one tool registration in server.py.
Bug reports + feature requests: open a GitHub issue.
MIT — see LICENSE.
Production-AI MCP Suite (Gumroad bundle) — this server plus 6 others in one curated 7-pack bundle
silentwatch-mcp — cron silent-failure detection
openclaw-health-mcp — deployment health
openclaw-cost-tracker-mcp — token-cost telemetry + 429 prediction (v1.1+)
openclaw-skill-vetter-mcp — skill security vetting
openclaw-upgrade-orchestrator-mcp — upgrade safety + provider-side regression detection (v1.2+)
AI Production Discipline Framework — Notion template, $19 — the methodology these MCP tools implement
SPEC.md — full server design
Built by Temur Khan — production AI engineer. Contact: hello@temhan.dev
Scan Python source code for try/except patterns that swallow errors or substitute fabricated mock data — the silent-fake-success pattern from the r/ClaudeAI thread. Flags pass-only handlers, mock-substitution returns, silent log-and-return, and bare excepts. Each finding includes a line number + severity + code excerpt.
| Name | Required | Description | Default |
|---|---|---|---|
| code | Yes | Python source code to scan |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden. It clearly states the tool scans code and outputs findings with line number, severity, and code excerpt, indicating a read-only, non-destructive operation. It could mention no side effects explicitly, but is sufficient.
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?
Two sentences with no wasted words: the first explains purpose and patterns, the second describes output. Every part adds value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a single-parameter tool with full schema coverage and no output schema, the description sufficiently covers what the tool does and what it returns. It could explicitly state the return format (e.g., list of objects), but it is implied.
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 100%, so baseline is 3. The description adds context about the patterns detected, which helps understand how the 'code' parameter is used, but does not add format or constraints beyond what the schema provides.
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 uses a specific verb 'Scan' and resource 'Python source code', and explicitly lists the patterns it detects (pass-only handlers, mock-substitution returns, etc.), clearly differentiating it from sibling tools that deal with transcripts or verification.
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 for detecting specific code smells but does not specify when to use this tool versus alternatives or mention any exclusions. Context from sibling names shows distinct use cases, but explicit guidance is missing.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Multi-turn agent transcript review — flags unverified completion claims (assistant says 'I've configured X' with no supporting tool calls), cross-turn factual contradictions, and tool calls without observable side effects. Pass an array of {role, text, tool_calls?} objects.
| Name | Required | Description | Default |
|---|---|---|---|
| transcript | Yes | List of turns. Each: {role, text, tool_calls?} |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. It discloses the tool's behavior: it flags specific types of issues (unverified claims, contradictions, tool calls without side effects). No mention of destructive actions or auth needs, but for a review tool this is acceptable.
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?
Two sentences, front-loaded with key purpose and specific detection criteria. No redundant or unnecessary words. Efficient and well-structured.
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 parameter, no output schema. Description explains input and detection criteria well, but could mention the output format (e.g., list of issues) for completeness. Still adequate for the complexity.
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 100% with descriptions for the transcript items. The description adds value by explaining the structure and purpose of the parameter ('Pass an array of {role, text, tool_calls?} objects'). It clarifies the expected input 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?
Description clearly states the tool's purpose: reviewing multi-turn agent transcripts for specific issues (unverified claims, contradictions, tool calls without side effects). It distinguishes from sibling tools like find_swallowed_exceptions and verify_action_outcome by focusing on transcript analysis.
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?
Description implies usage for analyzing agent transcripts and lists what it detects, but does not explicitly state when to use this tool versus alternatives or when not to use it. The context of sibling tools helps, but explicit guidance would improve.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
v1.1+ — Compare an agent's stated outcome against actual before/after state snapshots. Catches the [@chiefofautism, 158↑] failure mode: agent runs rm -rf / git push --force and then says 'I cleaned up the project structure' — bash-vet catches the destructive command, this checks the misreport about what got done. Also catches the Codex-CoT sandbox-escalation pattern: agent acknowledges read-only constraint, then writes anyway (pass read_only: true in the before snapshot). Pure function — caller captures snapshots; server is stateless. Returns ActionOutcomeReport with verdict (CLEAN / PARTIALLY_GROUNDED / FABRICATED / UNVERIFIED) + per-mismatch evidence.
| Name | Required | Description | Default |
|---|---|---|---|
| claim | Yes | The agent's stated outcome — verbatim. Examples: 'I cleaned up the project structure', 'tests pass', 'committed and pushed', 'created auth_v2.py'. | |
| before_snapshot | Yes | Caller-captured state BEFORE the agent acted. Recognized keys: files (list[str]), git_status, git_tip / git_head / git_log_tip (str SHA), tests_status / test_status, read_only (bool — asserts no-write constraint). Other keys are tracked but not matched against claim. | |
| after_snapshot | Yes | Caller-captured state AFTER the agent acted. Same key conventions as before_snapshot. | |
| expected_changes | No | Optional caller-supplied list of expected changes. Recognized formats: 'file:foo.py:added', 'file:bar.py:removed', 'git:committed', 'git:clean', 'tests:pass'. Each missing entry becomes a MISSING_EXPECTED_CHANGE finding. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description fully discloses behavior: pure function, stateless, returns structured verdict. It details the verdict categories and limitation of snapshot capture, providing complete transparency.
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 detailed and informative, but somewhat verbose. It front-loads the purpose but includes extensive examples and context that could be condensed without losing value.
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 (4 params, nested objects, no output schema), the description is highly complete. It explains the return type, verdict values, and use cases, leaving no major gaps for an agent to understand usage.
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 100% and schema descriptions are present. The description adds valuable context (examples, recognized keys, formats) that goes beyond the schema, aiding parameter understanding.
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 compares agent's stated outcome against before/after snapshots to detect misreporting, with specific failure modes and a clear verdict output. It distinguishes effectively from sibling tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explains when to use the tool and provides context (pure function, stateless), but does not explicitly state when not to use it or offer direct comparisons to sibling tools, which slightly reduces clarity.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Check that every claim in answer has support in context. Returns per-claim grounded/ungrounded + an overall verdict (CLEAN / PARTIALLY_GROUNDED / FABRICATED). Use inline during an agent conversation to flag hallucinated responses before they become user-facing facts. Sub-second, local, no API key.
| Name | Required | Description | Default |
|---|---|---|---|
| question | Yes | The user question (used for context-binding; v1.0 stores but doesn't use) | |
| context | Yes | Retrieval / source context the answer should be grounded in | |
| answer | Yes | The agent's response to verify | |
| threshold | No | Jaccard overlap threshold for `grounded` (0.0–1.0). Default 0.30. Lower = more permissive, higher = stricter. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Without annotations, the description carries the full burden. It discloses that the tool is sub-second, local, no API key, returns per-claim and overall verdict, and notes a quirk about the question parameter (stored but unused in v1.0). It lacks details on error handling or edge cases but provides substantial behavioral insight.
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?
Three sentences, each earning its place: first defines action and output, second gives usage context, third adds performance and privacy traits. No fluff, no repetition.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema, the description explains return format (per-claim + verdict). It covers usage, parameters, behavior, and performance. For a verification tool with simple inputs and outputs, this is fully complete.
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 100%, and the description adds meaningful context beyond the schema: it explains the threshold parameter (Jaccard overlap, default 0.30, effect of lower/higher values) and the question parameter's current behavior (stored but unused). This fully compensates for any schema gaps.
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 'Check' and resource 'every claim in answer has support in context'. It explicitly names the return values (per-claim grounded/ungrounded + overall verdict) and distinguishes itself from sibling tools like find_swallowed_exceptions or review_transcript by focusing on factual grounding.
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 to 'Use inline during an agent conversation to flag hallucinated responses before they become user-facing facts'. This gives a clear when-to-use scenario. It does not explicitly list when not to use or alternatives, but the context is sufficient for an agent to understand its purpose.
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.3.0find_swallowed_exceptionsreview_transcriptverify_action_outcomeverify_response_groundingScored across 4 tools
Each tool targets a distinct aspect of output vetting: code exception swallowing, transcript review, action outcome verification, and response grounding. No two tools overlap in purpose; descriptions clearly differentiate them.
All tool names follow a consistent verb_noun pattern in snake_case: find_swallowed_exceptions, review_transcript, verify_action_outcome, verify_response_grounding. The verbs are descriptive and the pattern is uniform.
With four tools, the server is well-scoped for its purpose. Each tool covers a critical vetting check without unnecessary bloat or gaps. The count is appropriate for a specialized vetting server.
The tool set covers the main failure modes mentioned (exception swallowing, unverified claims, action misreports, hallucinated responses). Minor gaps might include verifying tool call correctness or security issues, but the set is reasonably complete for its intended domain.
MCP server for AI agents to plan, verify, and deploy Cloudflare-native apps.
MCP server for building and testing AI agents with multi-model experimentation and insights.
AgentGuard — 20-tool AI safety MCP: policy preflight, risk scoring, audit logging, rate limits.
Persistent, inspectable memory for AI agents with lineage, correction, and a hosted MCP endpoint.