Lynx is a policy-gated execution library, not an MCP server. Tools are defined across example files with basic schemas and descriptions. Most tools have 1-3 parameters with type info and brief descriptions (avg ~50 chars), but lack depth on when/why to use them, error recovery, and output schemas. No tool annotations (readOnlyHint/destructiveHint). Naming is verb-first (list_files, write_file, shell) but descriptions are minimal. Example: 'List the files in a directory' (34 chars) lacks context on path resolution, symlink handling, or result structure. wire_transfer and refund tools lack confirmation/dry-run patterns despite destructive risk. No pagination, no output schema documentation, no error guidance.

• Add 50 - 150 char descriptions to all tools explaining WHAT they do, WHEN to use them, and any prerequisites. E.g., 'List files in a directory (non-recursive). Returns file names, sizes, and modification times. Use before reading or writing files to verify paths.'
• Document output schemas for all tools. Specify returned fields, types, and structure. E.g., list_files returns [{name: string, size: int, mtime: ISO8601}].
• Add tool annotations: mark wire_transfer, issue_refund, refund_customer, sql_exec, shell, write_file as destructiveHint=true; mark list_files, get_customer, heavy_compute as readOnlyHint=true.
• Implement confirmation/dry-run for destructive tools. E.g., wire_transfer should support a 'dry_run' parameter or require explicit confirmation before executing.
• Add parameter descriptions for all inputs. E.g., shell's 'cmd' param should note 'Shell command to execute. Dangerous commands (rm, dd, etc.) may be blocked by policy.'