Single tool 'scan' has a reasonable name and description (89 chars), but critical gaps undermine quality. Input schema is visible with two parameters (input, rules), both with descriptions. However, the schema lacks type constraints (no enums for rule IDs, no format/pattern for file paths), and the output schema is completely undocumented, LLMs cannot plan downstream actions or extract structured data. No error handling guidance, no pagination despite potentially large SARIF outputs, and no indication of whether the tool is idempotent or has side effects. The tool description does not state WHEN to use it vs alternatives, or what the SARIF output structure contains. Baseline: 194 chars avg description (this is 89), 100% of A+ tools document return types (this does not).

• Document the complete SARIF output schema: include fields like 'version', 'runs', 'results', 'ruleId', 'message', 'locations', and their types. This enables LLMs to extract vulnerability details and plan follow-up actions.
• Add enum constraint to 'rules' parameter: specify valid rule IDs (e.g., ['MCP-001', 'MCP-002', ...]) or document the format (e.g., 'MCP-NNN where NNN is 001-999'). Remove the example from description and use a formal constraint.
• Expand tool description to 150-200 chars: explain WHEN to use scan (e.g., 'before deploying an MCP server'), WHAT it detects (vulnerability patterns), and WHAT to do with results (review SARIF, fix issues). Current 89 chars is too terse.
• Add error handling section to description: 'If path is invalid, returns error with available paths. If rule ID is unknown, returns list of valid rules. Scan failures include remediation hints.'
• Document idempotency and side effects: 'Scan is read-only and idempotent, safe to retry. Does not modify the target codebase. Output is a SARIF report suitable for CI/CD integration.'