The 'scan' tool has a high-level description but NO visible input schema, parameter definitions, or output schema in the provided source. The mcp_server.py delegates to build_mcp_server() from cognis_core.mcp (external dependency), making the actual tool registration opaque. Without seeing explicit parameter types, descriptions, or constraints, the schema cannot be scored. The tool name 'scan' is generic and does not follow verb_noun convention (should be 'scan_sbom' or similar). No error handling, validation, or recovery guidance is visible.

• Expose the full tool definition in sbomgate/mcp_server.py: explicitly register the 'scan' tool with input schema (parameters with types, descriptions, enums, constraints), output schema, and error cases. Do not delegate to an external build_mcp_server() function without showing the resulting schema.
• Rename 'scan' to 'scan_sbom' or 'diff_sbom' to follow verb_noun convention and clarify the action. This helps LLMs distinguish it from other scanning tools.
• Document all input parameters: what does 'scan' accept? (e.g., old_sbom_path, new_sbom_path, fail_on_severity, output_format). Each parameter must have a type, description, and constraints (enums, ranges, patterns).
• Document the output schema: what fields does 'scan' return? (e.g., findings array with kind, component, severity, detail, old, new; gate pass/fail status; counts). Include examples.
• Add error handling and recovery guidance: 'If SBOM parsing fails, ensure the file is valid JSON and contains a components or packages array. If file not found, check the path. If network error, retry after 5 seconds.'