Two tools with minimal definitions. zsv_run has a basic description (67 chars) and a properly typed input schema with array of strings. zsv_help has a minimal description (48 chars) and empty input schema. Neither tool has parameter descriptions beyond the schema type. No output schemas documented. No error handling guidance. Tool names lack clarity on what zsv is or when to use each variant. Descriptions do not explain prerequisites, return format, or error cases.

• Expand tool descriptions to 100-200 characters. Explain: (1) What zsv is (a CSV processing tool), (2) When to use zsv_run vs zsv_help, (3) What the tool returns, (4) Any prerequisites or constraints. Example: 'zsv_run executes a zsv command (e.g., count, sql, search) on CSV files and returns the output. Use this for data operations; use zsv_help for command reference.'
• Document output schemas. Define the structure of stdout responses, are they plain text, JSON, CSV, or structured lines? Include field names, types, and example output so LLMs can parse results reliably.
• Add parameter descriptions and constraints. For 'cmd', specify: valid zsv subcommands (count, sql, search, etc.), required vs optional arguments, and example invocations. Use enums if the set of subcommands is fixed.
• Implement error handling guidance. Document common failure modes (file not found, invalid syntax, permission denied) and recovery steps. Return structured error responses with actionable messages, not raw stderr.
• Consider renaming tools for clarity. 'run_zsv_command' and 'get_zsv_help' are more explicit. Alternatively, prefix with the domain: 'csv_run_zsv' and 'csv_get_zsv_help' to signal they operate on CSV data.

Inferred effective spec: <=2025-11-25.

• Relies on Logging (deprecated) - log to stderr or use OpenTelemetry