Server has 7 tools with mixed quality. Tool names follow verb_noun convention (apply_modifier, append_from_blend, project_save/load/resume/status, start_debug_server), which is good. However, descriptions are minimal (10-50 chars) and lack context on WHEN to use tools or WHAT they return. No input parameter descriptions visible in the provided schema excerpts, only parameter names and types. Output schemas are not documented. Project tools (save/load/resume/status) lack clarity on their interdependencies and use cases. Error handling and recovery guidance are absent. The framework appears to delegate tool registration to dcc-mcp-core, so actual schema completeness cannot be fully verified from this codebase alone.

• Add 50 - 200 character descriptions to every tool. Include WHAT it does, WHEN to use it (vs similar tools), and WHAT it returns. Example: 'Apply a modifier permanently to a mesh object. Use this after creating a modifier to bake its effects into the geometry. Returns the modified mesh name and vertex count.'
• Document every input parameter with a description explaining its purpose, valid range, format, and any constraints. Example: 'object_name (string): Name of the mesh object in the current Blender scene. Must exist and be of type MESH.'
• Document output schemas for all tools. Specify field names, types, and what each field represents. Example: project_status should return {scene_path: string, active_skills: [string], checkpoint_ids: [string], ...}.
• Clarify the project tool workflow. Add descriptions explaining: project_status is a read-only snapshot; project_resume returns rehydration data for agent state recovery; project_save persists to disk; project_load restores from disk. Explain when to call each.
• Add error handling guidance to tool descriptions. Example: 'If the modifier does not exist, returns error code MODIFIER_NOT_FOUND. If the object is not a mesh, returns INVALID_OBJECT_TYPE. Retry is safe for transient errors; user must fix invalid inputs.'