Server provides 4 markdown processing tools with reasonably complete schemas and descriptions. All tools have input schemas with typed parameters and descriptions. However, descriptions are in Chinese (not LLM-optimized for English-speaking agents), and output schemas are only partially visible in the code. Tool names follow verb-noun convention (render, parse, extract, lint) but lack clarity around when to use each relative to others. Parameter descriptions are present but could be more prescriptive about constraints. The server shows solid foundational quality but lacks production-grade polish around error handling guidance and composition patterns.

• Translate all tool descriptions and parameter descriptions to English. Provide clear, LLM-optimized descriptions (50-200 characters) explaining WHAT each tool does, WHEN to use it, and WHAT it returns.
• Document output schemas for 'render', 'parse', and 'lint' explicitly in source code (e.g., 'outputSchema: z.object({...})') following the pattern used in 'extract'. Include descriptions for each output field.
• Add error handling guidance to each tool description. Example: 'Returns error if Markdown exceeds 1MB. If input is truncated, try splitting into smaller sections.' (pattern:recovery-guide)
• Add a dry-run or preview mode to 'lint' tool. Include a new optional parameter 'dryRun: boolean (default false)' that returns proposed fixes without applying them, letting the agent show a preview before confirming.
• Clarify composition in descriptions. Add notes like: 'Use parse() to convert HTML to Markdown, then render() to style it for a target platform.' (pattern:tool-chain)
• For 'render', add guidance on platform selection: 'Use platform=wechat for WeChat Public Account, zhihu for Zhihu Column. Each platform has style and HTML restrictions.' Map each enum value to its use case.
• Add input validation examples to descriptions. E.g., 'customCss selectors must be scoped under #bm-md to prevent style leakage.' This helps agents avoid common mistakes.
• Consider adding a 'stats' tool to return metadata about a Markdown document (word count, heading count, code block count, etc.) without extracting text. This would support analytics use cases without duplicating extract functionality.