This server has significant definition quality gaps. Tool descriptions are present but generic (avg ~40 chars, well below the 194-char baseline). Parameter schemas lack type information for complex objects (e.g., 'project' and 'context' params are typed as bare 'object' with no nested schema). No enum constraints on string parameters like 'model' or 'context_type'. Error handling is absent, no recovery guidance, no actionable error messages. Tool names are reasonable (verb_noun pattern) but lack clarity on overlapping concerns (generate_response vs generate_ai_response). Output schemas are undocumented. No tool annotations (readOnlyHint, destructiveHint). Pagination is partially implemented but inconsistently applied.

• Expand all object parameter schemas to include nested properties with types and descriptions. E.g., 'project' should define {name: string, description: string, ...} with constraints (name length, required fields).
• Consolidate generate_response and generate_ai_response into a single tool with a unified parameter set. Document which parameters are optional and their defaults.
• Add enum constraints to 'model' parameter. Call get_available_models first to populate the enum, or hardcode known models (gpt-4, claude-3, local-model) with descriptions.
• Add confirmation/dry-run support to delete_project and delete_context. E.g., add 'confirm: bool' parameter and document cascade behavior (do child contexts get deleted?).
• Document output schemas for all tools. Add a 'Returns' section to each description listing key fields (id, name, created_at, etc.) and their types. Include pagination metadata (total_count, next_cursor) for list endpoints.

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

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