Server has 4 tools with basic descriptions and partial schemas. Tool names follow verb_noun convention (supplyscan_status, supplyscan_scan, supplyscan_check, supplyscan_refresh), which is good. However, input schemas are defined via struct tags (jsonschema) rather than explicit JSON Schema in tool registration, the actual schema objects are not visible in the registration code. Descriptions are present but brief (34-72 chars), below the 50-200 char LLM-optimized baseline. Parameters lack explicit type declarations in the tool registration; types are inferred from Go struct fields. No output schemas are documented. Error handling via FindingsError is custom but lacks recovery guidance. No parameter validation, enums, or constraints visible.

• Explicitly pass InputSchema to mcp.Tool registration. Use go-sdk's schema builder or marshal struct tags to JSON Schema and include in the Tool definition so LLMs see parameter types and descriptions at discovery.
• Expand tool descriptions to 80-150 chars. Include WHEN to use the tool and what it returns. E.g., 'Scan a project directory for supply chain vulnerabilities and IOC matches. Returns a list of findings with severity, package, and remediation guidance. Use this to audit dependencies before deployment.'
• Document output schemas in tool descriptions or as a separate schema field. Describe the structure of ScanResult, CheckResult, StatusResponse, and RefreshResult so agents know what fields to expect.
• Add parameter constraints: ecosystem enum (npm|pypi), path validation (must exist and be readable), recursive/include_dev as boolean with clear defaults. Use descriptions like 'ecosystem: package registry (npm or pypi; default: npm)'.
• Refactor FindingsError: return findings as a structured result field (e.g., {success: true, findings: [...], error_count: 0}) instead of wrapping in an error. This lets LLMs distinguish successful scans with findings from actual failures.