Server has 15 tools with basic schemas and descriptions, but significant quality gaps. Tool names follow verb_noun convention (good). However, descriptions are minimal (10-50 chars, well below the 194-char baseline), parameter descriptions are sparse or missing entirely, and output schemas are not documented. Many parameters use overly generic 'additionalProperties: true' payloads instead of explicit field definitions. Error handling is present but not recovery-focused. No tool annotations (readOnlyHint/destructiveHint) despite clear risk classifications in metadata.

• Expand all tool descriptions to 100-200 chars. Include WHAT the tool does, WHEN to use it (vs similar tools), and what the response contains. Example: 'List all projects in TestIT with pagination. Use this to discover available projects before creating test plans. Returns project ID, name, and status. Supports page/size pagination.'
• Replace opaque 'payload' parameters with explicit field definitions. For create_project, define required fields (name, description, etc.) with types and descriptions. Use JSON Schema properties instead of additionalProperties: true.
• Document output schemas for all tools. Add a 'Returns' section to each tool description or a separate schema definition. Example: 'Returns: {id: string, name: string, status: string, createdAt: ISO8601}'.
• Add parameter descriptions for all inputs. For 'query' in search_projects, document: 'Search filter object. Supported keys: name (string), status (enum: active|archived), createdAfter (ISO8601 date).'
• Add tool annotations to inputSchema. Mark read-only tools with 'readOnlyHint: true', destructive tools (delete_project) with 'destructiveHint: true', and idempotent tools with 'idempotentHint: true'. This enables LLM safety reasoning.