Pre-scans text or outputs against a default or custom blocklist before automated approval. Blocks content on any match and returns the matched patterns for human or smaller-model review.
自动安全硬拦：对一段文本/产物按 blocklist(默认内建危险模式)预扫描。命中即 blocked → 不可自动放行,清单返回命中模式。用于自动审批前的把关; 小模型/人工兜底据此再判断。blocklist 可选传(字符串或正则)。
| Name | Required | Description | Default |
|---|---|---|---|
| content | Yes | 待扫描文本（呈现产物正文） | |
| blocklist | No | 可选自定义正则/子串黑名单,缺省用内建 |
Changes observed during successful MCP inspections.
v1.0.0Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full behavioral burdenMK. It discloses the hard-interception behavior, the 'hit means blocked and not auto-releasable' rule, and the return of a list of matched patterns. It could go further by stating the all-clear behavior or any side-effect-free guarantee, but the core behavior is transparent.
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 compact and front-loaded: it names the behavior first, then gives the hit rule, return value, and usage context in three sentences. Every sentence contributes directly to safe invocation.
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 two-parameter tool with no output schemaaintx, the description gives enough context: what is scanned, how the blocklist works, what happens on a hit, and when to use the tool. It does not explicitly describe the safe/no-hit outcome, but that is reasonably inferable from the conditional wording.
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 100% for both parameters, so the schema already documents content and blocklist well. The description adds only minor extra clarity by noting blocklist entries can be strings or regex, which mostly repeats the schema's '正则/子串' wording.
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 a specific verb and resource: it pre-scans text or artifacts against a blocklist and hard-blocks on hits. It conveys the safe-scanning purpose and the blocked/not-auto-release outcome, which helps distinguish it from generic tooling, though it does not explicitly name an alternative sibling.
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 when to use it: as a gate before automated approval, with output intended for small-model or human fallback judgment. It gives clear usage context but does not mention exclusions or name alternative scanning tools, so it falls just short of a 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.