Server exposes 7 tools with complete Zod schemas and detailed descriptions. Naming follows verb_noun convention (codex_generate_image, claude_web_search). Descriptions are substantive (100-250 chars), explaining WHAT, WHEN, and prerequisites. However, several parameters lack descriptions (e.g., codex_edit_image.instruction has only min(3) constraint, no description text). Output schemas are not documented, LLMs cannot predict response structure. Error handling uses a generic guard() wrapper that returns {ok, code, message} but lacks recovery guidance or error classification. No tool annotations (readOnlyHint/destructiveHint) despite clear risk levels (WRITE vs READ_ONLY). Parameter descriptions sometimes reference examples ('e.g. gpt-6-astra') which LLMs may reuse literally.

• Document output schemas for all 7 tools. Specify response structure: e.g., codex_generate_image returns {ok: true, path: string, size: string, tokens_used: number}. This enables LLMs to plan downstream calls and extract the right fields.
• Add explicit descriptions to all parameters. codex_edit_image.instruction should read: 'Natural language instruction describing the edit (e.g., remove background, add objects, change style). Min 3 characters.'
• Add tool annotations to schema. Mark codex_generate_image, codex_edit_image, codex_run, claude_run with destructiveHint: true. Mark read-only tools with readOnlyHint: true. This signals safety to LLMs without requiring description parsing.
• Enhance error responses with recovery guidance. Instead of {ok: false, code: 'invalid_input', message: e.message}, return {ok: false, code: 'invalid_input', message: '...', retryable: false, suggestion: 'Check that out_dir is an absolute path and writable.'}
• Replace example model names with enum constraints or a discovery tool. Instead of 'e.g. gpt-6-astra', provide an enum of valid models or a list_available_models tool so LLMs pick from actual options.