This MCP server exposes 18 tools for ConoHa VPS operations (storage, compute, networking). Tool naming is generally clear and action-oriented (list_, create_, delete_, upload_, get_). Descriptions are present for all tools and often detailed, though written in Japanese which limits LLM optimization. Input schemas are well-structured with proper types, enums, and constraints. However, there are significant gaps: (1) Tool descriptions lack explicit guidance on when to use each tool vs alternatives, (2) No output schemas are documented, critical for multi-tool chaining, (3) Error handling is minimal, tools don't guide recovery or categorize errors, (4) Some generic tools (conoha_post, conoha_post_put, conoha_get) accept overly flexible parameters that could benefit from more specific tool variants. The codebase shows good engineering (TypeScript, Zod validation, proper file organization) and includes risk annotations (READ_ONLY, WRITE, DESTRUCTIVE) but lacks documentation of those risk semantics in descriptions. Translation to English and output schema documentation would significantly improve LLM usability.

• Translate all tool descriptions to English. Japanese descriptions limit LLM understanding and accessibility. Keep Japanese as a secondary reference in code comments if needed.
• Document output schemas for all tools. Create a return type schema (e.g., in Zod) and include it in tool registration. Example: list_containers should declare it returns { containers: { name: string, count: number, bytes: number }[] }.
• Refactor generic conoha_post into specific tools: create_server, create_keypair, create_volume, create_security_group, create_security_group_rule. Each tool should have a clear, single responsibility.
• Add error categorization and recovery hints to descriptions. Example for delete_container: 'Fails with 409 if container is not empty. Try list_objects to see contents, then delete_object for each item, then retry.'
• Clarify when to use conoha_get vs conoha_get_by_param in descriptions. Example: 'Use conoha_get for listing all resources (servers, images, etc.). Use conoha_get_by_param when you already have a specific resource ID and need details about it.'
• Add 'required' and 'optional' field lists to all parameter descriptions. For conoha_post, specify which requestBody fields are required for each path (e.g., 'For /servers, flavorRef and security_groups are required; adminPass is optional').
• Modify upload_object to accept raw file content and handle Base64 encoding internally. Change parameter from 'content_base64' to 'file_content' and encode it server-side. This removes cognitive burden from the LLM.