churchtools-mcp

Overview Schema Source Related Servers Discussions Admin

Call the ChurchTools API

ct_api_request

Call any ChurchTools REST API operation: GET runs immediately; POST, PUT, PATCH, and DELETE return a preview plan with a token for ct_execute_plan before committing.

Instructions

Calls any operation of the ChurchTools REST API. GET runs at once. POST, PUT, PATCH and DELETE write nothing: they return a plan with a preview and a token for ct_execute_plan. The path must match an operation of the spec, with every value filled in.

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": {
      "method": "<method>",
      "path": "<path>"
    },
    "name": "ct_api_request"
  }
}

Input Schema

Name	Required	Description
`body`	No	The JSON body of a write
`path`	Yes	Concrete path relative to /api without a query string, e.g. /persons/12
`query`	No	Query parameters; an array repeats the key
`method`	Yes	The HTTP method

Schema Changelog

Changes observed during successful MCP inspections.

First observedv0.1.0Oct 18, 2026

TDQS

A4.4/5.0

Behavior4/5

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

With readOnlyHint=false and destructiveHint=false declared, the description supplies the crucial missing piece: writes are two-phase and return a preview plus a token rather than mutating anything, which reconciles why a DELETE-capable tool is marked non-destructive. It does not mention auth requirements (ct_login exists) or error behavior, keeping it at 4 rather than 5.

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

Conciseness5/5

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

Four short sentences, front-loaded with the tool's scope, then the GET-versus-write branch, then the path constraint. Every sentence carries distinct information with no repetition of the schema.

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?

For a fully generic API invoker with no output schema and 100% schema coverage, this covers the essential behavioral twist an agent could not infer from structured fields. It omits authentication expectations and how to discover valid operations, which the ct_login / ct_search_api / ct_get_operation siblings imply but are not referenced.

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?

Schema coverage is 100%, so the baseline is 3, but the description adds constraints beyond the schema: the path must resolve to an operation in the spec with every template value filled in. That clarifies the concrete-path requirement more sharply than the schema's own wording.

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

Purpose5/5

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

States a specific verb and resource (call any ChurchTools REST operation) and positions itself as the generic escape hatch among typed siblings like ct_get_person and ct_create_group. It also names the follow-up tool ct_execute_plan, so an agent can distinguish this from the concrete CRUD tools without opening any schema.

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?

Clear context on when behavior differs: GET executes immediately while POST/PUT/PATCH/DELETE only produce a plan. It routes the agent to ct_execute_plan for the second phase. It does not explicitly say when to prefer a typed sibling over this generic tool, so it stops short of full when/when-not guidance.

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