Three tools with clear, action-verb names (shield_scan_*) and adequate descriptions (50-80 chars each). All have proper JSON Schema with required fields and type declarations. However, parameter descriptions are minimal (e.g., 'Path to the file to scan' lacks format/constraint guidance). No output schema documented, LLMs cannot predict response structure. No error handling guidance. Missing tool annotations (readOnlyHint present conceptually but not declared in schema). Baseline: avg tool description ~194 chars; these are ~65 chars. Avg params per tool: 1.3 (well below baseline 4), suggesting oversimplification.

• Document output schema: Define the structure of findings (e.g., {findings: [{rule_id, severity, file, line, message, remediation}], summary: {total, critical, high, medium, low}}). This enables LLMs to extract and act on results.
• Enhance parameter descriptions with constraints. E.g., 'file_path: Absolute or relative path to a Python/TypeScript/JavaScript source file. Max 4096 chars. Returns error if file does not exist or is not readable.'
• Add error handling guidance in tool description. E.g., 'If the file is not found, returns {error: "File not found", suggestion: "Check the path and try again"}. If syntax is invalid, returns partial results with parsing errors.'
• Declare tool annotations in schema. Add 'readOnlyHint: true' to each tool's inputSchema to signal safety to LLMs and clients.
• For shield_scan_directory, add optional parameters: max_depth (default 10), exclude_patterns (default ['.git', 'node_modules']), limit (default 100 findings). Document that results are capped and paginated.