Single tool 'hl7tap_scan' has a generic description (89 chars) that lacks actionable detail about when/why to use it. Parameter 'target' has no type annotation visible in the schema definition, only a string type assertion in the description. No output schema documented. The description mentions 'Parse, pretty-print, diff, and replay HL7 v2 messages' but the tool only accepts a target path and returns JSON findings, the description conflates the CLI's multi-command interface with the MCP tool's single responsibility. No error handling guidance, no parameter constraints (e.g., valid path formats), and no indication of what 'findings' structure contains.

• Rewrite tool description to 50 - 150 chars, focusing on the MCP tool's single responsibility: 'Parse an HL7 v2 message file and return structured findings (segments, fields, validation issues).' Remove references to diff/replay/pretty-print, those are CLI features, not this tool's job.
• Document the output schema explicitly. Example: 'Returns {"findings": [{"id": string, "severity": "high"|"medium"|"low", "message": string, "location": string}], "score": number}'. This lets LLMs know what to extract.
• Add parameter description for 'target': 'File path to an HL7 v2 message file (e.g., /path/to/message.hl7). Must be readable by the server process. Returns error if file not found or not valid HL7.'
• Add error handling examples in the tool description: 'If target is not found, returns error with suggestion to list available files. If file is not valid HL7, returns partial findings with validation errors.'
• Rename tool to 'parse_hl7_message' or 'analyze_hl7_file' to follow verb_noun convention and clarify intent.