openmanus_bridge has a reasonable schema with typed parameters and enums, but lacks actionable descriptions for most parameters. discover_skills, get_skill_content, and list_gpus have minimal or missing descriptions (under 20 chars for some). No output schemas documented. Error handling guidance absent. Tool names are verb-noun but descriptions do not explain WHEN to use each tool or what happens on failure. Parameter descriptions are generic ('Prompt text', 'Skill identifier') without format constraints or examples of valid input.

• Add output schemas for all tools. Document the structure of discover_skills (e.g., returns array of {skill_id, name, description}), get_skill_content (returns {skill_id, content, metadata}), and list_gpus (returns array of {device_id, name, memory_gb, compute_capability}).
• Expand tool descriptions to 100 - 200 characters. For discover_skills: 'List all available skills from the OpenManus catalog. Call this first to discover what skills exist before retrieving their content with get_skill_content.'
• Add min/max bounds and format constraints to openmanus_bridge parameters. E.g., timeout_s: 'Timeout in seconds (1 - 3600, default 30)'; prompt: 'Prompt text (max 10000 chars, UTF-8 encoded)'.
• Document error scenarios and recovery paths. E.g., 'If job_id is not found, returns error code JOB_NOT_FOUND. Retry with a valid job_id from a prior run_prompt_async call.'
• Consider splitting openmanus_bridge into separate tools: run_prompt, run_prompt_async, get_job_status, validate_prompt, get_status. This enables agents to compose operations without conditional logic.

Inferred effective spec: <=2025-11-25.

• Relies on Logging (deprecated) - log to stderr or use OpenTelemetry