Loading ToolBench
MCP Server for Chinese sensitive/prohibited word detection. Supports Xiaohongshu, Douyin, Kuaishou, Bilibili. 中文敏感词违禁词检测 MCP 服务，支持小红书、抖音、快手、B站。
Server has two well-named tools with explicit schemas and descriptions. Both tools follow verb_noun naming convention (check_*, get_*) which is excellent. Descriptions are substantive (200+ chars each) and explain WHEN to use each tool. Input schemas are properly typed with zod and include constraints (maxLength, optional with defaults). However, output schemas are NOT documented, responses are formatted as markdown text rather than structured objects, making it difficult for LLMs to reliably extract and chain results. Error handling is present but generic ('Service error', 'Detection failed') with limited actionability. Parameters lack some nuance: the 'ner' parameter default and behavior are documented but the keyword search in get_word_suggestions lacks examples of actual keywords. No tool annotations (readOnlyHint, destructiveHint) present. Overall: solid naming and descriptions, but output structures and error guidance need improvement for production use.
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.
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.
Output schemas are not documented. Both tools return formatted markdown text in a 'content' array rather than structured JSON objects with typed fields. LLMs cannot reliably extract specific data (risk levels, word counts, suggestion lists) from unstructured text responses, forcing parsing and increasing hallucination risk.
Error responses are generic and non-actionable. 'Service error: <error message>' and 'Detection failed: <msg>' provide no recovery guidance. Per pattern:recovery-guide, errors should tell the LLM what to do next (e.g., 'Token limit exceeded. Reduce text length to <X> chars and retry.' or 'API unreachable. Verify WORDSCHECK_ACCESS_TOKEN is set correctly.').
No tool annotations (readOnlyHint, idempotentHint, destructiveHint). Both tools are read-only and idempotent, but this is not declared in the tool definitions. LLMs cannot infer safety properties and may unnecessarily hesitate to call these tools multiple times.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-23 | C | 68 | 2026-07-28+ | v2 |
get_word_suggestions keyword parameter lacks concrete examples. The description says 'e.g., 最好, 美白' but then immediately truncates the response. A complete example with actual keyword values would help LLMs understand the expected input format better.
The mandatory warning message ('⚠️ 重要提醒...') is hardcoded in every response, consuming tokens and diluting signal. This compliance notice should be returned once during server initialization or negotiation, not on every tool call.