Cellog

View saved version →

---
name: shepherd-care
description: Use when the user wants to manage Cellog groups, members, roles, departments, people, care reports, comments, hearts, private notes, appointments or personal read state.
---

Use the connected Cellog MCP tools with the user's own OAuth account. All operations follow current membership, role, department and report-reader permissions. Administration alone does not grant access to all reports.

1. Start with `list_groups` and use the intended group's ID. Resolve ambiguity before accessing or saving records for the wrong group.
2. Use `list_people` to identify a person and `get_person` for their visible history. Use `list_members` for group leaders and `list_visits` for date or follow-up filters.
3. Follow `has_more` with the next offset when a complete list is needed. One page is not a complete group summary. A leader sees only records and people permitted by their account; an administrator may see the group.
4. Use `record_visit` only when the user asks to save a record. Resolve the person, visit date and type of care from the user's account and request. Do not invent a visit, name, prayer note or follow-up need. Ask for any required missing detail.
5. Use `list_departments` and `list_report_readers` to explain current access. The department on a visit is classification only; it never grants report access. `get_visit` reads an individual report without automatically marking it read.
6. For requested corrections/deletions, read the current object with `for_editing: true` first and pass its exact `updated_at` as `expected_updated_at` to `update_person`, `delete_person`, `update_visit`, `delete_visit`, `update_event`, `delete_event`, `save_private_note` or `delete_private_note`. Refresh after conflicts; never overwrite concurrent changes. Preserve fields the user did not ask to change. People can be added, renamed, archived/restored and deleted; only administrators can change the assigned leader. Report corrections/deletions are author-only.
7. Use `list_visit_comments`, `add_visit_comment`, `delete_visit_comment`, `list_visit_hearts` and `set_visit_heart` for requested feedback. Only explicit recipients or a higher role in a shared department can respond. Authors can read feedback but have no automatic response permission. Comment deletion and heart changes affect only the current user's responses.
8. Use `get_private_note` only when the user asks for their private notebook. `save_private_note` and `delete_private_note` affect only the current author's note for a person currently assigned to them. Even administrators cannot see other people's notes. Never fold private notes into reports, group summaries or CSV exports, and never copy them into shared schedules or comments without the user's specific sharing request.
9. Use `list_events`, `create_event`, `update_event` and `delete_event` for appointments. Default to private visibility. Group visibility shares the event with current members and requires the user's sharing request. Date/time values are local, not UTC instants. Only the author can change an event.
10. `list_visit_reads` and `mark_visit_read` manage only the requesting administrator/minister's own read state. Do not automatically mark a report read while summarizing a list; use the write tool only on request.
11. Use `create_group`, `join_group`, `rename_group`, `rotate_invite_group`, `set_display_name`, `set_member_role`, `set_member_department`, `remove_member` and `remove_report_reader` only for explicit user instructions. Role, department, invitation and membership changes affect access; describe the target and effect before making an ambiguous change. Never guess invitation codes. New report access uses roles/departments; the reader tool removes legacy assignments. Transfer administrator duties before leaving a group.
12. Briefly confirm the actual saved operation. Include a resource ID only when the user explicitly asks for it or needs it to identify the newly created record. 

Preview of the first 4,000 characters. Read full instructions →