37 tools with highly variable quality. Most tools have descriptions (good), but parameter schemas are inconsistently documented. Many tools lack explicit input schema definitions in the visible code, only tool names and descriptions are evident. Parameter descriptions exist but are often terse (10-30 chars). No tool annotations (readOnlyHint, destructiveHint, idempotentHint) detected. Error handling and recovery guidance absent. Output schemas not documented. Tools are well-named (verb_noun pattern), but composition is weak: many tools operate on the same resources (song manifests, VSQX projects) without clear chaining guidance. Risk labels (READ_ONLY, WRITE) are present but not integrated into tool definitions.

• Add explicit input schemas (JSON Schema with type, description, enum, minLength, maxLength) to all 37 tools. Currently only ~10 tools have visible schemas. Use Zod or TypeScript interfaces to generate schemas automatically.
• Integrate risk labels into MCP tool definitions via readOnlyHint (for READ_ONLY tools) and destructiveHint (for WRITE tools). This enables LLMs to reason about safety without parsing metadata.
• Document output schemas for every tool. Include field names, types, and examples. E.g., vocaloid_inspect_song_manifest should return {song_id: string, title: string, sections: [{section_id: string, ...}], ...}.
• Add error handling guidance to tool descriptions. E.g., 'If the manifest file is not found, returns error code FILE_NOT_FOUND with available manifest paths. Retry with a valid path or call vocaloid_create_song_manifest to create a new one.'
• Create a workflow guide documenting common tool sequences (e.g., create → edit → build → render) and the IDs/references passed between them. Include this in prompts or resources so LLMs understand composition.