Server exposes 7 well-named, read-only tools with clear descriptions (avg 180 chars, within baseline 194). All tools have verb-noun naming (get_*, draft_*). Descriptions are LLM-optimized and include context on when to call each tool. However, input schemas are minimal or absent for 5 of 7 tools (get_availability, get_contact, get_flagship, get_also_building, get_offerings, get_mosaic_bridge_stats all have empty input {}). Only draft_intro_email has a proper schema with 4 typed parameters. Output schemas are not documented in code, inferred from type definitions but not exposed to the LLM. Error handling is basic (fetch failures throw, no recovery guidance). No tool annotations (readOnlyHint, idempotentHint) despite all being read-only. Composition is sound: each tool has one responsibility, names are distinct, and draft_intro_email chains naturally after discovery tools.

• Add explicit output schemas to all 7 tools. Register each tool with a 'result' or 'outputSchema' field documenting the response structure (e.g., for get_availability: {status: string, open_to: string[], response_time: string, as_of: string}).
• Add tool annotations: set readOnlyHint=true and idempotentHint=true on all 7 tools to signal to LLMs that they are safe to retry and do not modify state.
• Enhance error messages with recovery guidance. Replace 'Failed to fetch https://alsotari.online/about.json: 503 Service Unavailable' with 'Failed to fetch profile (service temporarily unavailable). Try again in 30 seconds, or contact [email protected] if the issue persists.'
• Document draft_intro_email parameter constraints: from_name (1-100 chars), problem (10-500 chars), constraint (0-200 chars, optional), outcome (10-500 chars). Add a note: 'Email will be drafted in professional business tone.'
• Consider adding a get_profile tool that returns a summary (name, headline, location, availability status, contact email) as a lightweight discovery entry point before calling more specific tools.