OpenReality MCP presents a moderately well-structured tool set for 3D scene manipulation and robotics workflows. Tool naming follows verb_noun conventions consistently (workspace_list_scenes, scene_locate_object_3d, agent_run). Input schemas are complete and well-typed across all 17 tools, with proper use of enums (e.g., export_dataset's format enum) and array constraints (scene_search_objects, scene_infer_spatial_relations). However, descriptions are uniformly terse (averaging ~45 chars, well below the 194-char production baseline), lacking context about WHEN to use each tool, prerequisites, or recovery guidance. Error handling is present (ApiError wrapper in toolkit.ts shows structured error surfacing), but descriptions do not guide LLM recovery. Parameter descriptions are minimal, many are one-line restatements of the name (e.g., 'The scene ID' for scene_id). No explicit output schemas are documented, forcing LLMs to infer response structure. The server demonstrates solid engineering (Zod validation, proper HTTP abstraction, guard pattern for error isolation), but falls short of production-grade agent optimization.

• Expand ALL tool descriptions to 100-200 characters, answering: What does it do? WHEN should the LLM call it instead of similar tools (e.g., scene_card vs scene_list_objects)? What does it return? Example: 'Get detailed scene metadata including object count, mesh status, and preview image. Call this after creating a scene (workspace_upload_scan) or when you need scene summary before querying objects. Returns: scene metadata object with fields {id, name, object_count, preview_url, mesh_available, created_at, status}.'
• Add min/max bounds to ALL numeric parameters. E.g., workspace_job_wait: 'Timeout in seconds (1-3600, default 900)' and 'Poll interval in seconds (0.1-30, default 2)'. scene_list_objects: 'Maximum number of objects to return (1-1000, default 100)'. agent_run: 'Maximum agent iterations (1-50, default 10)'.
• Document query format for scene_search_objects and scene_infer_spatial_relations. Specify: 'Queries are natural-language object descriptions (e.g., "red cube", "cylindrical handle") or semantic class names (e.g., "mug", "drawer"). See scene_card to discover available object classes in the scene.'
• Add coordinate system and units documentation to scene_measure_distance and scene_plan_path. E.g., 'Points are [x, y, z] coordinates in SLAM units (typically centimeters). Use scene_card's metric_scale field to convert to real-world meters if needed.'
• Document output schemas explicitly for all tools. Create a separate 'Output Schema' section in each tool's description or define a returns field. E.g., scene_card returns: '{id: string, name: string, object_count: int, preview_url: string, mesh_available: bool, created_at: ISO8601, status: string}'. workspace_list_scenes returns: '{scenes: [{id, name, created_at, object_count}], total: int, next_cursor?: string}'.