Two tools with basic descriptions but significant schema and parameter documentation gaps. Tool names lack action verbs (codex, codex-reply are domain-specific but not verb-prefixed). Input schemas visible but lack type definitions for nested objects and parameter constraints. Descriptions are adequate (100-150 chars) but lack actionable guidance on when to use each tool vs. the other. No output schema documented. Error handling present in code but not surfaced in tool definitions. No parameter descriptions for config object fields (model_reasoning_effort values, constraints). Follows basic MCP structure but falls short of production-grade tool design.

• Rename tools to verb-prefixed names: 'submit_code_review' and 'continue_review_thread' (or 'send_review_prompt' and 'reply_to_review'). This makes intent clear without reading descriptions.
• Expand 'config' parameter schema to explicitly define nested fields: {type: 'object', properties: {model_reasoning_effort: {type: 'string', enum: ['ultra', 'max', 'xhigh', 'high'], description: '...'}}}. Remove enum values from description text.
• Document output schema in tool definitions: 'Returns {threadId: string, content: string, model: string, thinking?: string}' or similar. Specify whether content is plain text or markdown.
• Add parameter descriptions for 'model': 'Model name (glm-* names passed through; others default to ZHIPU_MODEL env var). If omitted in codex-reply, inherits from thread history.'
• Add error handling guidance to descriptions: 'May return HTTP 400 if model is unknown or thinking budget is invalid. Retries automatically if thinking field is rejected; returns error if retry fails.'

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

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