Planning Center

Search events configured in Check-Ins (e.g. Sunday Service, Wednesday VBS). Returns events that are set up for check-in — not Calendar events, Services plans, or Registrations signups. Events may be native to Check-Ins or auto-created from a Registrations signup. To find the Check-Ins event spawned by a specific signup, pass the signup's event id as `registration_event_id`. (Going the other direction — a Check-Ins event back to its source signup — is not exposed on this endpoint.)

check_ins_events

Search manually-recorded headcount tallies for Check-Ins event times — counts that staff explicitly entered in the Headcounts app (e.g. "9am service / Adults = 187"). Each row pairs one event_time with one attendance_type and a total. An absent row may mean the count was zero. Use this only for explicit-tally counts. For attendance derived from individual people scanning in at a station, use `check_ins_check_ins` and aggregate. For who is *scheduled* on a service team for that service time, use `services_plans` instead. Pass `event_time_id` (an id from `check_ins_event_times`) to scope tallies to one session — the direct way to read or compare specific sessions (9am vs 11am). Headcount itself is only queryable by `created_at` / `updated_at`, so a time-window prompt ("last Sunday's 9am service") still means finding the session in `check_ins_event_times` first (by its `starts_at`) and passing its `event_time_id` here. Attendance-type names come from the included `attendance_type` resource (included by default); there is no separate MCP tool that lists attendance types, so this include is the only source of attendance-type names.

check_ins_headcounts

Search check-in locations configured for a single Check-Ins event — rooms, age groups, and other places people check in to. Each location has age, grade, and gender gating that determines who's allowed to check in there. Requires an `event_id`; look one up with `check_ins_events`. Some locations have `kind="Folder"`, meaning they don't accept check-ins themselves — they contain other locations. Use `include=locations` to descend into a folder's children and `include=parent` to walk back up. To drop folders and return only check-in-able locations, pass `filter="locations"`; to keep only top-level entries (no parent folder), pass `filter="root"`. Note: Check-Ins locations are distinct from Calendar resources (physically bookable spaces like the sanctuary) — if a prompt says "rooms," confirm which is meant.

check_ins_locations

Get the refund on a single donation in Planning Center Giving - the amount refunded, the payment processing fee returned, and when the refund was processed. A donation has at most one refund. Requires a donation ID, so reach for this when a specific donation is already in hand and the question needs the refund record's own fields (the refund fee, the exact time the refund was processed). For aggregate questions like "how much did we refund last month?", use giving_donations to find refunded donations instead. A not-found result means the donation has no refund, the donation ID is invalid, or you don't have permission to manage donations in Giving (administrator or bookkeeper).

giving_refunds

List giving batch groups — optional, customizable collections of giving batches that share common characteristics. Each group carries `total_cents`/`total_currency` totals and a `committed`/`status` state (`uncommitted`, `updating`, or `committed`), and committing a group commits all of its batches and donations. Limit to `committed` or `in_progress` (uncommitted) groups, find a group by a partial match on its `description`, narrow by `updated_at` range, include the `owner` (the Giving admin who created it), and sort by `updated_at`. Use `giving_batches` to drill into the individual batches within a group.

giving_batch_groups

Search donations in Planning Center Giving - the individual gifts a church has received, with the amount, how it was paid, when it arrived, and whether it was refunded. All money is in cents (`amount_cents` 5000 is $50.00). `received_at` is the business date a gift counts toward and what the Giving admin UI filters on - prefer it over `created_at`, which is when the record was entered. Searches the whole organization by default. Pass at most one of `person_id` (one donor's giving history), `batch_id` (the gifts in one batch), or `campus_id` - none of these is filterable org-wide, so scoping to one changes which endpoint is used. A donation carries a single total with no fund attribution of its own: include `designations.fund` to see which funds a gift was split across, or filter by `fund_id` to answer "how much came into one fund". For totals, set `include_totals` - the response `meta` then carries `received_total_amount_cents` across everything matching the filters, ignoring pagination. Use it rather than paging through results to sum them by hand.

giving_donations

Per-donor giving totals in Planning Center Giving. Each row is one person who gave inside a date range, with their total, how many donations it came from, and when they first ever gave. Set `received_at_start` and `received_at_end` to the window you mean. The applied window isn't echoed back, so name the range you used. There is no combined household row. Each person in a couple is their own row with their own total, so a couple's combined giving means fetching both and adding `total_received_donation_amount_cents` yourself. Read `total_received_donation_amount_cents` with `total_received_donation_amount_currency`; it is in that currency's minor units. `donation_count` includes refunded and failed donations while the total counts only what was received, so the two don't divide into an average gift. `first_donated` is the lifetime first gift, not the first inside the range, and can be null even for someone with donations — a missing value doesn't mean they never gave. Rows carry no `links.html`, so don't promise a donor a page or construct a URL for one. For what someone committed to give rather than what they gave, use giving_pledges.

giving_donors

List giving batches — groupings of donations. A batch starts uncommitted (`status` `in_progress`), acting as a staging area where its donations aren't yet visible to donors, and becomes visible once committed (`status` `committed`, with a `committed_at` timestamp). Each batch carries `total_cents`/`total_currency` totals (and `donations_count` on request). Filter to `committed` or `in_progress` batches, narrow by `updated_at` or `committed_at` range, and include the `batch_group` it belongs to or its `owner` (the Giving admin who created it). Sort by `committed_at` to surface the most recently committed batches.

giving_batches

List the giving funds configured for the organization. Funds track the intent of a donation (e.g. "General", "Building", "Missions") and let donors allocate gifts to a specific cause. Use `default: true` to find the organization's default fund.

giving_funds

List the payment sources configured for the organization. A payment source is the platform a donation originated from — donations made through Giving carry the built-in "Planning Center" source, while donations imported from an external platform (Stripe, Pushpay, Tithe.ly, etc.) carry a source identifying that platform. This is organization-level configuration only and returns no donor or donation data. `status` is either `active` or `archived`. Archived sources can't be assigned to new donations, but their historical donations are retained. One exception: the built-in "Planning Center" source returns `status` as the number `0` (meaning active) and returns no `created_at`/`updated_at` — treat it as always-active and always-present rather than filtering on those fields. `payment_source_type` is only returned by organizations that have that feature enabled, so it may be absent from results. In practice organizations have a handful of sources. The endpoint offers no filters or sorting, so narrow the results yourself after fetching. `giving_donations` can't filter by payment source, but each donation carries its `payment_source` relationship — to split totals by source, group the donations by that id and match it against the sources here.

giving_payment_sources

List pledge campaigns in Planning Center Giving — long-term commitment drives toward a goal (a building campaign, a missions push). Each campaign carries its `goal_cents` target and two running totals: `received_total_from_pledges_cents` (gifts that closed against a pledge) and `received_total_outside_of_pledges_cents` (gifts to the same fund with no pledge behind them). Reach for this for campaign-level progress questions like "how are we tracking against the building campaign goal?" Each campaign belongs to a fund. Filter by `fund_id` to find every campaign supporting a specific fund (look the fund up with giving_funds first), or include `fund` to see its name alongside each campaign. This tool returns campaign-level aggregates only — for the individual pledges behind a campaign, use giving_pledges. There is no "active" filter, so compose one from the date bounds — and set **both** together, not just one. A campaign is active when it has started and has not yet ended, so send `starts_at_end` = today (started on or before today) **and** `ends_at_start` = today (ends on or after today) in the same call. Sending only one bound returns campaigns that may already be over or not yet started, not active ones. To surface the campaigns wrapping up soonest, sort by `ends_at` ascending with no date bounds — that is a separate question from "active", so don't add the date filters unless the user asked only for active campaigns.

giving_pledge_campaigns

Look up pledges in Planning Center Giving - a person's commitment to give a set amount toward a pledge campaign, alongside how much they have actually donated against that commitment so far. Provide exactly one of `person_id` (the pledges one person has made) or `pledge_campaign_id` (everyone who pledged to one campaign). Each pledge carries `amount_cents` (the amount committed) and `donated_total_cents` (the amount delivered so far). To find donors who are behind on their commitments, compare those two fields on the returned records - there is no server-side filter for it, so the arithmetic has to be done here. When the pledger belongs to a joint giving unit - the "and Jane" half of "John and Jane pledged $5,000" - `joint_giver_amount_cents` and `joint_giver_donated_total_cents` carry that second person's amounts; both are 0 otherwise. Include `joint_giver` to see who they are.

giving_pledges

Look up recurring donations in Planning Center Giving - a donor's scheduled, repeating gift (weekly, monthly, etc.), including the amount, the schedule, when the last gift came in, and when the next one is due. Recurring donations are read-only. Reach for this for questions about scheduled future giving ("who gives monthly?", "whose recurring gift is paused?", "what is this person's recurring gift?"). For gifts that have actually been received, use giving_donations instead. `status` is `active`, `indefinite_hold` (paused with no end date), or `temporary_hold` (paused until `release_hold_at`). Include `designations` to see how a recurring gift is split across funds. Each designation carries its fund as a relationship id, so use giving_funds to get fund names. The donor is likewise returned as a person id - use people_search to resolve names. `amount_cents` on the gift is its total across every fund it is split between, so it does not answer how much goes to one fund. For that, include `designations` and read the amount on the designation whose `fund` is the one in question.

giving_recurring_donations

Look up individual attendance records for a single event in Planning Center Groups - whether each person attended and their role (member, leader, visitor, or applicant) at the time of the event.

groups_event_attendances

Search events in Planning Center Groups. An event is a single meeting of a group with a start and end time, an optional location, and a cancellation status. By default this searches events across every group in the organization. Provide `group_id` or `person_id` to list events for a specific group or person.

groups_events

Search for groups. Groups are collections of people that meet together regularly (small groups, classes, Bible studies, etc.). Returns details like name, description, schedule, contact email, and membership count. Use `groups_group_types` to look up the categories that groups belong to. `memberships_count` counts memberships in that one group, visitors included. Summing it across groups double-counts people in more than one; to count unique people, use `groups_memberships`.

groups_search

Look up group memberships in Planning Center Groups - the association of a person to a group, with the member's role and the date they joined. Provide exactly one of `group_id` (to list a group's members) or `person_id` (to list the groups a person belongs to). Only leaders and members are returned. To count unique people across groups, call this once per group with `include: person`, then dedupe by person id - a person can be in several groups.

groups_memberships

List or fetch group type categories (e.g. "Small Groups", "Classes") from Planning Center Groups. Group types define the default settings, visibility, and color theme for the groups within them.

groups_group_types

Record a submission to a people form, for submissions captured outside of Church Center (e.g. a paper form). The caller must be able to manage the target form. Identify the submitter with either person_id (an existing person) or person_attributes (matched to an existing profile by name + email, or used to create a new person). Provide exactly one of the two. Pass each answer in values, referencing a form_field_id on the form. The shape of value depends on the field's type, so use people_form_fields (include options) to discover each field's id, type, and option ids before submitting (the value field documents the exact shapes). Use people_forms to find the form and people_form_submissions to read existing submissions. IMPORTANT: Submit only answers supplied by the user, or values they explicitly asked you to look up. Never infer, guess, or fabricate a value -- if a required field's value is unknown, ask the user rather than supplying a placeholder. Submitting triggers the same side effects as a Church Center submission: notification and confirmation emails, workflow cards, and profile updates.

people_form_submissions_create

Create a note on a person's profile. A note is text filed under a note category and attached to a specific person. Use this to record a note about someone; use people_notes to read existing notes and people_note_categories to discover which category to file the note under.

people_notes_create

Get information about the authenticated user's organization.

people_current_organization

Search for background checks. Optionally filter by a specific person using `person_id`. Current denotes the background check that best represents a person's current standing

people_background_checks

List the church campuses (physical sites) configured for the organization. The returned campus IDs are what the `campus_id`/`campus_ids` filters on other tools (e.g. `people_search`, `groups_search`) expect.

people_church_campuses

Search custom field data — the actual values of custom fields on people's profiles. Each field datum is tied to a field definition (`people_field_definitions`), which belongs to a custom tab (`people_tabs`). Use this tool to look up the values of custom fields for people.

people_field_data

Search the custom field definitions configured for the organization. A field definition represents a custom field — its name, data type, sequence, and which tab (`people_tabs`) it belongs to. Use this to discover what custom fields exist on people profiles, then read a person's values with `people_field_data`. Related: include `field_options` to retrieve the available choices for dropdown or checkbox fields.

people_field_definitions

Search people custom tabs. A tab groups field definitions on the profile (e.g., 'Volunteer Info', 'Church Info'). Tabs contain field definitions (`people_field_definitions`), which describe the custom fields whose per-person values come from `people_field_data`.

people_tabs

Search the fields that make up a specific people form. Each form field describes a single input on the form, including its label, field type, whether it is required, and its display order. Requires a `form_id` (find one via `people_forms`). Use this to understand a form's structure before reading its submissions with `people_form_submissions` or recording one with `people_form_submissions_create`.

people_form_fields

Search for people form submissions. A form submission represents an individual person's response to a specific people form. Use `people_form_fields` to see the questions that make up the form.

people_form_submissions

Search for people forms. Forms is a tool for gathering information from people via customizable online forms.

people_forms

Search households — groups of people who live together (typically a family), each with a primary contact. Filter by household or primary-contact name, and `include` the member people. To find an individual person, use `people_search`.

people_households

Retrieves the people that appear in a specific Planning Center People list. Requires a `list_id` (find one via `people_lists`).

people_list_results

Search for people lists. A list is a powerful tool for finding and grouping people together. To get the people in a list, use `people_list_results`.

people_lists

Search note categories in Planning Center People. Note categories organize and classify notes on people profiles. Use this tool to find available note categories by name.

people_note_categories

Search for notes attached to people's profiles. A note is text with a category connected to a person's profile.

people_notes

Search for people by name, contact info, status, campus, membership, and more.

people_search

Search people workflow cards. Cards are workflow steps that are assigned to a staff member to perform for a specific person. Requires a `workflow_id` (find one via `people_workflows`).

people_workflow_cards

Search the categories that organize people workflows. Use this to find a category by name; then filter `people_workflows` by its `workflow_category_id`.

people_workflow_categories

Search for people workflows. A workflow consists of a series of steps to complete a specific task (e.g. Baptism Interest would entail scheduling a meeting, provide learning materials, assign dates, etc.). Steps consist of cards that are a step that is assigned to a staff member to perform for a specific person. Use `people_workflow_cards` for the per-person cards within a workflow, and `people_workflow_categories` for the categories that group workflows.

people_workflows

Church Center viewership statistics for the episodes in a single Publishing channel. Returns one entry per episode with its Church Center live watch count (live_watch_count), library watch count (library_watch_count), and a per-EpisodeTime breakdown (times, each carrying its own watch_count). Counts are Church Center plays only. Views on YouTube, Vimeo, Facebook, or other external platforms are NOT included — this mirrors the per-episode statistics panel the Publishing admin sees. This tool takes a channel_id. First call `publishing_channels` to pick the relevant channel (typically the main Sunday channel), then call this tool with that channel's id. Answer questions like "most-watched episodes this month" or "average listen count per episode" by fetching a channel's statistics and aggregating client-side — do NOT fan out per episode. Aggregates cover only the episodes you have fetched, so set `per_page` to 100 and keep paging with `page_after` until `has_more` is false before summarizing. Use `type` and the after/before date range to narrow server-side: `type: "live"` bounds by when episodes were published live, `type: "library"` bounds by when they were added to the library, and omitting `type` returns episodes matching either. `after` is an inclusive lower bound (includes the whole named day). `before` is an exclusive upper bound: it cuts off at the start of the named day, so episodes published on the `before` date itself are NOT included. Both are YYYY-MM-DD.

publishing_episode_statistics

Search sermon channels in Planning Center Publishing. A "channel" is a top-level content grouping for sermons (e.g. "Sunday Morning", "Wednesday Bible Study"). Each channel carries its own feature flags (enable_audio, enable_on_demand_video, enable_watch_live, general_chat_enabled/group_chat_enabled, sermon_notes_enabled, podcast configuration) and a lifecycle pair (published, archived). This is the foundational Publishing tool. `publishing_episode_statistics` requires a channel id from here. `publishing_episodes` and `publishing_series` can't filter by channel — request their `channel` include and group by it client-side. For lifecycle questions ("is this channel published or archived?", "show me archived channels") use the `filter` param (archived, not_archived, published, podcast_enabled) rather than fetching every channel and inspecting the published/archived attributes yourself — the filter dispatches server-side. Pass multiple values to combine scopes, e.g. `["published", "podcast_enabled"]` for published channels with podcasting enabled. A channel's `services_service_type_remote_identifier` links it to a Planning Center Services service type. To answer "which channel is paired with our Sunday 9am service type?", call `services_service_types` first to find that service type's id, then match it against a channel's `services_service_type_remote_identifier` here. `general_chat_enabled`/`group_chat_enabled` read `false` both when chat is off and when the org lacks a Groups subscription; check `can_enable_chat` to tell those two cases apart.

publishing_channels