Single tool 'shipcheck_scan' has a clear, concise description (79 chars) and a minimal but present input schema. However, the schema lacks depth: only one required parameter with a basic string type and no format/pattern constraints. No output schema is documented, the tool returns JSON but the structure is not specified. Parameter description is generic ('Path to Dockerfile to scan') and does not explain expected format, error cases, or what 'findings' means. No error handling guidance. Tool naming is acceptable (verb_noun pattern) but the description does not explain WHEN to use it vs alternatives, what prerequisites exist, or how to interpret results. Baseline: avg tool description 194 chars (this is 79); avg params per tool 4 (this has 1). The server exposes only one tool, limiting composition assessment.

• Document the output schema explicitly. Example: 'Returns {findings: [{code: string, severity: string, line: number, instruction: string, message: string, hint: string}], summary: {total: number, critical: number, high: number}}'. This lets LLMs extract and reason about results.
• Expand tool description to 100-150 chars explaining WHAT (Dockerfile linter), WHEN (before building/pushing images), and WHAT IT RETURNS (JSON array of linting findings with severity levels). Example: 'Analyzes a Dockerfile for security, hygiene, and CVE issues. Returns structured findings with severity (critical/high/medium/info) and remediation hints.'
• Add format constraint to 'target' parameter: 'Path to Dockerfile (absolute or relative; must exist and be readable). Example: ./Dockerfile or /app/Dockerfile'.
• Add error handling guidance in tool description: 'If file not found, returns error with available paths. If Dockerfile is malformed, returns partial findings with line numbers.'
• Consider adding optional parameters for filtering results by severity (e.g., min_severity: enum [critical, high, medium, info, all]) to reduce noise and let agents focus on critical issues.