Kram exhibits severe definition quality gaps across all dimensions. Tool definitions are inferred from test files rather than explicit registration code, making actual schemas unverifiable. Descriptions are present but minimal (10-50 chars), lacking WHEN/WHY context. No input schemas visible in source, parameter types and constraints are undocumented. Critical tools like 'bash' and 'delete_file' lack error handling guidance. No tool annotations (destructiveHint, readOnlyHint) despite high-risk operations. Composition is poor: 'bash' and 'run_background' overlap; 'snapshot_diff' and 'snapshot_restore' lack output schema documentation. No evidence of pagination, rate limiting, or secret injection patterns.

• Publish explicit tool registration code showing full JSON Schema for all 13 tools. Include type, description, enum, minLength, maxLength, pattern, and default for every parameter.
• Expand descriptions to 50-200 chars following the pattern: WHAT (action), WHEN (use case), PREREQUISITES (required state). E.g., 'Execute a bash command in the workspace. Use for file operations, builds, or system tasks. Returns stdout/stderr. Destructive, use with caution.'
• Add tool annotations: mark bash, delete_file, run_background, write_file, snapshot_restore as destructiveHint=true; mark read_file, grep, web_fetch, ask_question, process_output, lsp_diagnostics as readOnlyHint=true.
• Implement confirmation pattern for destructive tools: add a 'dry_run' boolean parameter (default false) to bash, delete_file, run_background. Return what would happen without executing.
• Document output schemas for all tools. E.g., bash returns {stdout: string, stderr: string, exit_code: int}; read_file returns {content: string, size_bytes: int}. Include pagination for tools returning lists (grep, lsp_diagnostics).