This server has critical definition gaps. Tool descriptions are present but minimal (10-60 chars, well below the 50-200 char baseline for LLM-optimized descriptions). The publish_application tool has a basic schema with 4 parameters, but descriptions lack actionable detail (e.g., what format should 'target_path' take? What are valid 'parameters'?). list_sessions has an empty input schema but no output schema documented. No error handling guidance, no parameter constraints (enums, ranges), and no indication of what fields are returned. The server exposes credentials (RAS_USERNAME, RAS_PASSWORD) via environment variables but does not document permission scopes or audit trails. Tool names are acceptable (verb_noun pattern) but descriptions do not explain WHEN to use each tool or what the LLM should expect in responses.

• Document output schemas for both tools. Example: list_sessions returns {sessions: [{id: string, name: string, user: string, status: string}], total: number}. publish_application returns {app_id: string, status: string, message: string}.
• Expand parameter descriptions with format and constraint details. E.g., 'target_path: Full file system path (e.g., /opt/apps/myapp.exe). Must be accessible on the RAS server.' and 'parameters: Command-line arguments as a single string (e.g., "-v --config=prod"). Optional.'
• Add error handling guidance to tool descriptions. E.g., 'On failure, returns error code and message. If app_name not found, try list_applications() first. If target_path invalid, verify path exists on RAS server.'
• Document permission scopes and audit requirements. Add to server docs: 'Requires RAS admin credentials. All calls logged with timestamp, user, tool, and result for compliance.'
• Expand list_sessions description to 100+ chars explaining what sessions are, when to call it (e.g., 'before publishing to check active users'), and what fields are returned.