Four tools with basic descriptions and partial schemas. All tools have descriptions (10-60 chars), but most are terse and lack actionable context for LLM selection. Input schemas are present but incomplete: parameters lack type definitions in visible code (inferred from function signatures). No output schemas documented. Error handling is minimal, tools return JSON strings without structured error guidance. No parameter validation hints, no enum constraints, no dependency documentation. Naming is verb-forward (scan_*, list_*, explain_*) but descriptions don't explain WHEN to use each tool or what distinguishes them.

• Add output schema documentation for each tool. E.g., scan_project returns {findings: [{id, severity, message, file_path, line, remediation}], scan_path, scanner_errors}. This enables LLM to extract and chain results.
• Expand parameter descriptions to 50-100 chars with actionable context. E.g., 'Path to BTP project root (mta.yaml or package.json present). Scans for CVEs, secrets, and XSUAA misconfigurations. Use scan_file for single-file analysis.'
• Add enum constraints: threshold in ['CRITICAL', 'HIGH', 'MEDIUM', 'LOW', 'INFO']; category in ['xsuaa', 'mta', 'cap', 'all']. Declare in schema and description.
• Enhance error responses with recovery guidance. E.g., explain_finding: 'Rule "RULE_XYZ" not found. Call list_rules(category="all") to see available rules, or check rule_id spelling.'
• Move trivy_path and gitleaks_path out of tool parameters. Inject via environment variables (TRIVY_PATH, GITLEAKS_PATH) or server config. Expose only user-facing inputs (path, threshold).