churchtools-mcp

Overview Schema Source Related Servers Discussions Admin

Plan a change to a ChurchTools group membership

ct_update_group_member

Updates a group member's role, status, comment, and start or end date by returning a patch plan that includes only changed fields.

Instructions

Writes nothing: returns a plan that patches only the membership fields whose value changes: role, status, comment, start and end date.

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "groupId": "<groupId>",
      "personId": "<personId>"
    },
    "name": "ct_update_group_member"
  }
}

Input Schema

Name	Required	Description
`comment`	No	null clears it
`groupId`	Yes	The group's id
`personId`	Yes	The person's id
`memberEndDate`	No	YYYY-MM-DD; null clears it
`groupTypeRoleId`	No	The role id
`memberStartDate`	No	YYYY-MM-DD; an active membership needs one
`groupMemberStatus`	No	active, requested (awaits confirmation), waiting (waiting list) or to_delete (pending removal)

Schema Changelog

Changes observed during successful MCP inspections.

First observedv0.1.0Oct 18, 2026

TDQS

A3.5/5.0

Behavior4/5

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

Adds genuinely non-obvious behavior beyond the annotations: the call has no write effect ('Writes nothing'), it *returns a plan* rather than applying anything, and it patches only fields whose value actually changes (so an omitted field is not a clear, while an explicit null is). The diff-patch semantics is exactly the kind of detail an agent cannot recover from the schema. Minor tension with readOnlyHint=false, which is reconcilable if the generated plan/operation is itself persisted, but the description does not resolve it explicitly.

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?

A single dense sentence, front-loaded with the most decision-relevant fact ('Writes nothing') and structured with a colon before the field list. Nothing is wasted, though the extreme terseness is what leaves the usage/workflow gap.

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?

With no output schema, the description correctly fills that gap by stating the return value is a plan, and it explains the no-write and diff-only semantics. The one real omission is the downstream contract: nothing tells the agent how the returned plan is applied (presumably via ct_execute_plan), which matters for invoking the tool correctly as part of a workflow.

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% and the schema already documents each field, including the enum meanings for groupMemberStatus and the 'null clears it' semantics. The description only recasts the fields in business language (role, status, comment, start/end date), which adds mild mapping value but no syntax or format detail beyond the schema. Baseline 3 is appropriate.

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?

States a specific action and scope: it returns a *plan* that patches a defined set of membership fields (role, status, comment, start/end date). That is far more precise than a restatement of the name and implies update-of-existing rather than add/remove. It stops short of naming the sibling tools it is meant to be chosen over (ct_add_group_member, ct_remove_group_member, ct_execute_plan), so it is clear but not sibling-differentiating.

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

Usage Guidelines2/5

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

There is no when-to-use guidance, no prerequisites, and no mention of the plan/execute handoff that this server clearly has (siblings ct_execute_plan and ct_get_operation). An agent is left to infer from the name alone that this is the tool for changing an existing membership, and to infer on its own what must be done with the returned plan.

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