Loading ToolBench
一条命令，让微信连上 AI — Bridge WeChat to any AI (Claude Code, OpenAI, Anthropic, Ollama, etc.)
This MCP server has severe definition quality issues across all dimensions. Tool naming uses agent class prefixes rather than action verbs (e.g., 'AnthropicAgent.ask' instead of 'send_message'). Descriptions are present but generic and lack actionable context for LLM selection. Critically, input schemas are incomplete, parameters lack type information (onChunk is typed as 'function' which is not a valid JSON Schema type), and the images array parameter in vision tools lacks itemSchema definition. No output schemas are documented, making it impossible for agents to understand what these tools return. Parameter descriptions are minimal (typically 1-2 sentences) and do not explain dependencies, constraints, or recovery paths. Error handling is not visible in the source. Tool composition is poor: multiple near-identical tools (ask, askStream, askWithImages) for each agent backend should be consolidated. The server appears designed for WeChat integration rather than as a general-purpose MCP tool set.
Send a message to Anthropic Claude API and receive a reply with conversation history management
Send a message to Anthropic Claude API with streaming response
Send a message with image attachments to Anthropic Claude API
Send a message to Claude Code CLI and receive a reply
Send a message to Claude Code CLI with streaming response
Send a message with image attachments to Claude Code CLI
Send a message to Codex CLI (OpenAI coding agent) and receive a reply
Send a message to an arbitrary shell command and return stdout
Tool names use class.method notation (AnthropicAgent.ask) instead of action verbs (send_message, ask_anthropic). Naming convention violates pattern:tool and prevents LLMs from inferring intent from names alone. Names do not clarify distinctions between identical ask/askStream/askWithImages variants.
Input schemas are incomplete. The 'onChunk' parameter is typed as 'function', which is not a valid JSON Schema type. The 'images' array parameter in vision tools lacks itemSchema definition (should specify type: object with properties for mimeType and base64). Parameters lack minLength, maxLength, pattern, or enum constraints.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-23 | F | 29 | 2026-07-28+ | v2 |
Send a message to Gemini CLI and receive a reply with session management
Send a message to Gemini CLI with streaming response
Send a message to Ollama local LLM and receive a reply with conversation history management
Send a message to Ollama local LLM with streaming response
Send a message to OpenAI API (or OpenAI-compatible API) and receive a reply with conversation history management
Send a message to OpenAI API with streaming response
Send a message with image attachments to OpenAI API
No output schemas documented. It is impossible for agents to understand what these tools return (response structure, field names, types). This violates pattern:tool and pattern:tool-description. Agents cannot plan downstream tool calls without knowing output structure.
Descriptions are generic and do not explain when to use each tool variant. 'Send a message to Anthropic Claude API and receive a reply with conversation history management' does not distinguish why an LLM should choose ask vs askStream vs askWithImages. Descriptions lack dependency hints, recovery guidance, or actionable context per pattern:tool-description baseline (10-1024 chars, optimized for LLM reasoning).
Parameter descriptions are minimal. 'userId' is described only as 'Unique identifier for the user conversation' without explaining if it is an email, username, numeric ID, or arbitrary string. 'message' lacks guidance on max length, format (plain text vs markdown), or special handling. Vision tool images parameter lacks schema for inner object structure.
Poor tool composition. Fifteen tools are defined, but they collapse into three variants (ask, askStream, askWithImages) repeated across five agent backends (Anthropic, ClaudeCode, Codex, Gemini, Ollama, OpenAI). This should be consolidated into generic send_message, send_message_stream, send_message_with_images tools that accept a backend/agent parameter, OR offer separate canonical tools like anthropic_send_message, openai_send_message with consistent naming. Current structure forces agents to reason about which backend to use and then multiply by three variants.
No error handling documentation. It is unknown what errors these tools return (network failure, API error, invalid input, rate limit, etc.), how agents should recover, or what guidance is provided. Pattern:recovery-guide and pattern:error-classification require categorizing errors as retryable, user-fixable, or fatal.
CommandAgent.ask is marked IRREVERSIBLE but lacks a confirmation/dry-run mechanism. Executing arbitrary shell commands via agent calls is a severe security risk. Pattern:confirmation-request requires that destructive operations support a dry-run or confirmation step to prevent catastrophic errors.
No tool annotations present (readOnlyHint, destructiveHint, idempotentHint). CommandAgent.ask is marked IRREVERSIBLE in the metadata but this is not exposed via tool annotations. Vision tools (askWithImages) are not marked as read-only. Agents cannot reason about safety without explicit annotations.