Loading ToolBench
Convert Markdown to WeChat-formatted articles with AI-powered enhancements, image generation, and draft creation
This MCP server exhibits severe definition quality gaps across nearly all 26 tools. While tool names follow verb_noun conventions (e.g., upload_image, convert, generate_image), the input schemas are either completely absent from the visible source code or cannot be verified from the provided Makefile, go.mod, and partial main.go excerpt. The source code shows only tool name declarations and descriptions in the sample; no JSON Schema definitions, parameter type information, or output schemas are visible in the provided code. Parameter descriptions exist (e.g., 'Path to the local image file' for upload_image) but are minimal (10-50 chars typically), falling short of the 50-200 char LLM-optimized range. Critical patterns are missing: no error handling guidance in descriptions, no recovery suggestions, no constraints on parameters (e.g., image formats, file size limits), no documentation of which operations are idempotent vs. destructive beyond a Risk label. Many tools lack context on dependencies (e.g., 'create_draft' expects JSON but no schema shown). The descriptions read as functional specifications rather than LLM-friendly prompts that guide tool selection and parameter inference.
Analyze an article and return deterministic enhancement advice
Manage Brand Profile for AI agents
List server capabilities and features
Manage md2wechat configuration
Convert Markdown article to WeChat format
Create WeChat draft article from JSON file
Create WeChat image post (infographic-style article)
Diagnose and troubleshoot md2wechat configuration and environment
No visible JSON Schema definitions for any of the 26 tools. Input parameter definitions show type and description fields in the summary, but the actual schema structures with proper JSON Schema type constraints, enum values, format specifiers, and pattern constraints are not provided in the source code excerpt. This violates the critical pattern requirement: 'Document the output schema. LLMs need to know what fields to expect so they can plan downstream tool calls and extract the right data.'
Inferred effective spec: <=2025-11-25.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-23 | F | 40 | <=2025-11-25 | v2 |
Download online image and upload to WeChat
Generate cover image for WeChat article
Generate image via AI and upload to WeChat
Generate infographic image for article
Improve article readability and tone using AI
Inspect and validate converted article structure
Manage and validate article layout modules
Preview article conversion result
List available AI prompts and templates
List available AI providers and models
List available skills and extensions
Synchronize configuration and data
Test and validate HTML article for WeChat
List available layout themes
Generate article title suggestions using AI
Upload local image to WeChat material library
Print CLI version
Write/generate article content using AI
Tool descriptions are minimal (10-50 characters typically) and lack LLM-optimized context. They do not answer: What does it do? When should the LLM call it instead of a similar tool? What does it return? For example, 'Upload local image to WeChat material library' (48 chars) does not specify: What image formats are supported? What is the size limit? Does it return a media_id? Does it fail if the image is corrupted? Is the operation idempotent? Example: advise describes 'Analyze an article and return deterministic enhancement advice' (56 chars), deterministic is good, but 'enhancement advice' is vague. Advice about what? Structure? Tone? SEO? This violates pattern:tool-description.
Parameter descriptions are present but insufficient. They name the field and its purpose in 1-2 sentences (e.g., 'Path to the local image file', 'URL of the online image to download') but do not include constraints, expected formats, or error conditions. LLMs cannot infer: Must file_path be absolute or relative? Are symlinks allowed? What image formats (PNG, JPEG, GIF, WebP)? Maximum file size? Timeout? This violates pattern:constrained-input and pattern:tool-description. Example: 'action' parameter in config tool has description 'Config action: init, show, validate, set' (41 chars) but is not declared as an enum with explicit values.
No error handling guidance in tool descriptions. LLMs have no instruction on recovery paths. Example: upload_image should tell the LLM 'If the file is not found, check the file_path. If the image format is unsupported, convert it to JPEG.' Instead, descriptions assume success. Tools like download_and_upload do not explain: What if the URL is invalid? What if the download times out? What if the image is too large? This violates pattern:recovery-guide.
No output schemas documented. Tools are listed with their input schemas but no return type is visible. Example: convert should return a WeChat-formatted article object with fields like media_id, title, content, created_at. Without documented output schemas, LLMs cannot chain tools effectively, they do not know which fields the next tool expects. This violates pattern:tool.
Tool 'download_and_upload' contains 'and' in its name, signaling multiple responsibilities (download + upload). This should be split into two tools: download_image and upload_image. An LLM can then compose them independently and handle partial failures. For example, if download succeeds but upload fails, the LLM can retry upload without re-downloading. Current design forces an all-or-nothing operation, reducing composability and error recovery options. This violates pattern:tool.
No idempotency hints in descriptions. Tools that modify state (upload_image, create_draft, generate_cover, etc.) should explicitly state whether repeated calls with identical parameters produce the same result or cause duplicates. For example, does calling upload_image twice with the same file_path upload the same image twice, or does it skip the second call? Agents retry on ambiguous failures, without idempotency guidance, they risk duplicate side effects (duplicate drafts, multiple image uploads). This violates pattern:idempotent-operation.
Tools like 'config', 'layout', and 'brand' use action/command parameters ('init', 'show', 'validate', 'set') but these are not declared as enums with explicit allowed values. Free-form strings invite hallucinated values (e.g., LLM passes 'initialization' instead of 'init'). Enums are self-documenting and let LLMs pick valid options without guessing. This violates pattern:constrained-input.
Generic descriptions for read-only discovery tools. Tools like 'capabilities', 'providers', 'themes', 'prompts', and 'skills' have descriptions under 40 characters (e.g., 'List available AI providers and models', 'List available layout themes', 'List available skills and extensions'). These do not explain when to call them or what data structure they return. Example: 'prompts' should say 'Returns a list of available AI prompt templates that can be used with write, humanize, and title tools. Call this first to see available prompt variants before generating content.' This violates pattern:tool-description and harms tool discoverability.
Incomplete parameter documentation for AI-related tools. 'generate_image', 'write', 'humanize', and 'title' accept optional parameters (prompt, style, etc.) but descriptions do not specify: What AI providers are supported? What models are used? Does it require API keys configured? What is the maximum prompt length? Are there rate limits? This forces LLMs to call 'providers' first as a discovery step, wasting a round-trip. Descriptions should include dependency hints: 'If no prompt is provided, uses a default template. Call providers() first to confirm an AI service is configured.' This violates pattern:tool-description.