All seven abilities are read-only. Deliberately not exposed: private messages (messages_get_threads) and friend connections (friends_get_friend_user_ids), a different risk category to group, activity and directory metadata.
Finding a group’s admin name and email is a two-call round trip, usable from any subsite connector:
// 1. Resolve the group and get admin user ID(s)
{ "tool": "lh-mcp-buddypress-queries/get-group", "params": { "slug": "sugar-gliders" } }
// -> admin_ids: [7407]
// 2. Get that admin's name and email
{ "tool": "lh-mcp-buddypress-queries/get-group-members", "params": { "group_id": 21, "role": "admin" } }
// -> name and email of the group adminplugins_loaded (no bp_loaded dependency, unlike lh-buddypress-group-taxonomies) since it has no BuddyPress-specific class loading order requirements. Every execute callback guards with function_exists()/class_exists() checks instead, since BuddyPress itself may not be fully loaded at plugins_loaded time on every request path.wp_register_ability()/wp_register_ability_category() require that version.list-groups and get-groups-by-taxonomy (in the taxonomy plugin) share the same status-filter-after-fetch pattern, since BuddyPress core doesn’t yet support filtering groups_get_groups() by a list of statuses directly.get-group-activity passes the group to bp_activity_get() in its filter argument (object: groups, primary_id) with show_hidden on, so private and hidden groups’ activity is included. Before 2.2.1 the group was passed as top-level arguments, which BuddyPress ignores, so every group returned the network’s latest activity.lh-buddypress-queries to lh-mcp-buddypress-queries in v2.0.0, a breaking change for anything calling the old ability names directly.get-groups-by-taxonomy, list-terms, list-group-taxonomies)lh-membership: taxonomy-based (not directory-based) member listing, same edit_users capability precedent for email-bearing abilities