中文内容合规检查：广告法违禁词 + AI 标识规则，逐条给出法条依据。Chinese content compliance: ad-law banned terms + AI labeling.
Scored across 2 tools
Both tools use the check_* verb but target clearly different compliance domains: AI-generated content labeling vs. advertising-law risk. An agent can distinguish them from the descriptions, though the shared 'check' framing and Chinese-only descriptions mean a non-Chinese-reading agent could momentarily hesitate about which to invoke first.
Both tools follow the same predictable verb_noun snake_case pattern (check_ai_label, check_content). No mixing of conventions or stray naming styles.
Two tools is very thin for a compliance-checking server, even one with a narrow niche. The AI-label tool explicitly defers its full judgment to a cloud version, so the exposed surface feels like a partial product rather than a well-scoped set.
The core detect-and-suggest loop exists for two rule families (AI labeling and ad-law terms), and check_content returns edit suggestions. However, there is no rule catalog, no batch/multi-segment check, no rewrite or re-verify tool, and the AI-label check is a free-tier stub, leaving notable gaps for real workflows.
检测内容中的 AI 生成/合成表述，并提示《人工智能生成合成内容标识办法》的标识要求。免费版只做表述检测；完整判定（显式标识 + 隐式元数据标识）在云端版。
| Name | Required | Description | Default |
|---|---|---|---|
| text | Yes | 要判断的内容 |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It usefully discloses a key behavioral limit: the free tier performs only expression detection while full determination (explicit labeling + implicit metadata labeling) requires the cloud version. It says nothing about result format, confidence, or accuracy, so it is only partially 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?
Two sentences, purpose front-loaded and the version limitation clearly appended. No filler and no repetition of the name. Slightly dense due to the regulatory citation but every clause carries information.
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?
No output schema and no annotations, so the description must fill the gap. It clarifies the free/cloud capability boundary, but never indicates what the detection result looks like (a verdict, a label suggestion, metadata?), leaving the agent guessing about the return value of a check 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?
Only one parameter, 'text', with 100% schema description coverage ('要判断的内容'). Per the rubric, a fully-covered schema sets the baseline at 3, and the description adds no syntax, format, or size guidance beyond it.
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?
States a specific verb and resource: detect AI-generated/synthetic expressions in content and flag labeling requirements under a named regulation. This is far more than a tautology. It does not, however, differentiate itself from the sibling check_content, so the agent cannot tell them apart from the description alone.
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 scopes what the free version will and won't do ('免费版只做表述检测；完整判定在云端版'), which implies when this tool is appropriate. But it gives no explicit when-to-use vs the sibling check_content and no exclusions or prerequisites beyond the version boundary.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
检查一段中文内容的广告法合规风险，返回逐条问题清单：问题类型 / 原文位置 / 命中文本 / 依据法条 / 修改建议。覆盖：绝对化用语（第9条）、医疗功效与疾病名（第17/18条）、保健功效、违规用语（免检/特供）、食品绝对化、虚假表述等高频规则。调用规则：同输入必同输出；未发现问题时明确说明，不虚报。限制：单次 2000 字符；本会话共 30 次。
| Name | Required | Description | Default |
|---|---|---|---|
| lang | No | Language of the rules to apply. 'auto' (default) picks zh if the text contains CJK characters, otherwise en. zh = China Advertising Law + AI-labeling rules; en = EU AI Act Art.50 + EU/US advertising, health, financial and green claims rules. | |
| text | Yes | Content to check (Chinese or English; max 2000 characters) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full load and does so well: it discloses determinism, false-positive policy, per-call character cap, session call budget, and the exact shape of the returned issue list. It omits auth/data-retention or whether input is stored, which is the remaining gap.
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?
Front-loaded with purpose and return format, then coverage, then usage rules and limits – a logical progression with dense but purposeful content. The middle enumeration of rule categories is slightly list-heavy but every clause carries operational information.
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?
There is no output schema, so the description correctly compensates by spelling out the逐条 issue-list fields and the no-issue case, plus throughput limits. Complete enough for an agent to call it correctly; only edge-case handling (oversized input, language mismatch) is left implicit.
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 the schema already documents both text and lang (including the auto-detection semantics and the zh vs en rule sets). The description's 2000-character note only echoes the schema, so baseline 3 is appropriate – it adds little parameter meaning beyond structured data.
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?
States a specific verb+resource (检查…广告法合规风险) and enumerates the concrete rule families it enforces (第9条绝对化用语、第17/18条医疗功效等). It does not, however, distinguish itself from the sibling check_ai_label, and it frames the scope as Chinese-only even though the schema's lang enum supports English/EU rules.
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?
Provides invocation behavior (同输入必同输出, explicit no-issue reporting, no false positives) and operational limits (2000 chars, 30 calls/session), which is useful. But it never says when to prefer this over check_ai_label or how the two relate, so the when-to-use dimension is only implied.
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.
check_content2 fields changedInput schema / properties / langAdded value: +{
+ "description": "Language of the rules to apply. 'auto' (default) picks zh if the text contains CJK characters, otherwise en. zh = China Advertising Law + AI-labeling rules; en = EU AI Act Art.50 + EU/US advertising, health, financial and green claims rules.",
+ "enum": [
+ "auto",
+ "zh",
+ "en"
+ ],
+ "type": "string"
+}Input schema / properties / text / descriptionPrevious value: -"要检查的中文内容（≤2000 字符）"New value: +"Content to check (Chinese or English; max 2000 characters)"check_ai_labelcheck_contentAI content compliance: ad-law prohibited words, AI labeling GB45438, EU AI Act Art50, SB1000
生成式AI备案、AI生成内容标识、深度合成、算法备案：条文级问答 + 按条号取法规原文 + 应办清单（中文）
中国 AI 客服国标 GB/T 47746—2026 合规知识库：条款级问答 + 全部 61 项达标自查清单（48 应 + 4 宜 + 9 可，含 5 项一票否决），答案标注条款依据。
Compliance lint for AI, scraping, and privacy law. Cited findings in 200 or more jurisdictions.
Add one secure layer between your agents and this server.