Single tool 'itarcheck_scan' has a reasonable name (verb_noun pattern) and adequate description (89 chars), but critical gaps undermine quality. Input schema is present with proper type and description for the 'target' parameter. However, the tool lacks output schema documentation, LLMs cannot infer the structure of returned JSON findings. No error handling guidance, no parameter constraints (e.g., file existence validation), and no documentation of what 'ITAR/EAR export-controlled terms' means or how findings are structured. The description is generic and does not explain when to use this tool vs. alternatives, what prerequisites exist, or what the JSON response contains. Baseline: 194 chars avg description (this is 89); 100% of A+ tools document output schemas (this does not).

• Document the output schema explicitly: 'Returns JSON object with fields: tool (string), findings (array of {id, sev, where}), score (integer). Example: {"tool": "itarcheck", "findings": [{"id": "GEN-001", "sev": "high", "where": "/path/to/file"}], "score": 1}'.
• Expand description to 150 - 250 chars: 'Scans files and directories for ITAR/EAR export-control keywords and USML category indicators. Returns structured findings with severity levels. Use this to audit code, datasheets, and documentation before sharing with external parties.'
• Add parameter constraint to 'target': 'File or directory path (absolute or relative). If directory, recursively scans all files. Must be readable by the process.'
• Add error handling guidance: 'If target does not exist, returns error: "Path not found: <path>". If unreadable, returns partial results with accessible files only.'
• Document the rules/findings structure in the description or as a separate discovery tool. Clarify what 'GEN-001', 'high', etc. mean so LLMs understand severity and can prioritize findings.