Server has 7 tools with explicit schemas and descriptions, but quality is uneven. Tool names follow verb_noun convention (list_, read_, post_, wait_, start_, cast_, get_) which is good. However, descriptions are verbose and often include implementation details (Postgres triggers, LISTEN/NOTIFY) rather than user-facing intent. Parameter descriptions exist but lack constraint documentation (enums, ranges, formats). Output schemas are partially documented in descriptions but not formally specified. Error handling is minimal, no recovery guidance or actionable error messages. The server is STDIO-only, which is a hard transport limitation.

• Rewrite descriptions to focus on user intent, not implementation. E.g. 'read_thread' should say 'Retrieve debate messages from a thread, ordered by ID, with pagination support' instead of detailing LISTEN/NOTIFY mechanics.
• Convert 'kind' and 'protocol' parameters to formal enum types in JSON Schema. Replace prose lists with structured constraints: {"enum": ["analisis", "critica", ...]}.
• Document output schemas formally. For each tool, add a 'returns' section specifying field names, types, and descriptions. E.g. read_thread returns {messages: [{id, thread, author, kind, body, artifact, created_at}], has_more: bool, max_id: int|null}.
• Add error handling documentation. For post_message, document: 'Raises ValueError if author not in registry or kind not in {analisis, critica, ...}. Returns clear error message with valid options.' Implement recovery hints: 'Call list_threads() to see available threads.'
• Add parameter constraints to descriptions. E.g. 'limit: maximum messages to return (1-1000, default 50)' and 'timeout_secs: wait duration in seconds (1-300, default 60)' instead of bare descriptions.