Click on "Deploy Server".
Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state.
In the chat, type @ followed by the MCP server name and your instructions, e.g., "@Chinese Sensitive Words MCP Server Check this text for sensitive words: 加微信13812345678"
That's it! The server will respond to your query, and you can continue using it as needed.
Here is a step-by-step guide with screenshots.
English | 中文
中文敏感词/违禁词检测 MCP Server，支持小红书、抖音、快手、B站等平台。
海量词库，日日更新 — 覆盖政治、色情、暴力、赌博、毒品、广告法极限词、医疗功效词等
多平台支持 — 小红书、抖音、快手、B站专属词库
风险等级分类 — 高危（封号）/ 中危（限流）/ 低危（建议修改）/ 提示
替换建议 — 不只检测，还推荐安全替代词
谐音变体检测 — 识别 "薇信→微信"、"℡→电话" 等变体
跳字检测 — 识别 "加 微 信"、"最.好.的" 等干扰字符
手机号/URL 检测 — 自动识别联系方式和外链
NER 智能过滤 — 减少地名、人名、机构名误报
Related MCP server: sensitive-lexicon-mcp
Tool | 功能 | 适用场景 |
| 检测文本中的敏感词/违禁词 | 检查文案、产品描述、直播话术是否合规 |
| 获取敏感词的安全替换建议 | 修改被标记的违禁词 |
在配置文件中添加：
{
"mcpServers": {
"chinese-sensitive-words": {
"command": "npx",
"args": ["-y", "chinese-sensitive-words-mcp"]
}
}
}claude mcp add chinese-sensitive-words -- npx -y chinese-sensitive-words-mcpnpx mcporter config add chinese-sensitive-words-mcp --stdio "npx -y chinese-sensitive-words-mcp"用户对 AI 说：
"帮我检查这段小红书文案有没有违禁词：这是全网最好用的美白产品，效果立竿见影，加微信13812345678领优惠"
AI 调用 check_sensitive_words 返回：
⚠️ Detected 4 sensitive word(s):
Risk summary: 🔴 High=1 | 🟡 Medium=2 | 🔵 Low=1
🔴 HIGH RISK (may cause account ban)
- "13812345678" — Category: 手机号
🟡 MEDIUM RISK (may cause content throttling)
- "最好用" — Category: 广告法极限词 → Suggested replacements: 很好用, 超好用
- "美白" — Category: 医疗功效 → Suggested replacements: 提亮, 焕亮
🔵 LOW RISK (recommend modification)
- "加微信" — Category: 引流 → Suggested replacements: 私信咨询用户对 AI 说：
"最好用 这个词应该换成什么？"
AI 调用 get_word_suggestions(keyword="最好用") 返回：
"最好用" (极限词替换)
Suggested replacements: 很好用, 超好用, 非常好用, 特别好用输入：
我们的产品是第一好，请留下你的薇信
API 返回：
{
"code": "0",
"msg": "检测成功",
"data": {
"wordCount": 2,
"wordList": [
{
"keyword": "第一",
"category": "sl-compare-add",
"level": "低",
"suggestion": ["领先", "优秀", "出色", "很棒"],
"startIndex": 6,
"endIndex": 7
},
{
"keyword": "薇信",
"category": "特殊符号引流",
"level": "低",
"suggestion": null,
"startIndex": 15,
"endIndex": 16
}
],
"stats": { "high": 0, "mid": 0, "low": 2, "tip": 0 },
"hasSensitive": true,
"hasHighRisk": false
}
}检测结果：
违禁词 | 类别 | 说明 | 建议替换 |
第一 | 极限比较词 | 违反广告法，属于绝对化用语 | 领先、优秀、出色、很棒 |
薇信 | 特殊符号引流 | 用谐音字规避"微信"，平台仍能识别 | 删除，改为"私信我" |
修改建议：
我们的产品非常出色，私信我了解更多
类型 | 额度 | 说明 |
免费（无 TOKEN） | 100 次/天 | 开箱即用，无需注册 |
注册用户（有 TOKEN） | 无限制 | 配置 WORDSCHECK_ACCESS_TOKEN |
{
"mcpServers": {
"chinese-sensitive-words": {
"command": "npx",
"args": ["-y", "chinese-sensitive-words-mcp"]
}
}
}{
"mcpServers": {
"chinese-sensitive-words": {
"command": "npx",
"args": ["-y", "chinese-sensitive-words-mcp"],
"env": {
"WORDSCHECK_ACCESS_TOKEN": "your_token_here"
}
}
}
}{
"mcpServers": {
"chinese-sensitive-words": {
"command": "npx",
"args": ["-y", "chinese-sensitive-words-mcp"],
"env": {
"WORDSCHECK_API_BASE": "https://your-server.com/api",
"WORDSCHECK_ACCESS_TOKEN": "your_token_here"
}
}
}
}平台 | 词库内容 |
通用 | 政治、色情、暴力、赌博、毒品、违法 |
小红书 | 广告法极限词、医疗功效、虚假宣传、焦虑营销、品牌词 |
抖音 | 直播违禁词、引流词、夸大宣传 |
快手 | 社区规范违禁词 |
B站 | 社区规范、内容审核词 |
等级 | 影响 | 示例 |
🔴 高危 | 可能导致封号/删帖 | 政治敏感、色情、暴力、手机号 |
🟡 中危 | 可能导致限流/降权 | 广告法极限词、医疗功效、虚假宣传 |
🔵 低危 | 建议修改 | 引流词、促销词 |
💡 提示 | 注意措辞 | 焦虑营销、容貌身材相关 |
欢迎提交 Issue 和 Pull Request！详见 CONTRIBUTING.md。
微信：chenganp
💡 需要定制开发自己的 MCP Server？查看我们的 MCP 定制开发服务
Detect sensitive/prohibited words in Chinese text for social media platforms (Xiaohongshu, Douyin, Kuaishou, Bilibili). Returns risk level (high/medium/low/tip), word category, position, and safe replacement suggestions. Free tier: 100 requests/day without token. Set WORDSCHECK_ACCESS_TOKEN for unlimited access. Max 3000 characters per request. Use this tool when users need to check marketing copy, product descriptions, live-streaming scripts, or social media posts for compliance.
| Name | Required | Description | Default |
|---|---|---|---|
| text | Yes | Chinese text to check for sensitive words. Supports marketing copy, product descriptions, social media posts, live-streaming scripts. Max 3000 chars. | |
| ner | No | Enable NER (Named Entity Recognition) filtering to reduce false positives on place names, person names, and organizations. Default: true. Set false for stricter detection. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden. It discloses free tier limits (100 requests/day without token), authentication requirement (WORDSCHECK_ACCESS_TOKEN for unlimited), max character length (3000), and return information (risk level, category, position, suggestions). Missing details on error handling or rate limiting prevent a higher score.
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 concise (two sentences plus a note about limits) and well-structured: first sentence declares purpose and output, second sentence provides usage guidance. Every sentence adds value without redundancy.
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 description covers usage context, authentication, limits, and return values. However, it lacks explicit output format details (e.g., whether results are an array or object). Given no output schema, a slightly more structured specification would improve completeness.
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%, so the schema already documents both parameters. The description adds value by naming example content types for the 'text' parameter, but does not provide critical information beyond the schema. Baseline 3 is appropriate.
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's function: detecting sensitive words in Chinese text for specific social media platforms. It lists platforms (Xiaohongshu, Douyin, etc.) and typical use cases, effectively distinguishing it from the sibling tool 'get_word_suggestions' which likely provides suggestions rather than detection.
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 advises using the tool for checking marketing copy, product descriptions, live-streaming scripts, or social media posts, providing clear context. However, it does not specify when not to use it or mention alternative tools beyond the implied sibling.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get safe replacement suggestions for sensitive/prohibited Chinese words. Returns alternative words that convey similar meaning but comply with platform rules. Use this when users want to fix flagged words in their content. If keyword is provided, returns suggestions only for that word; otherwise returns the full suggestion library organized by category.
| Name | Required | Description | Default |
|---|---|---|---|
| keyword | No | Optional: specific sensitive word to get suggestions for (e.g., '最好', '美白'). If omitted, returns all available suggestions grouped by category. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Without annotations, the description explains behavior: returns suggestions for a specific keyword if provided, otherwise full library organized by category. No side effects or authorization details are needed for this read-only suggestion tool.
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 concise sentences, no redundant information. The purpose is front-loaded, and the behavior distinction is clearly stated. Every sentence 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?
Given the tool's simplicity (one optional parameter, no output schema), the description is fully adequate. It covers purpose, usage scenario, and behavior variants. No further details are necessary.
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?
The input schema describes the 'keyword' parameter, and the description adds meaningful context: specifying how the tool behaves with and without the parameter. With 100% schema coverage, the description enhances understanding 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?
The description explicitly states the tool's purpose: 'Get safe replacement suggestions for sensitive/prohibited Chinese words.' It specifies the resource and action, and distinguishes behavior based on keyword presence. Sibling tool 'check_sensitive_words' hints at a different function, reducing confusion.
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 provides clear usage guidance: 'Use this when users want to fix flagged words in their content.' This implies the tool should be used after detection. While it doesn't explicitly list when not to use it, the sibling tool name offers differentiation.
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.0.2check_sensitive_wordsget_word_suggestionsScored across 2 tools
The two tools have clearly distinct purposes: one detects sensitive words in text, the other provides replacement suggestions. No overlap in functionality.
Both tool names follow a consistent verb_noun pattern (check_sensitive_words, get_word_suggestions), making them predictable.
With two tools, the server covers the core workflow (detection and suggestion) for a specialized compliance checking domain. No unnecessary tools.
The server covers the primary needs but lacks a tool for quick single-word checking or batch processing. Minor gap for advanced use cases.
Audit creator scripts for TikTok Shop and Amazon policy violations. Returns flags and safe rewrites.
Chinese web novel MCP: 36 tools (outline, prose, review, coach, KD export). BYOK, no API key.
Search Chinese books with Douban ratings, AI book guides and curated toplists. Free, no API key.
Toxicity, sentiment, NER, PII detection, and language identification tools
