CiviCRM MCP by usefulapi

Each tool maps to a distinct resource+action: list_* per entity, get_contact by id vs search_contacts by word, and create/add/record/register/log writes are clearly separated per domain object. The only potential overlap is civicrm_query vs the typed list_* tools, but its description explicitly frames it as the generic read fallback and warns to use list_entities/get_fields for names, so boundaries remain clear.

Every tool uses a uniform civicrm_ prefix with snake_case verb_noun naming (list_contributions, get_contact, create_membership, update_contact, search_contacts). The verbs vary (add, log, record, register) but each variation is motivated by the action's semantics rather than inconsistent convention, and civicrm_whoami is an idiomatic, unambiguous special case.

24 tools is at the high end of the comfortable range, but the count is driven by genuine domain breadth (contacts, groups, contributions, memberships, events, participants, activities, cases, relationships, notes) plus two generic introspection helpers. Each tool covers a real CiviCRM entity/action, though a few read tools could plausibly be folded into civicrm_query.

Read coverage is excellent and core write workflows (contact create/update, note, group membership, contribution, membership, participant, activity) exist, but there are no delete or removal operations anywhere, no update for contributions/memberships/events/participants, and no way to create events or groups. Agents hitting a correction or cleanup task will hit a dead end since civicrm_query is explicitly read-only.