Planning Center MCP Server and API by Cotlet

List unconfirmed volunteers in Planning Center

planning_center_list_unconfirmed_volunteers

Read-onlyIdempotent

List unconfirmed volunteers in the user's own Planning Center account from ChatGPT, Claude or any AI agent. Returns how to do it in Planning Center step by step (screens, buttons, fields) and opens nothing by itself; then do it with the cotlet_browser_* tools in the user's Planning Center Cloud Browser. Planning Center's official API: Planning Center has a full REST API for Calendar, Check-Ins, Giving, Groups, People and Services, and since August 2026 an official MCP server, but the MCP is mostly read-only (checked 22 Oct 2026).

Tool call template

This tool declares no required parameters. Add optional parameters from the input schema as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {},
    "name": "planning_center_list_unconfirmed_volunteers"
  }
}

Input Schema

Name	Required	Description	Default
No arguments

Schema Changelog

Changes observed during successful MCP inspections.

AddedNov 9, 2026

TDQS

A3.7/5.0

Behavior4/5

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

Annotations already declare readOnly, idempotent, non-destructive, closed-world, so the safety profile is covered. The description still adds real value beyond them by disclosing that the response is procedural instructions and that no browser session is opened, which prevents the agent from assuming data is returned. It does not describe the shape or length of the returned instructions.

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

Conciseness2/5

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

The opening clause 'from ChatGPT, Claude or any AI agent' is marketing filler, and the entire third sentence about Planning Center's REST API coverage and an August 2026 MCP server is background trivia that does not help select or invoke the tool. Only the middle clause about returning step-by-step instructions and requiring cotlet_browser_* tools earns its place, and it is buried rather than front-loaded.

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

Completeness3/5

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

For a zero-parameter, read-only planning tool, the description covers what comes back and what to do next, which is the essential arc. It leaves open the scope of 'unconfirmed volunteers' (which Planning Center product, what counts as unconfirmed, which account/workspace the steps assume). Given the noise it carries elsewhere, the missing scope detail is a real gap rather than an inherent limitation.

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

Parameters4/5

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

The tool takes zero parameters, so there is nothing for the description to disambiguate. The baseline of 4 applies; the description neither misleads about inputs nor adds unnecessary argument detail.

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 name and first sentence state a specific verb and resource (list unconfirmed volunteers in Planning Center), and the second sentence clarifies the actual deliverable: a step-by-step guide of screens, buttons and fields rather than the raw list. That distinction is important and saves the agent from misreading the tool. It does not, however, say which Planning Center product (Services vs. Check-Ins) or what 'unconfirmed' means, so peripheral ambiguity remains.

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

Usage Guidelines4/5

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

Explicit sequencing guidance is given: this tool 'opens nothing by itself', and the actual work is done 'with the cotlet_browser_* tools in the user's Planning Center Cloud Browser'. The remark that Planning Center's official MCP is 'mostly read-only' implicitly justifies routing through this tool instead. There is no explicit when-not-to-use or pointer to a sibling planning_center_* tool that might overlap.

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

All Planning Center MCP Server and API by Cotlet tools Inspect

Try in Browser

One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources

Need Help?