VULK MCP Server demonstrates strong definition quality with well-structured tool schemas, consistent naming conventions, and comprehensive parameter validation. All 11 tools follow verb_noun naming patterns (create_visual_brief, get_project, deploy_project, etc.). Tool descriptions are detailed and contextual, explaining WHAT the tool does, WHEN to use it, and consequences. Input schemas are fully specified with Zod validation, including type constraints, min/max bounds, regex patterns, and enum restrictions. However, output schemas are not explicitly documented in the visible code, responses are constructed ad-hoc rather than formally specified. Error handling is present at the API layer but not visible in tool definitions themselves. Tool annotations (readOnlyHint, destructiveHint) are correctly applied for risk classification. One notable gap: no explicit tool-to-tool composition guidance (e.g., which tools accept the IDs returned by others), though the API design suggests reasonable chaining (create_project returns URLs that pair logically with edit_project and deploy_project). File content handling in get_project_files includes size limits and redaction guards, showing security-conscious design.

• Document output schemas for all tools. Define the structure of responses returned by create_project, get_project, list_projects, etc. Use TypeScript types exported from api.ts and reference them in tool descriptions or a separate schema file. Example: 'Returns {projectId: string, previewUrl: string, editorUrl: string, created: ISO8601}'
• Expand list_models and get_usage descriptions to 80 - 150 characters. Explain WHY an LLM would call each: 'Use list_models to see which generative models your account has access to before calling create_project with a specific model ID.' 'Use get_usage to check remaining credits before creating expensive immersive sites; returns tokens used, cost, and remaining quota.'
• Clarify subscribe description: 'Returns a URL to VULK pricing or a checkout link for the specified plan. Does NOT charge or activate billing, only generates a shareable URL. Use this to guide users to upgrade their plan.'
• Add error recovery guidance in tool descriptions. Example for create_project: 'May fail if account lacks credits or model availability. On error, suggest checking get_usage() for remaining credits or list_models() to see available models.' This teaches the LLM how to diagnose and recover.
• Document tool composition patterns in a README or via tool description hints. Example: 'After create_visual_brief returns a brief structure, pass the moodboard field to generate_immersive_site. After create_project succeeds, pass projectId to edit_project or deploy_project.' This enables multi-step workflows.