shadcn-mcp has 4 tools with basic schemas and descriptions, but significant gaps limit production readiness. Tool names follow verb_noun convention (list_, generate_, init_, get_), which is good. However, descriptions are generic (10-50 chars for most), parameter descriptions are minimal or absent, and output schemas are completely undocumented. No error handling guidance, no pagination support, and no indication of which operations are destructive. The server exposes file system paths as required parameters without validation or sanitization, creating security risks. Schemas are present but sparse, most parameters lack detailed constraints, ranges, or format specifications.

• Document output schemas for all tools. E.g., list_components should return {components: [{id: string, name: string, description: string}], total: number}. This enables LLMs to extract component IDs for downstream calls.
• Add enum constraint to 'component' parameter in generate_component and get_component_docs. Reference the hardcoded SHADCN_COMPONENTS array to auto-generate valid options, preventing hallucinated component names.
• Validate and sanitize project_path parameter. Reject paths containing '..', enforce absolute paths or relative-to-cwd only, and document the expected directory structure (must contain package.json, tsconfig.json, etc.).
• Add error recovery guidance. E.g., 'If component already exists, call generate_component with overwrite=true' or 'If init fails, check that project_path contains a valid package.json'.
• Implement per-tool destructive hints in tool annotations (destructiveHint: true for generate_component and init_shadcn) and add a dry_run boolean parameter to preview changes before committing.