Skip to main content
Glama
tracsoftllc

Planning Center Online MCP Server

by tracsoftllc

List / Search People

pco_list_people
Read-onlyIdempotent

Search and filter people in Planning Center People by name, status, gender, or age group to retrieve contact details and membership information.

Instructions

Search for and list people in Planning Center People (PCO).

Supports filtering by name, status, and more. Returns person records with attributes.

Args:

  • query (string, optional): Search by name (partial match on first or last name)

  • where_first_name (string, optional): Filter by exact first name

  • where_last_name (string, optional): Filter by exact last name

  • where_status (string, optional): Filter by membership status (e.g. 'active', 'inactive')

  • where_gender (string, optional): Filter by gender (e.g. 'M', 'F')

  • where_child (boolean, optional): Filter to only children (true) or adults (false)

  • include_emails (boolean, optional): Include email addresses in response

  • include_phone_numbers (boolean, optional): Include phone numbers in response

  • limit (number): Max results (1-100, default 25)

  • offset (number): Pagination offset (default 0)

  • response_format ('markdown' | 'json'): Output format (default: 'markdown')

Returns: List of people with name, status, gender, birthdate, created/updated dates. Error: Returns "Error: ..." message if the request fails.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
queryNoSearch by name (partial match)
where_first_nameNoFilter by exact first name
where_last_nameNoFilter by exact last name
where_statusNoFilter by membership status
where_genderNoFilter by gender (M or F)
where_childNoFilter to children (true) or adults (false)
include_emailsNoInclude email addresses in response
include_phone_numbersNoInclude phone numbers in response
limitNoMaximum number of results to return (1-100, default: 25)
offsetNoNumber of results to skip for pagination (default: 0)
response_formatNoOutput format: 'markdown' for human-readable or 'json' for machine-readablemarkdown
Behavior4/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already declare readOnlyHint=true, destructiveHint=false, openWorldHint=true, and idempotentHint=true, covering safety and idempotency. The description adds valuable behavioral context beyond annotations: it specifies the return format options (markdown/json), describes error behavior ('Returns "Error: ..." message if the request fails'), and mentions partial matching for name searches. However, it doesn't address rate limits, authentication requirements, or pagination details beyond offset/limit parameters.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is well-structured with a clear purpose statement followed by parameter documentation and return information. It's appropriately sized for an 11-parameter tool. However, the Args section is somewhat redundant with the schema, and the front-loaded purpose statement could be slightly more specific about the tool's primary use cases beyond just 'search and list'.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the tool's complexity (11 parameters, no output schema), the description provides good context: it explains the tool's purpose, documents all parameters (though redundantly), describes return values and error behavior. With comprehensive annotations covering safety and idempotency, and 100% schema coverage, the description fills important gaps about return formats and error handling. It could benefit from more guidance on when to use specific filters or how results are ordered.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100%, so the input schema already documents all parameters thoroughly with descriptions, constraints, and defaults. The description's Args section largely repeats what's in the schema (e.g., 'query (string, optional): Search by name (partial match on first or last name)' vs schema's 'Search by name (partial match)'). It adds minor clarification about partial matching applying to first or last name, but overall adds minimal value beyond the comprehensive schema.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool's purpose as 'Search for and list people in Planning Center People (PCO)' with specific verbs (search/list) and resource (people). It distinguishes from siblings like pco_get_person (singular retrieval) and pco_create_person (creation), but doesn't explicitly contrast with other list tools like pco_list_groups. The purpose is specific but sibling differentiation could be more explicit.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description implies usage through the mention of filtering capabilities ('Supports filtering by name, status, and more'), suggesting when this tool would be appropriate. However, it doesn't provide explicit guidance on when to use this versus alternatives like pco_get_person for single-person retrieval or pco_list_people_lists for different data. No exclusions or prerequisites are mentioned.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Install Server

Other Tools

Latest Blog Posts

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/tracsoftllc/PCO-MCP'

If you have feedback or need assistance with the MCP directory API, please join our Discord server