Single tool 'run_cell' has a freeform string parameter with no type constraints, enums, or validation guidance. Description is adequate (67 chars) but parameter lacks any description whatsoever. No output schema is documented. The tool accepts arbitrary Python code (WRITE risk) with no error handling, recovery guidance, or safety constraints. No input validation, no pagination, no structured output definition. This is a minimal, unsafe tool definition that violates multiple core patterns.

• Add a description to the 'freeform' parameter: 'Python code to execute in the persistent IPython kernel. Code runs in a shared namespace across calls. Avoid infinite loops, blocking I/O, and resource-intensive operations.'
• Document the output schema explicitly. Specify what fields are returned (e.g., stdout, stderr, result, execution_time, error_type) and their types.
• Add input validation: reject code containing dangerous patterns (e.g., 'import os', 'subprocess', '__import__') or implement a sandbox/timeout mechanism.
• Add error handling that returns structured errors with recovery hints: 'SyntaxError on line 3: invalid syntax. Check your Python code and retry.' instead of raw tracebacks.
• Add a confirmation/dry-run step for destructive operations (file deletion, network calls) to prevent accidental data loss.