Skip to main content
Glama
Sign In

HallucC — Hallucination & Safety Guardian

by io.github.fredyee
OverviewDiscussionsAdmin

Agent Ice Wall (Session Fuse)

check_agent_ice_wall

智能体冰墙（童锁/保险丝）：agent 每执行一步前调用一次，做单步幻觉护栏 + 会话级风险累积熔断。响应的 action 字段是唯一需要看的：allow/warn 放行、block 本步拦截、frozen=整场立即停机（风险累积超阈值或命中捏造工具等零容忍项，冻结期间任何动作都不应执行）。熔断条件：block=3分/warn=1分累积 ≥10、连续 3 次 block、或一次命中捏造工具/参数 Schema 违规；冷却 5 分钟自动解冻，或用户手动 reset。session_id 由你在整个 agent 任务内自定复用（状态在云端账号下，本地零安装零存储）。传入 tool_schemas 工具注册表可启用捏造工具/参数校验（强烈建议）。耗额度。与 check_cua_actions（CUA 桌面动作分级）正交：本工具管 LLM agent 的幻觉失控。

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "session_id": "<session_id>",
      "step": "<step>"
    },
    "name": "check_agent_ice_wall"
  }
}

Input Schema

NameRequiredDescriptionDefault
stepYes当前步（两种 schema 均兼容，服务端自动归一）
taskNo原始任务指令（参数来源校验用）
session_idYes会话 ID（由调用方自定并在整个 agent 会话内复用）：风险分按 session 累积，超阈值整场冻结。同一 agent 任务务必用同一个 ID，不同任务不要复用。
prior_stepsNo前序步（同 schema），供循环/重试风暴等跨步检测
tool_schemasNo工具注册表 {工具名: {required, properties}}；给了才启用捏造工具/参数 Schema 校验（这两项是零容忍熔断项）

Output Schema

NameRequiredDescriptionDefault
stepNo
quotaNo
actionNo客户端唯一需要看的字段：frozen=整场立即停机
sessionNo

Schema Changelog

Changes observed during successful MCP inspections.

  1. Added

TDQS

A4.6/5.0
Behavior5/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

The description goes well beyond annotations: it discloses scoring (block=3, warn=1), the freezing semantics (nothing may execute while frozen), the auto-unfreeze window, the reset path, and that calls consume credits (耗额度). It also explains where state lives (in the cloud under the account, with nothing stored locally), which explains why readOnlyHint=false even though the tool is a guard.

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?

It is one dense paragraph, but it is front-loaded correctly: purpose first, then the single response field that matters (action), then the fuse rules and operational notes. Minor cost: threshold numbers and session bookkeeping are packed into a single block rather than separated into their own segments.

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, the description still explains which response field is the only one to read and what each value means, including frozen meaning stop everything. It also covers state lifetime and quota, so an agent can call this correctly without extra context.

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%, and the description's parameter content (session_id reuse across one task, tool_schemas enabling the fabricated-tool check) largely restates what the schema descriptions already say. It does add urgency via 强烈建议 for tool_schemas, but it adds no field-level meaning beyond the schema, so the baseline 3 applies.

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?

The description names a specific mechanism: a per-step hallucination guard plus a session-level risk fuse. It immediately separates itself from the sibling tool by scoping the guard to LLM agent hallucination control, and it states that check_cua_actions covers CUA desktop action grading instead.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines5/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

It says explicitly to call this tool once before every agent step, and it tells the agent when the fuse fires (score ≥10, three consecutive blocks, or one fabricated-tool/schema violation) versus when the session recovers (5-minute cooldown or manual reset). It also tells the agent where not to use it, by naming check_cua_actions as the orthogonal tool for desktop actions.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

All HallucC — Hallucination & Safety Guardian toolsInspect
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.

Resources