Loading ToolBench
An MCP server for managing WeChat Official Account (OA) operations, including access token management, draft creation/publication, and material management
WeChat OA MCP Server has critical definition quality issues that prevent reliable LLM usage. Tool names lack action verbs and are inconsistently formatted (WeChat_get_access_token vs WeChat_del_draft). Descriptions are present but generic, often simply restating what the API does without explaining when/why to use the tool or what it returns. Parameter descriptions lack detail on format constraints, enums, or validation rules. Output schemas are entirely missing, tools return raw JSON strings without documented field structure. Error handling is minimal, with only generic error messages. Security concerns include exposure of access_token as a required parameter (should be server-side injected) and destructive operations without confirmation patterns. The five tools fall into two categories: token management and content manipulation, but lack the composition guidance needed for LLMs to chain them effectively.
创建微信公众号草稿
删除微信公众号草稿
删除微信公众号永久素材
获取微信公众号access_token
发布微信公众号草稿
Tool naming violates verb-noun convention. Names like 'WeChat_get_access_token', 'WeChat_del_draft', and 'WeChat_del_material' use non-standard abbreviations ('del' instead of 'delete') and inconsistent prefixes. LLMs struggle to infer tool purpose from abbreviated names. Should follow pattern: 'delete_draft', 'delete_material', 'get_access_token' (drop redundant 'WeChat_' prefix or use consistently as namespace).
access_token is exposed as a required tool parameter in all four content/publication tools (WeChat_create_draft, WeChat_publish_draft, WeChat_del_draft, WeChat_del_material). This violates the secret-injection pattern, tokens should never appear in tool parameters, as they are logged in traces and prompt history. Solution: inject access_token server-side via environment/vault; remove from tool signatures.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | F | 39 | 2026-07-28+ | v2 |
| 2026-03-09 | F | 31 | - | v1 |
Output schemas are not documented. Tools return formatted JSON strings (e.g., '{"success": true, "access_token": "..."}') but nowhere in the handler code or tool definitions are the field names, types, or presence guarantees documented. LLMs cannot parse response fields reliably or chain tools. Example from HandleGetAccessToken: response format is hardcoded as a string but no schema maps 'access_token', 'expires_in', 'error' fields.
Destructive operations (WeChat_del_draft, WeChat_del_material) lack confirmation/dry-run support. No pattern prevents accidental permanent deletion. Per Agentic Tool Patterns (pattern:confirmation-request), irreversible operations should support a confirmation step or require explicit intent signals to avoid agent mistakes.
Parameter descriptions lack format/constraint details. Example: 'content' parameter in WeChat_create_draft says 'must be less than 2万 characters' but uses Chinese numeral and provides no guidance on encoding, HTML validation, or behavior on truncation. 'image_url' accepts a URL but does not specify: required format (http/https only?), max size, supported types, or retry behavior on network errors. Per pattern:constrained-input, constraints must be explicit and parseable.
Tool descriptions are generic and do not explain WHEN to use each tool or dependencies between them. Examples: WeChat_create_draft describes 'creates a draft' but does not state that image_url must be uploaded first, or what happens if the image fails to fetch. WeChat_publish_draft does not explain the relationship to WeChat_create_draft or whether a draft can be published multiple times. Per pattern:tool-description, descriptions must include prerequisites and relationships.
Error handling is minimal and non-actionable. All tools return generic error messages: 'WeChat API failed: <err>' with no guidance on recovery. Example from HandleDeleteDraft: if deletion fails, the LLM receives only 'delete failed' with no context on whether to retry, whether the draft was already deleted, or whether permissions are missing. Per pattern:recovery-guide, errors must categorize as retryable/user-fixable/fatal and suggest next steps.
No permission gates or scope declarations. Tools that delete content (WeChat_del_draft, WeChat_del_material) do not verify caller permissions before executing. No audit trail or scope metadata (e.g., 'requires:write:material') is declared. Per pattern:scope-declaration and pattern:permission-gate, tools must declare required permissions and enforce least-privilege checks.
Composition and chaining guidance missing. The five tools implement a workflow (get token → create draft → publish), but no tool description explains the required sequence or which outputs must feed into which inputs. Example: WeChat_publish_draft requires 'draft_media_id' from WeChat_create_draft, but this dependency is not documented. Per pattern:tool-chain, tool outputs must explicitly include IDs needed by dependent tools, and descriptions must hint at sequencing.