Four tools with basic verb-noun naming (list_*, get_*) and present descriptions. All tools are READ_ONLY, reducing risk. However, descriptions are terse (10-60 chars), parameter descriptions are minimal or absent, and output schemas are not documented. Input schemas are visible and properly typed, but lack depth. No error handling guidance, no pagination support despite list_scans accepting a limit parameter, and no chaining IDs documented. Follows basic patterns but falls short of production quality.

• Document output schemas for all four tools. Example: list_scans returns {scans: [{id: string, status: string, finding_count: integer, created_at: string}], total: integer}. This enables LLMs to chain tools and extract the right fields.
• Expand tool descriptions to 100-150 characters. Example for list_scans: 'List recent ORTHRUS vulnerability scans in reverse chronological order. Returns scan IDs, status (running|completed|failed), and finding counts. Use this to discover available scans before calling get_findings.'
• Add min/max bounds and format guidance to parameters. Example: 'limit (integer, 1-100, default 50): Maximum number of scans to return. Larger limits may timeout.' For scan_id: 'scan_id (string, UUID format): The unique identifier of the scan, returned by list_scans.'
• Document pagination behavior explicitly. If list_scans returns all results up to limit, state: 'Returns up to limit scans. If more exist, the response includes next_cursor for pagination.' If no pagination exists, state: 'Returns all scans matching the limit; no pagination support.'
• Add error handling guidance to get_scan and get_findings. Example: 'If scan_id is not found, returns error 404 with message "Scan not found. Call list_scans() to see available scans." Retry is not needed; check the scan_id and try again.'