Legax MCP server provides 5 tools with generally well-structured schemas and descriptions. Tools are named with action verbs (send, poll, request, approve, show status) which follow the verb_noun pattern. Input schemas are present and include type definitions, enums, and property descriptions. However, descriptions vary in quality and completeness, some lack sufficient context for LLM decision-making. Parameter descriptions are present but uneven; some parameters have rich descriptions (e.g., 'kind' with enum values) while others are minimal. Output schemas are not documented anywhere, making it difficult for agents to reason about what fields to expect. Error handling guidance is absent from all tool descriptions. The server follows tool composition principles reasonably well (each tool has a focused responsibility), but lacks error recovery patterns and lacks explicit guidance on when to use each tool vs. alternatives.

• Define explicit input schema for approval_prompt with required parameters and type constraints. Remove additionalProperties=true or justify why flexible input is necessary.
• Expand approval_prompt description to 100 - 200 characters explaining: What does it do? When to use vs. legax_request_permission? What does it return? Example: 'Send an approval prompt to a paired phone device and wait for user decision. Use for immediate, high-priority permissions. Returns {approved: boolean, timestamp: string}.'
• Document output schemas for all 5 tools. Include in descriptions or as a separate schema appendix. Example for legax_poll: 'Returns {replies: [{timestamp, agentId, message}], decisions: [{requestId, approved, timestamp}]}'.
• Add error recovery guidance to each tool description. Example for legax_send: 'On timeout (network down), retry with exponential backoff. On 'transport not found', ensure relay is running via legax_status.'
• Expand legax_status description and explain the structure of 'transports' and 'pending' it returns. Document when to call it diagnostically.
• Add parameter-level guidance on dependencies. E.g., in legax_poll: 'If both sessionId and agentId are omitted, polls all agents; if sessionId provided, agentId is optional and filters further.'
• Consider adding a discovery tool (e.g., list_transports) to let agents discover available relay transports without calling legax_status.