VoidLang MCP exposes 9 HTTP endpoints with minimal schema documentation. Tool names lack action verbs (GET /isa, POST /compile are HTTP verbs, not semantic tool names). Descriptions are present but generic (10-50 chars). Input schemas for POST endpoints exist but are sparse: /compile accepts a 'void' object with no nested schema, /run similarly lacks detail. No output schemas documented. No error handling guidance. No parameter validation rules stated. The server is functional but falls well below production-grade tool definition standards.

• Rename tools to semantic action verbs: 'get_isa', 'get_isa_quick', 'list_targets', 'compile_void', 'run_void', 'download_artifact', 'check_health', 'get_mcp_manifest'. This enables LLMs to infer intent from names alone.
• Document output schemas for all tools. E.g., /compile should return {targets: [{target: string, kind: string, binary_size: number, build_log: string}], artifacts: [{id: string, filename: string, size: number}]}.
• Expand input schemas with nested types. /compile's 'void' param should be {type: 'object', properties: {v: {type: string}, name: {type: string}, tgt: {type: string}, ins: {type: array}}, required: ['v']}.
• Extend descriptions to 100-200 chars with context: 'Compile a void bytecode file to generate binaries (linux), source code (go), or project scaffolds (web, mobile, docker). Requires a valid void object with opcodes. Returns artifacts by target platform.'
• Add error handling guidance: 'POST /run may fail with timeout (>180s), invalid_bytecode, or platform_unsupported. Retryable errors: timeout. Non-retryable: invalid_bytecode (fix code and retry). Returns {error: string, code: string, suggestion: string}.'