codex-async-mcp defines 6 tools with reasonable names and descriptions, but has significant gaps in schema completeness, parameter validation guidance, and error handling. All tools have descriptions (10-50 words), but most parameter descriptions are minimal (5-15 words) and lack validation constraints. Input schemas are present but sparse, no enums, patterns, or range constraints despite parameters that could benefit from them (e.g., status filter in list_jobs, event_types in get_job_events). Error handling guidance is absent; tools do not document retryability, failure modes, or recovery paths. Output schemas are not documented. Most tools appear well-named and start with action verbs (get_, list_, start_, continue_, cancel_), but descriptions lack WHEN to use each tool and dependencies between them. This is a typical mid-tier community server.

• Document the return schema for every tool in a structured format. Example for get_job_status: 'Returns {job_id: string, status: "pending"|"running"|"completed"|"failed", result: object|null, error: string|null, created_at: ISO8601, updated_at: ISO8601}'.
• Replace free-form parameter descriptions with constraint-aware ones. Example: change 'Optional model to use' to 'Optional model name (string, alphanumeric, max 50 chars; valid values: claude-opus, claude-sonnet, gpt-4-turbo; defaults to claude-opus if omitted)'.
• Add enums for parameters with known values. Define model, profile, sandbox, status, event_types as enum fields in the schema with explicit allowed values.
• Document pagination for list_jobs and get_job_events. Specify default limit (e.g., 20), max limit (e.g., 100), and pagination mechanism (cursor-based? offset-based?). Return total_count or next_cursor in results.
• Add error handling guidance to each tool description. Example: 'Returns 404 if job_id not found (try list_jobs to discover valid IDs); returns 409 if job is not in a cancellable state (check status via get_job_status first).'
• Clarify tool composition: document which tool to call first (start_codex_job), how to monitor progress (get_job_status or get_job_events), when to continue (continue_codex_job requires completed state?), and when to cancel.
• Expand tool descriptions to 50 - 200 characters, following the rubric baseline. Include WHAT, WHEN, and any prerequisites or side effects.
• Add parameter defaults and ranges to numeric parameters. Example: 'limit (integer, default 20, min 1, max 100)' instead of 'Optional limit on number of jobs'.

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

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