Both tools have minimal descriptions (under 50 chars) and lack parameter documentation. get_scene_info has an empty input schema ({}), violating the requirement that every parameter needs a description. execute_code has a single 'code' parameter with a basic description but no constraints (length, format, safety warnings). Neither tool documents output schemas, error handling, or recovery guidance. No tool annotations (readOnlyHint/destructiveHint) despite clear risk differences. Naming is acceptable (verb_noun pattern), but definitions fall far short of production quality.

• Add output schema documentation for both tools. Example: get_scene_info should document returned fields (scene_name, object_count, frame_range, etc.) with types.
• Add input validation to execute_code: document max code length, timeout (e.g. 30s), and forbidden operations (e.g. 'cannot modify Blender UI thread'). Return actionable errors like 'Code execution timed out after 30s. Simplify or break into smaller steps.'
• Add tool annotations: mark get_scene_info with readOnlyHint=true; mark execute_code with destructiveHint=true to signal state modification.
• Example: 'Retrieve metadata about the active Blender scene including object count, frame range, and render settings. Use before modifying scene to understand current state.'
• Document error cases and recovery paths. Example: 'If code execution fails with SyntaxError, the agent should fix the code and retry. If it times out, suggest breaking the operation into smaller steps.'