astro-dev-mcp is a domain-specific code generation server with mixed quality. The server defines 6 tools with explicit schemas and descriptions, but several critical gaps undermine production readiness. Tool names follow verb_noun conventions (generate-*, get-*), which is correct. Descriptions are present and detailed, some exceeding 1024 chars with example JSON blocks, this is overly verbose and wastes tokens. Input schemas are complete with type definitions and enums, but parameter descriptions lack implementation guidance. Output schemas are entirely undocumented, critical for a generation tool. Error handling is absent: no recovery guidance, no validation rules, no error classification. Security is weak: no audit trails, no permission checks, no secret injection pattern. Composition is reasonable, tools do single jobs, but idempotency is uncertain for file-write operations. The Japanese-language descriptions add cognitive load for English-speaking LLMs, though content is technically correct.

• Add output schemas to all tools. For generate-* tools, document: { success: boolean, filePaths: string[], content: string, error?: string }. For get-* tools, document the structure of returned context (e.g., { components: [...], schemas: [...], structure: ... }).
• Shorten descriptions to 100-200 chars and remove embedded JSON examples. Move examples to parameter descriptions or separate documentation. Example: 'Generates Astro components with typed props and Sass styling. Specify props as TypeScript interfaces (string|number|boolean|array|object). See get-project-context for existing component patterns.'
• Clarify auto-inference for generate-section and generate-page. Add parameter guidance: 'prompt: Describe the section intent in English (e.g., "Article cards in a grid", "Q&A in accordion"). The system infers sectionType and uiPattern from this description. For explicit control, pass sectionType and uiPattern directly.'
• Add field requirements to generate-page pageData. Document: 'pageData.head requires: slug (string, URL-safe), ttl (string, <100 chars), description (string). Optional: url, image. pageData.contents structure depends on sections; use get-project-context to see required fields for each section type.'
• Implement input validation with error guidance. Example error message (not just rejection): 'Invalid componentName: "articleCard". Must be PascalCase (e.g., ArticleCard). To fix: capitalize first letter and remove hyphens.'
• Add confirmation step for destructive writes. Before overwriting existing files, return { status: 'confirm_required', filePath: string, action: 'overwrite'|'merge'|'error_on_conflict' } and let LLM choose next action.