Two tools registered. dingtalk.bootstrap has a clear description (95 chars) and empty input schema (correct for no-arg tool). dynamic_dws_tools is critically problematic: it is a meta-tool that dynamically loads schemas at runtime from an external binary (dws), making static schema validation impossible. The description (156 chars) explains the pattern but does not document what individual tools do, what parameters they accept, or what they return. No per-tool schema visibility in source code. Tool names lack action verbs (dynamic_dws_tools is generic). No parameter descriptions for dynamically loaded tools. No output schema documentation. Error handling returns formatted text but lacks recovery guidance.

• Expose dws schema at server startup: parse dws output and register each tool with explicit name, description, input schema (Zod), and output schema. Avoid the dynamic_dws_tools meta-tool; register concrete tools like 'dingtalk.send_message', 'dingtalk.list_conversations', etc.
• Add per-parameter descriptions to all dynamically loaded tools. If dws provides flag descriptions, include them in Zod schema via .describe(). If not, document in a README mapping dws flags to MCP parameters.
• Implement input validation in dispatch.ts: sanitize arguments against command injection (no shell metacharacters unless explicitly quoted), validate enum values against dws schema, and reject unknown flags.
• Enhance error responses with recovery guidance. E.g., 'Authentication failed. Run `dws auth login` in a terminal and restart the MCP server.' instead of raw error text.
• Document output schema for each tool. If dws returns JSON, parse and return structured objects with typed fields. If text, document the format (e.g., 'Returns newline-delimited key=value pairs').