Kluster.ai Verify MCPofficial
A
licenseNot graded
qualityNot graded
maintenanceEnables fact-checking of AI responses against reliable sources and validation of responses against document content to ensure accuracy and reliability.
-
HallucC — Hallucination & Safety Guardian
Server Details
Fact-check LLM outputs with cited sources. API key: aihcc.cloud/keys.
Ownership verified
- Status
- Healthy
- Uptime
- 35.4% over 42 days
- Last Tested
- Transport
- Streamable HTTP · MCP 2025-11-25
- URL
- Repository
- fredyee/hallucc-mcp
- GitHub Stars
- 0
- Server Listing
- HallucC — Hallucination Fact-Check & AI Safety Guard
TDQS
A3.9/5.0
Scored across 5 tools
Disambiguation4/5
Tools mostly target distinct stages: CUA runtime actions vs CUA code audit, prompt/output gateway safety, agent trajectory plus output verification, and text claim verification. However, check_safety, verify_agent, and verify_text overlap around output/hallucination checking, so selection can require careful reading despite helpful descriptions.
Naming Consistency4/5
All tool names use snake_case with a clear prefix-plus-noun structure, which is predictable and readable. The main deviation is the use of two verb families, check_* and verify_*, for closely related validation operations rather than one consistent verb.
Tool Count5/5
With 5 tools, the set is well-scoped for a safety and hallucination guardian covering text, agents, CUA actions, and CUA code audits. Each tool appears to earn its place without obvious padding or severe under-coverage.
Completeness4/5
The surface covers the core safety and hallucination verification workflows across text, agent traces, CUA actions, and CUA source code. Minor gaps remain, such as no standalone prompt-only safety check and no tool for inspecting or managing the underlying rulesets.
Available Tools
5 toolscheck_cua_actionsClassify CUA ActionsARead-onlyInspect
Computer-Use Agent 动作风险分级。提交动作轨迹 → 逐步返回 L0(放行)/L1(放行+记录)/L2(需确认)/L3(阻断)/takeover(凭据场景挂起等用户亲手输入) 裁决、matched_rules、outcome，及 L0-L3 汇总计数；响应含 ruleset_version（规则库版本）与 disclaimer（本结果仅为分级参考，未执行实际拦截）。覆盖：敏感路径/破坏性命令/不可逆元素语义、域名分级（未知域导航 L2、黑名单域与敏感粘贴到未知域 L3、支付金额超阈值 L3）、凭据词表与支付/登录域 takeover、task_scope 任务意图偏离（越界升一级，只能收窄）、多智能体委托链字段（每条动作可选 chain_id/agent_id/parent_agent_id/delegation_depth，给了则服务端追加链级跨跳污点分析：跨 agent 传播时聚合级别抬到 L3 并置 risk_diluted，返回在 chain_trace 字段；未给则零影响）。纯规则判定，不调 LLM、不耗额度。用于在 agent 执行前/后做安全自检。
| Name | Required | Description | Default |
|---|---|---|---|
| actions | Yes | 待分级的动作序列（1~500 条） | |
| session_id | No | 给了则把分级结果写入审计表，可在 /cua/audit 回放 | |
| task_scope | No | 任务意图对齐（收窄机制）：动作越出 scope 时升一级处置（L0→L1、L1→L2、L2 保持但追加原因、L3 不变）。只能升级不能降级；不传则零影响。 |
Output Schema
| Name | Required | Description |
|---|---|---|
| chains | No | |
| results | No | |
| summary | No | |
| warning | No | |
| disclaimer | No | |
| session_id | No | |
| chain_trace | No | |
| has_propagation | No | |
| injection_steps | No | |
| ruleset_version | No |
TDQS
A4.6/5.0
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and destructiveHint=false, but the description adds substantial behavior the annotations cannot express: pure rule engine with no LLM call and no quota consumption, the tool does NOT actually block anything (disclaimer), session_id has an audit-table write side effect, and the optional chain_id/agent_id/parent_agent_id/delegation_depth fields trigger server-side cross-agent taint analysis that can raise the aggregate to L3 with risk_diluted returned in chain_trace. It also explains the narrowing-only semantics of task_scope. Nothing here contradicts the annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Front-loaded with purpose and verdict vocabulary, and every clause carries information (rule coverage, takeover conditions, chain behavior, cost profile). It is, however, one very dense run-on paragraph of nested parentheticals, which is harder to scan than it could be given the amount of content.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Even though an output schema exists (so return values need not be described), the description still enumerates the rule families, the takeover triggers, the optional audit/chain fields and the non-blocking caveat. For a nested-object classifier with side effects, an agent has everything it needs to call it correctly and interpret the result.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the baseline is 3, but the description genuinely adds semantics on top: task_scope can only upgrade a verdict (L0→L1, L1→L2) and never downgrades, the delegation-chain parameters are optional and have zero effect when omitted, and session_id enables audit replay. These are behavioral contracts the per-field schema text does not fully convey.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb+resource in the first phrase (Computer-Use Agent 动作风险分级) and immediately describes the input (动作轨迹) and output shape (逐步 L0/L1/L2/L3/takeover 裁决、matched_rules、outcome、汇总计数). The CUA-action scope cleanly separates it from siblings like check_cua_code_audit, check_safety, verify_agent and verify_text without needing to name them.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Gives a concrete usage context — "用于在 agent 执行前/后做安全自检" — which tells the agent when this tool belongs in a workflow. It does not, however, state exclusions or explicitly point to an alternative sibling (e.g. check_cua_code_audit for source-level checks), so routing between the five check_/verify_ tools is still partly inferred.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
check_cua_code_auditAudit CUA CodeARead-onlyIdempotentInspect
CUA 代码审计：静态分析 Agent 源码，检测危险导入（subprocess/os.system 等）、权限边界（eval/exec）、注入面（字符串拼接 shell）、危险默认值、沙箱缺失。纯规则扫描，不调 LLM、不耗额度。支持单文件或多文件扫描。
| Name | Required | Description | Default |
|---|---|---|---|
| code | No | 单文件模式：要扫描的源代码文本（≤50000 字符），与 files 二选一 | |
| files | No | 多文件模式：[{path, content, language?}] 数组，与 code 二选一 | |
| filename | No | 单文件模式：文件名，用于报告中标识（默认 input.py） | |
| language | No | 语言提示，auto 时按 filename 扩展名推断（默认 auto） |
Output Schema
| Name | Required | Description |
|---|---|---|
| summary | No | |
| findings | No | |
| disclaimer | No | |
| privacy_note | No | |
| ruleset_version | No |
TDQS
A3.7/5.0
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnly=true, destructive=false, idempotent=true, so the safety profile is covered. The description adds genuinely useful context beyond them: the scan is pure rule-based with no LLM calls and no quota consumption, which matters for cost-sensitive agent planning. It stops short of describing output/pagination, but with annotations covering safety a 4 is warranted.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Front-loaded with purpose, then a detection list, then behavioral/cost notes, then file-mode support. Every clause earns its place except the 'CUA 代码审计' prefix, which merely restates the name/title.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a read-only static-analysis tool with an output schema and full annotation coverage, the description supplies purpose, detection scope, cost model, and supported input modes. Nothing critical is missing, though sibling disambiguation would complete the picture.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already documents all four parameters. The description's mention of single-file vs multi-file modes loosely maps to the code/files mutual exclusivity but adds no syntax or constraint detail. Baseline 3 is correct when the schema does the heavy lifting.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb and resource ('静态分析 Agent 源码') and enumerates exactly what it detects (dangerous imports, eval/exec, injection surfaces, dangerous defaults, missing sandbox). This is far more specific than a tautology. However, it never differentiates itself from siblings like check_safety or verify_agent, so an agent cannot tell them apart without opening schemas.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
'支持单文件或多文件扫描' and '纯规则扫描，不调 LLM、不耗额度' imply the contexts where this is the cheap, deterministic choice. But there is no explicit when-to-use-vs-alternatives or when-not guidance relative to check_safety/verify_agent. Usage is implied rather than stated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
check_safetyCheck SafetyARead-onlyInspect
AI 安全网关检测。对 prompt + output 跑 OWASP LLM Top 10 三层检测：40+ 特征规则引擎（注入/越狱/有害内容/敏感信息泄露/欺诈）+ 可选 LLM 深度分析 + 可选幻觉检测。返回 passed、risk_score、risk_level、threats[]（category/severity/match_context/recommendation）、quota。fast=true 走纯规则 <10ms 模式。耗 detect 额度（fast 亦计入）。
| Name | Required | Description | Default |
|---|---|---|---|
| fast | No | true 走纯规则快速模式（<10ms，无 LLM）→ /guard/check-fast；默认 false 走完整 /guard/check | |
| output | Yes | AI 响应（≥1 字，≤50000 字） | |
| prompt | No | 用户原始输入（默认空，≤50000 字） | |
| check_hallucination | No | 是否同时检测幻觉，默认 false |
Output Schema
| Name | Required | Description |
|---|---|---|
| quota | No | |
| passed | No | |
| summary | No | |
| threats | No | |
| risk_level | No | |
| risk_score | No | |
| detection_id | No | |
| llm_analysis | No | |
| hallucination | No | |
| harmful_detected | No | |
| injection_detected | No | |
| jailbreak_detected | No |
TDQS
A3.7/5.0
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already mark this readOnly/non-destructive, so the bar is lower, and the description still adds real behavioral context beyond them: it consumes 'detect' quota even in fast mode, enumerates the three detection layers, and gives the <10ms latency profile. The quota-consumption side effect is the kind of operational cost an agent must know before calling.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
One dense, front-loaded paragraph: purpose first, then detection layers, then return fields, then mode/quota caveats. It is information-rich with minimal filler, though the return-field enumeration is somewhat redundant against the output schema and adds density.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With annotations covering the safety profile and an output schema covering return values, the description still supplies the missing operational facts: detection scope, layer composition, mode behavior, latency, and quota cost. An agent has enough to invoke it correctly; only sibling routing against verify_* remains unstated.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so fast/output/prompt/check_hallucination are already fully documented in the schema. The description largely repeats the fast semantics ('fast=true 走纯规则 <10ms') rather than adding syntax or defaults, with only the quota-counting note for fast being new information. Baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description names a specific operation and scope: OWASP LLM Top 10 three-layer detection over prompt + output, with a concrete rule-engine breakdown (injection/jailbreak/harmful content/leakage/fraud). It clearly distinguishes the resource being checked (AI prompt/output safety) from siblings like verify_agent or check_cua_code_audit, though it never names those siblings explicitly to route the agent.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
It gives a mode-selection rule (fast=true for pure-rule <10ms vs default full /guard/check) and warns that quota is consumed either way, which is genuinely useful context. However it offers no explicit when-to-use-this vs when-to-use verify_text/check_cua_actions guidance, leaving the sibling routing to inference.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
verify_agentVerify AgentARead-onlyInspect
Agent 输出与轨迹自检。对最终回答跑逐声明幻觉核验，并对执行轨迹做六维结构化评估（事实性/来源/指令合规/工具声明一致/任务完成/反思）。返回 main.claims、steps[].checks、quota。耗 detect 额度。
| Name | Required | Description | Default |
|---|---|---|---|
| task | No | 原始任务指令（task_completion 裁判用） | |
| speed | No | 速度模式：fast|standard|deep，默认 standard | |
| steps | No | agent 执行轨迹，逐步六维评估 | |
| domain | No | 领域模式：general|medical|legal|finance|education|government | |
| agent_output | Yes | agent 最终输出文本（≥1 字，≤50000 字） | |
| tool_schemas | No | 工具 Schema（与 trajectory 端点对齐） |
Output Schema
| Name | Required | Description |
|---|---|---|
| main | No | |
| quota | No | |
| steps | No | |
| agent_eval | No | |
| detection_id | No |
TDQS
A3.7/5.0
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, destructiveHint=false, openWorldHint=true, so the safety profile is covered. The description adds genuinely useful behavior beyond that: it discloses a quota/cost effect ('耗 detect 额度') and the shape of what comes back (main.claims, steps[].checks, quota), which is not derivable from the annotations. It does not, however, explain what triggers the six dimensions or any rate/limit detail beyond the quota note.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Three dense sentences, front-loaded with the core capability before the evaluation dimensions and the return keys. Every clause carries information, though the six-dimension parenthetical and the return-key list make it list-heavy rather than maximally tight.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a high-complexity tool (6 params, nested step objects, output schema present) the description names the evaluated dimensions, the quota cost, and the top-level response keys. Since an output schema exists, it needn't explain return values in depth, so this is close to complete — the only gap is the absent sibling routing that would let an agent pick this over verify_text.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so every parameter (task, speed, steps, domain, agent_output, tool_schemas) is already documented in the schema, and the enum values for speed/domain are enumerated there. The description adds only indirect hints ('task_completion 裁判用' maps to the task param, '逐声明' and '六维' hint at the nested steps checks), so it does not meaningfully exceed the schema baseline.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb+resource: per-claim hallucination verification of the final answer plus a named six-dimension structured evaluation of the trajectory (factuality/sources/instruction compliance/tool-claim consistency/task completion/reflection). This is far more specific than a tautology, but it never names or distinguishes itself from sibling verify_text or check_safety, so the agent must infer which verifier applies to agent outputs vs plain text.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Usage is implied by 'Agent 输出与轨迹自检' — this is the verifier for agent outputs and execution traces — but there is no explicit when-to-use/when-not statement and no routing guidance against verify_text, check_safety, or the check_cua_* siblings. The agent can guess the context but must infer it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
verify_textVerify TextARead-onlyInspect
逐声明幻觉核验。输入文本 → 提取声明 → 逐声明验证（supported/refuted/unverified）+ 来源引用。返回红/黄/绿汇总、每条声明的状态/置信度/理由/来源、citations、quota。耗 detect 额度（与 Web 端同源）。
| Name | Required | Description | Default |
|---|---|---|---|
| text | Yes | 待核验的文本 | |
| model | No | 被测模型名（选填，分享卡片展示用） | |
| speed | No | 速度模式：fast|standard|deep，默认 standard | |
| domain | No | 领域模式：general|medical|legal|finance|education|government | |
| strict | No | 严格模式（自我一致性），不传走全局默认 |
Output Schema
| Name | Required | Description |
|---|---|---|
| input | No | |
| quota | No | |
| speed | No | |
| claims | No | |
| domain | No | |
| strict | No | |
| summary | No | |
| citations | No | |
| elapsed_ms | No | |
| math_issues | No | |
| detection_id | No |
TDQS
A3.8/5.0
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already cover the safety profile (readOnlyHint=true, destructiveHint=false, openWorldHint=true). The description adds valuable behavioral context beyond that: it consumes detect quota, shares a quota source with the Web interface, and returns red/yellow/green summaries with per-claim status, confidence, reasons, sources, and citations. It does not explain why the operation is non-idempotent, so it stops short of a 5.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a compact, front-loaded paragraph that moves purposefully from purpose to process to outputs to cost. No sentence is wasted, and the arrow notation makes the pipeline easy to scan.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the rich annotations and the presence of an output schema, the description is nearly complete: it covers purpose, process, output summary, and quota cost. The only notable gap is any guidance on choosing this tool over its siblings, which keeps it from a 5.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already documents all five parameters and their enums. The description adds no parameter-specific meaning (e.g., it never explains model, speed, domain, or strict), so the baseline of 3 for high schema coverage is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb and resource: per-claim hallucination verification of input text, including the extraction and verification pipeline. It does not mention or differentiate from siblings (check_safety, verify_agent, etc.), so it cannot score a 5 under the rubric.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies the use case (verifying claims in text for hallucinations) and notes a cost constraint ('耗 detect 额度'), but it gives no explicit when-to-use, when-not-to-use, or alternatives to sibling tools like check_safety or verify_agent. This is implied usage only.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Tool Schema Changelog
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
2 tool updates
- Changed
verify_agent1 field changed- changed
Output schema / properties / main / anyOfPrevious value: -[ - { - "additionalProperties": {}, - "properties": { - "claims": { - "anyOf": [ - { - "items": {}, - "type": "array" - }, - { - "type": "null" - } - ] - }, - "input": { - "type": [ - "string", - "null" - ] - }, - "summary": { - "type": [ - "string", - "null" - ] - } - }, - "type": "object" - }, - { - "type": "null" - } -]New value: +[ + { + "additionalProperties": {}, + "properties": { + "claims": { + "anyOf": [ + { + "items": {}, + "type": "array" + }, + { + "type": "null" + } + ] + }, + "input": { + "type": [ + "string", + "null" + ] + }, + "summary": { + "anyOf": [ + { + "additionalProperties": {}, + "properties": { + "green": { + "anyOf": [ + { + "maximum": 9007199254740991, + "minimum": -9007199254740991, + "type": "integer" + }, + { + "type": "null" + } + ] + }, + "hallucination_risk": { + "type": [ + "number", + "null" + ] + }, + "red": { + "anyOf": [ + { + "maximum": 9007199254740991, + "minimum": -9007199254740991, + "type": "integer" + }, + { + "type": "null" + } + ] + }, + "total": { + "anyOf": [ + { + "maximum": 9007199254740991, + "minimum": -9007199254740991, + "type": "integer" + }, + { + "type": "null" + } + ] + }, + "yellow": { + "anyOf": [ + { + "maximum": 9007199254740991, + "minimum": -9007199254740991, + "type": "integer" + }, + { + "type": "null" + } + ] + } + }, + "type": "object" + }, + { + "type": "null" + } + ] + } + }, + "type": "object" + }, + { + "type": "null" + } +]
- Changed
verify_text2 fields changed- added
Output schema / properties / summary / anyOfAdded value: +[ + { + "additionalProperties": {}, + "properties": { + "green": { + "anyOf": [ + { + "maximum": 9007199254740991, + "minimum": -9007199254740991, + "type": "integer" + }, + { + "type": "null" + } + ] + }, + "hallucination_risk": { + "type": [ + "number", + "null" + ] + }, + "red": { + "anyOf": [ + { + "maximum": 9007199254740991, + "minimum": -9007199254740991, + "type": "integer" + }, + { + "type": "null" + } + ] + }, + "total": { + "anyOf": [ + { + "maximum": 9007199254740991, + "minimum": -9007199254740991, + "type": "integer" + }, + { + "type": "null" + } + ] + }, + "yellow": { + "anyOf": [ + { + "maximum": 9007199254740991, + "minimum": -9007199254740991, + "type": "integer" + }, + { + "type": "null" + } + ] + } + }, + "type": "object" + }, + { + "type": "null" + } +] - removed
Output schema / properties / summary / typeRemoved value: -[ - "string", - "null" -]
5 tool updates
- Changed
check_cua_actions1 field changed- changed
Output schema / (root)Previous value: -nullNew value: +{ + "$schema": "http://json-schema.org/draft-07/schema#", + "additionalProperties": {}, + "properties": { + "chain_trace": { + "anyOf": [ + {}, + { + "type": "null" + } + ] + }, + "chains": { + "anyOf": [ + { + "items": {}, + "type": "array" + }, + { + "type": "null" + } + ] + }, + "disclaimer": { + "type": [ + "string", + "null" + ] + }, + "has_propagation": { + "type": [ + "boolean", + "null" + ] + }, + "injection_steps": { + "anyOf": [ + { + "maximum": 9007199254740991, + "minimum": -9007199254740991, + "type": "integer" + }, + { + "type": "null" + } + ] + }, + "results": { + "anyOf": [ + { + "items": { + "additionalProperties": {}, + "properties": { + "action": { + "anyOf": [ + { + "additionalProperties": {}, + "propertyNames": { + "type": "string" + }, + "type": "object" + }, + { + "type": "null" + } + ] + }, + "level": { + "anyOf": [ + { + "enum": [ + "L0", + "L1", + "L2", + "L3" + ], + "type": "string" + }, + { + "type": "null" + } + ] + }, + "matched_rules": { + "anyOf": [ + { + "items": {}, + "type": "array" + }, + { + "type": "null" + } + ] + }, + "outcome": { + "type": [ + "string", + "null" + ] + }, + "reasons": { + "anyOf": [ + { + "items": { + "type": "string" + }, + "type": "array" + }, + { + "type": "null" + } + ] + }, + "step": { + "anyOf": [ + { + "maximum": 9007199254740991, + "minimum": -9007199254740991, + "type": "integer" + }, + { + "type": "null" + } + ] + }, + "verdict": { + "type": [ + "string", + "null" + ] + } + }, + "type": "object" + }, + "type": "array" + }, + { + "type": "null" + } + ] + }, + "ruleset_version": { + "type": [ + "string", + "null" + ] + }, + "session_id": { + "type": [ + "string", + "null" + ] + }, + "summary": { + "anyOf": [ + { + "additionalProperties": {}, + "properties": { + "L0": { + "anyOf": [ + { + "maximum": 9007199254740991, + "minimum": -9007199254740991, + "type": "integer" + }, + { + "type": "null" + } + ] + }, + "L1": { + "anyOf": [ + { + "maximum": 9007199254740991, + "minimum": -9007199254740991, + "type": "integer" + }, + { + "type": "null" + } + ] + }, + "L2": { + "anyOf": [ + { + "maximum": 9007199254740991, + "minimum": -9007199254740991, + "type": "integer" + }, + { + "type": "null" + } + ] + }, + "L3": { + "anyOf": [ + { + "maximum": 9007199254740991, + "minimum": -9007199254740991, + "type": "integer" + }, + { + "type": "null" + } + ] + }, + "blocked": { + "anyOf": [ + { + "maximum": 9007199254740991, + "minimum": -9007199254740991, + "type": "integer" + }, + { + "type": "null" + } + ] + }, + "confirm": { + "anyOf": [ + { + "maximum": 9007199254740991, + "minimum": -9007199254740991, + "type": "integer" + }, + { + "type": "null" + } + ] + }, + "takeover": { + "anyOf": [ + { + "maximum": 9007199254740991, + "minimum": -9007199254740991, + "type": "integer" + }, + { + "type": "null" + } + ] + }, + "total": { + "anyOf": [ + { + "maximum": 9007199254740991, + "minimum": -9007199254740991, + "type": "integer" + }, + { + "type": "null" + } + ] + } + }, + "type": "object" + }, + { + "type": "null" + } + ] + }, + "warning": { + "type": [ + "string", + "null" + ] + } + }, + "type": "object" +}
- Changed
check_cua_code_audit1 field changed- changed
Output schema / (root)Previous value: -nullNew value: +{ + "$schema": "http://json-schema.org/draft-07/schema#", + "additionalProperties": {}, + "properties": { + "disclaimer": { + "type": [ + "string", + "null" + ] + }, + "findings": { + "anyOf": [ + { + "items": { + "additionalProperties": {}, + "properties": { + "category": { + "type": [ + "string", + "null" + ] + }, + "detail": { + "type": [ + "string", + "null" + ] + }, + "file": { + "type": [ + "string", + "null" + ] + }, + "line": { + "anyOf": [ + { + "maximum": 9007199254740991, + "minimum": -9007199254740991, + "type": "integer" + }, + { + "type": "null" + } + ] + }, + "raw": { + "type": [ + "string", + "null" + ] + }, + "severity": { + "anyOf": [ + { + "enum": [ + "high", + "medium", + "low" + ], + "type": "string" + }, + { + "type": "null" + } + ] + } + }, + "type": "object" + }, + "type": "array" + }, + { + "type": "null" + } + ] + }, + "privacy_note": { + "type": [ + "string", + "null" + ] + }, + "ruleset_version": { + "type": [ + "string", + "null" + ] + }, + "summary": { + "anyOf": [ + { + "additionalProperties": {}, + "properties": { + "by_category": { + "anyOf": [ + { + "additionalProperties": {}, + "propertyNames": { + "type": "string" + }, + "type": "object" + }, + { + "type": "null" + } + ] + }, + "by_severity": { + "anyOf": [ + { + "additionalProperties": {}, + "propertyNames": { + "type": "string" + }, + "type": "object" + }, + { + "type": "null" + } + ] + }, + "capability_level": { + "type": [ + "string", + "null" + ] + }, + "dangerous_import_count": { + "anyOf": [ + { + "maximum": 9007199254740991, + "minimum": -9007199254740991, + "type": "integer" + }, + { + "type": "null" + } + ] + }, + "injection_surface_count": { + "anyOf": [ + { + "maximum": 9007199254740991, + "minimum": -9007199254740991, + "type": "integer" + }, + { + "type": "null" + } + ] + }, + "tool_count": { + "anyOf": [ + { + "maximum": 9007199254740991, + "minimum": -9007199254740991, + "type": "integer" + }, + { + "type": "null" + } + ] + }, + "total": { + "anyOf": [ + { + "maximum": 9007199254740991, + "minimum": -9007199254740991, + "type": "integer" + }, + { + "type": "null" + } + ] + } + }, + "type": "object" + }, + { + "type": "null" + } + ] + } + }, + "type": "object" +}
- Changed
check_safety1 field changed- changed
Output schema / (root)Previous value: -nullNew value: +{ + "$schema": "http://json-schema.org/draft-07/schema#", + "additionalProperties": {}, + "properties": { + "detection_id": { + "anyOf": [ + { + "maximum": 9007199254740991, + "minimum": -9007199254740991, + "type": "integer" + }, + { + "type": "null" + } + ] + }, + "hallucination": { + "anyOf": [ + {}, + { + "type": "null" + } + ] + }, + "harmful_detected": { + "type": [ + "boolean", + "null" + ] + }, + "injection_detected": { + "type": [ + "boolean", + "null" + ] + }, + "jailbreak_detected": { + "type": [ + "boolean", + "null" + ] + }, + "llm_analysis": { + "anyOf": [ + {}, + { + "type": "null" + } + ] + }, + "passed": { + "type": [ + "boolean", + "null" + ] + }, + "quota": { + "anyOf": [ + { + "additionalProperties": {}, + "propertyNames": { + "type": "string" + }, + "type": "object" + }, + { + "type": "null" + } + ] + }, + "risk_level": { + "type": [ + "string", + "null" + ] + }, + "risk_score": { + "type": [ + "number", + "null" + ] + }, + "summary": { + "type": [ + "string", + "null" + ] + }, + "threats": { + "anyOf": [ + { + "items": { + "additionalProperties": {}, + "properties": { + "category": { + "type": [ + "string", + "null" + ] + }, + "category_name": { + "type": [ + "string", + "null" + ] + }, + "match_context": { + "type": [ + "string", + "null" + ] + }, + "recommendation": { + "type": [ + "string", + "null" + ] + }, + "severity": { + "type": [ + "string", + "null" + ] + } + }, + "type": "object" + }, + "type": "array" + }, + { + "type": "null" + } + ] + } + }, + "type": "object" +}
- Changed
verify_agent1 field changed- changed
Output schema / (root)Previous value: -nullNew value: +{ + "$schema": "http://json-schema.org/draft-07/schema#", + "additionalProperties": {}, + "properties": { + "agent_eval": { + "anyOf": [ + { + "additionalProperties": {}, + "propertyNames": { + "type": "string" + }, + "type": "object" + }, + { + "type": "null" + } + ] + }, + "detection_id": { + "anyOf": [ + { + "maximum": 9007199254740991, + "minimum": -9007199254740991, + "type": "integer" + }, + { + "type": "null" + } + ] + }, + "main": { + "anyOf": [ + { + "additionalProperties": {}, + "properties": { + "claims": { + "anyOf": [ + { + "items": {}, + "type": "array" + }, + { + "type": "null" + } + ] + }, + "input": { + "type": [ + "string", + "null" + ] + }, + "summary": { + "type": [ + "string", + "null" + ] + } + }, + "type": "object" + }, + { + "type": "null" + } + ] + }, + "quota": { + "anyOf": [ + { + "additionalProperties": {}, + "propertyNames": { + "type": "string" + }, + "type": "object" + }, + { + "type": "null" + } + ] + }, + "steps": { + "anyOf": [ + { + "items": { + "anyOf": [ + { + "additionalProperties": {}, + "propertyNames": { + "type": "string" + }, + "type": "object" + }, + { + "type": "null" + } + ] + }, + "type": "array" + }, + { + "type": "null" + } + ] + } + }, + "type": "object" +}
- Changed
verify_text1 field changed- changed
Output schema / (root)Previous value: -nullNew value: +{ + "$schema": "http://json-schema.org/draft-07/schema#", + "additionalProperties": {}, + "properties": { + "citations": { + "anyOf": [ + { + "items": {}, + "type": "array" + }, + { + "type": "null" + } + ] + }, + "claims": { + "anyOf": [ + { + "items": {}, + "type": "array" + }, + { + "type": "null" + } + ] + }, + "detection_id": { + "anyOf": [ + { + "maximum": 9007199254740991, + "minimum": -9007199254740991, + "type": "integer" + }, + { + "type": "null" + } + ] + }, + "domain": { + "type": [ + "string", + "null" + ] + }, + "elapsed_ms": { + "type": [ + "number", + "null" + ] + }, + "input": { + "type": [ + "string", + "null" + ] + }, + "math_issues": { + "anyOf": [ + { + "items": {}, + "type": "array" + }, + { + "type": "null" + } + ] + }, + "quota": { + "anyOf": [ + { + "additionalProperties": {}, + "propertyNames": { + "type": "string" + }, + "type": "object" + }, + { + "type": "null" + } + ] + }, + "speed": { + "type": [ + "string", + "null" + ] + }, + "strict": { + "type": [ + "boolean", + "null" + ] + }, + "summary": { + "type": [ + "string", + "null" + ] + } + }, + "type": "object" +}
5 tool updates
- First observed
check_cua_actions - First observed
check_cua_code_audit - First observed
check_safety - First observed
verify_agent - First observed
verify_text
Publisher details
- Operator
- Shenzhen Lianshi Technology Co., Ltd. · Publisher source
- Operator website
- https://aihcc.cloud/
- Vendor relationship
- First-party · Publisher source
- Documentation
- https://aihcc.cloud/docs
- Trust center
- https://aihcc.cloud/
- Restrictions
- need provide OAuth key
Related MCP Connectors
Independent fact-checking for AI answers: a verdict and sources for every claim.
Free fact-checks, papers, source vetting, plus verified AI pricing, comparisons, guides, and tools.
Fact-checks generated content against your sources of truth showing what to trust, change, & verify.
Fact-check AI answers with cited sources. Pay per call in USDC on Base via x402.
Related MCP Servers
Arkheia Hallucinationofficial
AlicenseNot gradedqualityDmaintenanceDetect fabrication and hallucination in any LLM output. Score responses from GPT-4o, Claude, Gemini, Llama and 30+ models. Free tier included.2MIT- AlicenseNot gradedqualityBmaintenanceEnables per-claim citation verification for AI-generated text by fetching cited sources and judging whether they support the claim, with verdicts and evidence quotes.31 npmMIT
- AlicenseAqualityBmaintenanceAn independent review layer for AI-generated text: a 10-lens gate run by a separate model over output it did not write, returning the flagged line and the reason for each check rather than a single opaque verdict. A check that cannot complete reports unknown instead of a pass; lens_health needs no API key.98 npmMIT
Try in Browser
One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd
Glama MCP Gateway
Add one secure layer between your agents and this server.