Single tool 'auditrail_scan' has a basic description (89 chars) but critically lacks parameter descriptions. The input schema defines 'target' as a string with a description, but the tool description does not explain what constitutes a valid target (file path? log entry? directory?), when to use this tool, or what the JSON output structure contains. No output schema is documented. The tool name 'auditrail_scan' is reasonably verb-forward but the description does not clarify prerequisites, error conditions, or recovery paths. Baseline: 100% of A+ tools have documented return types and parameter descriptions; this tool has neither.

• Document the complete output schema. Example: 'Returns {"intact": bool, "event_count": int, "break_count": int, "breaks": [{"index": int, "reason": str, "action": str}], "manifest_digest": str}'. This lets LLMs know what fields to extract.
• Rewrite the 'target' parameter description: 'File path or directory containing audit log events in JSON or JSONL format. Accepts absolute or relative paths. Example: /var/log/audit.jsonl or ./events.json'.
• Expand tool description to 100-150 chars with clear intent: 'Verifies the integrity of an audit log by validating hash-chain links. Detects tampering, missing events, or corruption. Returns a manifest with event count, integrity status, and details of any breaks found.'
• Add error handling guidance to the description: 'Returns error if file not found, invalid JSON, or required fields (ts, actor, action) are missing. If tampering is detected, the manifest will have intact=false and a list of breaks.'
• Consider splitting the tool into two: 'auditrail_verify' (checks integrity, returns break list) and 'auditrail_attest' (generates a signed manifest). This matches the JavaScript port's command surface and gives agents finer control.