Critical gaps across all dimensions. Tool definitions lack input schemas (cannot verify from source), descriptions are minimal (10-50 chars, well below 50-200 char baseline), and no parameter descriptions visible. Two tools (resilience_admit_frontier, resilience_submit_attempt) have no description at all. No output schemas documented. Error handling and recovery guidance absent. Naming uses underscores but lacks clarity on intent (e.g., 'resilience_transition_once' is cryptic). No evidence of idempotency, pagination, or composition patterns. This server appears to expose internal system APIs without agent-friendly wrapping.

• Add explicit input schemas to all tools with parameter types (string, number, boolean, enum), descriptions (50-100 chars each), and constraints (min/max, regex, enum values). Example: channelId should be 'string, 1-256 chars, alphanumeric + hyphens'.
• Rewrite tool descriptions to 50-200 chars following the pattern: WHAT (verb + object) + WHEN (use case) + RETURN (key fields). E.g., 'Read all messages in a channel. Use this to retrieve conversation history before posting. Returns: messages array with id, author, timestamp, text.'
• Document output schemas for all tools. Specify field names, types, and whether pagination is supported. For list tools, include total_count or next_cursor and enforce a max result limit (20-50 items).
• Rename resilience_* tools to clarify intent: 'resilience_admit_frontier' → 'queue_task_for_execution' or 'submit_task_to_frontier'; 'resilience_transition_once' → 'advance_task_state' or 'process_next_task_step'; 'resilience_page_outbox' → 'list_outbox_messages'.
• Add error handling guidance. For each tool, document what can fail (e.g., 'Channel not found', 'Task already completed') and what the LLM should do next (retry, ask user, call alternative tool).