Four read-only file analysis tools with basic schemas and descriptions. All tools have input schemas with type definitions and descriptions present. However, descriptions are minimal (10-20 chars baseline), parameter descriptions lack actionable detail (e.g., 'File path to read' vs 'Absolute or relative file path; must be readable by the process'), and output schemas are completely undocumented. No error recovery guidance. Tools follow verb_noun naming (safe_read, get_outline, inspect_file, read_hex) but lack composition hints and chaining IDs. No tool annotations (readOnlyHint present in metadata but not in schema). Baseline: avg tool description ~15 chars (well below 194-char production baseline); zero output schema documentation.

• Add output schema documentation for each tool. E.g., safe_read should document: {content: string, encoding: string, byte_count: integer}. get_outline should document the structure of returned outline (e.g., array of {type, name, line_number}).
• Expand tool descriptions to 100-200 characters. Include WHEN to use (e.g., 'Use safe_read for text files with unknown encoding; use read_hex for binary inspection'). Add return value summary (e.g., 'Returns file content as UTF-8 string with detected encoding label').
• Add constraint details to parameter descriptions. E.g., 'path: Absolute or relative file path (max 4096 chars); must be readable by process. Relative paths resolved from current working directory.' 'range: Byte offsets [start, end] where 0 ≤ start < end ≤ file_size.'
• Implement error recovery guidance in error responses. Replace Japanese error messages with English, actionable guidance: 'File not found at /path/to/file. Verify path exists and is readable. Use inspect_file to check file metadata first.'
• Document tool composition. Add a 'Related tools' section to descriptions: 'safe_read: Use after get_outline to read specific functions. inspect_file: Use first to check file metadata and search for keywords before reading.'