Critical gaps across all dimensions. Tool descriptions are minimal (10-20 chars), far below the 194-char baseline for production tools. No input parameter descriptions exist, LLMs cannot infer what 'data' object contains or how to construct it. Output schemas are completely undocumented. No error handling guidance. Tool names lack clarity (e.g., 'get_compute_by_id' vs 'get_computes' distinction is unclear). The 'update_compute' tool accepts a generic 'data' object with no schema visibility, violating constrained-input and secret-injection patterns. No tool annotations (readOnlyHint, destructiveHint). This server would require substantial rework before production use.

• Expand all tool descriptions to 100-200 characters. Example: 'get_version' → 'Retrieve the current GNS3 server version and build information. Use this to verify server compatibility before executing topology operations.'
• Add parameter descriptions for 'compute_id' (e.g., 'The unique identifier of the compute resource (string, e.g., "local")') and 'data' (e.g., 'Compute configuration object with required fields: host (string), port (integer 1-65535), protocol (http|https), and optional user/password for authentication').
• Document output schemas for each tool. Example for get_computes: 'Returns array of compute objects with fields: compute_id (string), host (string), port (integer), protocol (string), user (string|null), password (string|null), status (string).'
• Add tool annotations: mark get_* tools with readOnlyHint=true; mark update_compute with destructiveHint=true to signal state modification.
• Add error handling guidance. Example for update_compute: 'If authentication fails, return "Invalid credentials for host {host}. Verify user/password in configuration." If connection times out, suggest checking network connectivity and port availability.'