Server has 4 tools with explicit schema definitions visible in src/index.ts. Tool naming follows verb_noun pattern (analyze_context, think_aloud, plan_and_verify, execute_and_review), which is good. However, descriptions are present but relatively generic, they explain WHAT but lack WHEN to use and consequences. Schemas are well-structured with Zod validation, but descriptions of several parameters are vague or task-specific ('Invalid session ID format' is not helpful context for an LLM). The most critical gap: descriptions are good length (50-150 chars) but lack actionable guidance for LLM decision-making. Error handling strategy is not visible in the provided code, no recovery hints. All 4 tools have schemas, but composition is questionable: 'analyze_context' + 'think_aloud' + 'plan_and_verify' + 'execute_and_review' form a stateful workflow that requires sequential calls and session management, agents must know the exact choreography or risk failures. Output schemas are not documented.

• Document output schema for each tool. At minimum, list the fields returned and their types. E.g., analyze_context returns {analysis: {issues: Issue[], patterns: string[]}, confidence: number, session_id: string}.
• Rewrite tool descriptions to answer: WHAT does it do? WHEN should the LLM call it (vs. other tools)? WHAT does it return? Example for plan_and_verify: 'Submit code diffs for safety and style verification before applying to disk. Call this after analyze_context to identify issues, and before execute_and_review to apply changes. Returns confidence (0-100), identified issues, and required approval flag. Does NOT modify files.'
• Replace 'think_aloud' with a more standard name like 'add_reasoning' or 'add_thought_step' to improve clarity.
• Move validation error messages ('Thought cannot be empty') out of parameter descriptions. Validation belongs in the tool implementation. Use descriptions for actionable context: 'Free-form text capturing the LLM's reasoning at this step. E.g., "This function is too long, split into helper functions."'
• Document the required workflow sequence explicitly in each tool description or in a shared context. E.g., 'This tool is part of the Think → Plan → Execute workflow. Always call analyze_context first to establish a session_id, then think_aloud to record reasoning, then plan_and_verify to validate diffs, then execute_and_review to apply them.'
• Add enum constraint for 'phases' in plan_and_verify. Specify valid values in both the schema and description: 'Phases to verify: syntax, safety, style, performance. At least one required.'

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

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