exec tool is dangerously under-documented. Description is only 'Execute arbitrary shell commands via bash -c (VERY DANGEROUS - only in trusted/sandboxed environments)', insufficient for LLM decision-making. LLMs cannot infer when/why to use this tool. No actionable error guidance.

Neither tool documents its output schema. LLMs cannot predict what fields are returned, forcing them to guess downstream usage. Pattern requires 'Document the output schema'.

exec tool name violates action-verb pattern. 'exec' is generic and does not describe the action. Should be 'run_shell_command' or 'execute_bash'. 'exec' by itself is ambiguous.

go_tool description mentions actions (vet, test, build, fmt, tidy, verify) but does not explain WHEN to call each or WHAT they produce. Descriptions should be 50-200 chars and explain intent, not just list enums.

cwd parameter in both tools lacks usage guidance. Is it optional? What happens if omitted? Does it affect path resolution? Undocumented dependencies confuse LLMs. Pattern pattern:param-relationships requires explicit documentation.

exec tool accepts free-form cmd string with no validation hints. No description of shell syntax, quoting, or injection risks. LLMs cannot reason safely about shell escaping. Should document expected format or accept structured parameters.

Error responses are basic RPCError (code + message). No classification of retryable vs fatal errors. No recovery guidance. Pattern pattern:recovery-guide requires 'Error responses must tell the LLM what to do next'.

No input validation visible in source. runCommand accepts any args; no SQL injection, path traversal, or command injection guards. exec tool passes raw cmd to bash -c. Pattern pattern:tool-gateway requires input sanitization.