No user-submitted related servers found.
Scored across 23 tools
Tool purposes are largely distinct: each list_* targets one clinical or administrative resource, and the auth/session pair (mah_auth_status, mah_sign_in, mah_verify_code) and patient pair (mah_list_patients, mah_set_active_patient, mah_get_patient_context) are clearly separated by descriptions. The only soft overlaps are mah_get_health_summary versus the individual lists (allergies, issues, meds) and the upcoming/past visit split, but descriptions make the boundary readable.
Nearly every tool follows the mah_ + verb_noun pattern (list_*, get_*, set_*, sign_in, verify_code, reply_message, send_verification_code), which is highly predictable. The exceptions are mah_auth_status and mah_healthcheck, which are noun/single-word forms, but these are minor deviations on an otherwise uniform scheme.
At 23 tools the surface is on the heavy side, but almost every entry maps to a genuinely different portal resource (test results, meds, immunizations, allergies, care team, insurance, billing, messages, visits, goals) plus a necessary auth/verification and patient-switching flow. Nothing looks redundant enough to cut, though grouping or trimming a few niche lists would help.
The read side is broad, but the surface is list-only for several resources: mah_list_test_results explicitly says individual result values live on a detail page for which no tool exists, and there is no equivalent detail fetch for visits, billing accounts, or messages. Write actions are also thin (only mah_reply_message) — no scheduling, refill request, or new message composition — leaving realistic patient workflows as dead ends.