Three tools with basic schemas and descriptions, but significant gaps in parameter documentation and error handling. Tool names use domain-specific prefixes (openvsp.*) rather than action verbs (inspect, modify, run are present but inconsistently applied). Schemas are present but parameters lack detailed constraints and validation guidance. No error recovery patterns, no output schema documentation, and descriptions are minimal (34-72 chars, below the 50-200 char LLM-optimized baseline). Missing parameter descriptions for array items and boolean flags. No tool annotations (readOnlyHint, destructiveHint, idempotentHint) despite clear read/write semantics.

• Rename tools to action-verb form: 'describe_geometry' (instead of inspect), 'edit_geometry' (instead of modify), 'run_analysis' (instead of run_vspaero). This clarifies intent and matches LLM expectations.
• Expand tool descriptions to 100-200 characters. Current descriptions (34-72 chars) lack context on when to use each tool and what distinguishes them. E.g., 'Describe an OpenVSP geometry without modifying it. Returns component IDs, parameters, and raw metadata. Use this to inspect a model before editing.' (120 chars).
• Document set_commands parameter fully: 'Array of VSP script commands to execute. Each command is a literal line of OpenVSP Python syntax (e.g., {"command": "vsp.SetParmVal(geom_id, \"Length\", \"XSec_1\", 5.0)"}). Invalid syntax will cause the script to fail.'
• Add output schema documentation in tool descriptions or as a separate schema field. E.g., 'Returns {script_path: string, execution_time_ms: number, error: string|null, components: [{id: string, name: string, type: string}]}'.
• Implement error handling with actionable messages. Catch file-not-found, script syntax errors, and VSPAero crashes; return structured errors like '{error: "File not found", path: "/path/to/file.vsp3", suggestion: "Check the file path and try again."}'.