API operations for AI clients
The Scalar API MCP is generated from the same published contract as the API Reference. Use search-openapi-operations to discover a method and path, then execute-request with the returned Scalar identifiers. The operation IDs below identify the OpenAPI contract; they are not executor IDs. This catalog covers callable API operations, not the two outbound webhook schemas.
| OpenAPI operation ID | Request | Effect |
|---|---|---|
createChurch |
POST /v1/churches |
Write; confirm intended action |
listChurches |
GET /v1/churches |
Read |
importChurches |
POST /v1/churches/import |
Write; confirm intended action |
getChurch |
GET /v1/churches/{id} |
Read |
registerChurchBankAccount |
POST /v1/churches/{id}/bank-account |
Write; send from your backend, not through the assistant |
setChurchPayoutSchedule |
POST /v1/churches/{id}/payout-schedule |
Write; confirm intended action |
requestChurchVerification |
POST /v1/churches/{id}/verification |
Write; confirm intended action |
recordChurchConsent |
POST /v1/church_consents |
Write; confirm intended action |
getFlowSettings |
GET /v1/flow-settings |
Read |
saveFlowSettings |
PUT /v1/flow-settings |
Write; confirm intended action |
getAllowedOrigins |
GET /v1/allowed_origins |
Read |
saveAllowedOrigins |
PUT /v1/allowed_origins |
Write; confirm intended action |
createDonorSession |
POST /v1/donor_sessions |
Write; send from your backend, not through the assistant |
getDonorSession |
GET /v1/donor_sessions/{id} |
Read |
createManageSession |
POST /v1/manage_sessions |
Write; send from your backend, not through the assistant |
listEnrollments |
GET /v1/enrollments |
Read |
getEnrollment |
GET /v1/enrollments/{id} |
Read |
createRefund |
POST /v1/refunds |
Write; confirm intended action |
listRefunds |
GET /v1/refunds |
Read |
getRefund |
GET /v1/refunds/{id} |
Read |
cancelRefund |
POST /v1/refunds/{id}/cancel |
Write; confirm intended action |
listFinancialEvents |
GET /v1/financial_events |
Read |
listEvents |
GET /v1/events |
Read |
createWebhookEndpoint |
POST /v1/webhook_endpoints |
Write; send from your backend, not through the assistant |
listWebhookEndpoints |
GET /v1/webhook_endpoints |
Read |
testWebhookEndpoint |
POST /v1/webhook_endpoints/{id}/test |
Write; confirm intended action |
listWebhookDeliveries |
GET /v1/webhook_endpoints/{id}/deliveries |
Read |
deleteWebhookEndpoint |
DELETE /v1/webhook_endpoints/{id} |
Write; confirm intended action |
getSandboxFixtures |
GET /sandbox/fixtures |
Read |
simulateDeposit |
POST /sandbox/simulate/deposit |
Sandbox simulation; changes test state |
simulatePayrollConnected |
POST /sandbox/simulate/payroll-connected |
Sandbox simulation; changes test state |
simulatePayrollDisconnected |
POST /sandbox/simulate/payroll-disconnected |
Sandbox simulation; changes test state |
simulateConnectionBroken |
POST /sandbox/simulate/connection-broken |
Sandbox simulation; changes test state |
simulateAccountClosure |
POST /sandbox/simulate/account-closure |
Sandbox simulation; changes test state |
simulateLateReturn |
POST /sandbox/simulate/late-return |
Sandbox simulation; changes test state |
simulateKycOutcome |
POST /sandbox/simulate/kyc |
Sandbox simulation; changes test state |
simulateRefundReturned |
POST /sandbox/simulate/refund-returned |
Sandbox simulation; changes test state |
All POST operations require Idempotency-Key. Required fields, state prerequisites and responses are in the API Reference. Sandbox simulation endpoints do not exist in production. An accepted simulation is not proof that its asynchronous effect has completed. In the hosted sandbox flow, a person connects the payroll through the payroll provider's window in its test mode; simulatePayrollConnected and simulatePayrollDisconnected play that provider for scripts and CI that do not drive the window, and simulateConnectionBroken is the only way to break a connection in the sandbox.
Before a write, have the assistant show the environment, church or enrollment ID, action and idempotency key. In the sandbox, have it read the test values (donor phone numbers and code, church EINs, routing and account numbers) with getSandboxFixtures (GET /sandbox/fixtures) instead of inventing them. Church, donor session and enrollment IDs come from your own API responses and events, and consent comes from the donor in the flow; never let the assistant make them up. Do not put raw personal information or secrets in the prompt. Create webhook endpoints from your backend, not through the assistant: createWebhookEndpoint returns the whsec_ signing secret once, and an AI transcript would keep it; if that happens, delete the endpoint and create a new one. For the same reason, send registerChurchBankAccount (and a church creation or import that carries bank_account), createDonorSession and createManageSession from your backend: they carry bank account numbers or return a donor's one-time link; see What to run through the MCP. Donor changes and cancellation must happen in the donor's authenticated flow. createRefund returns money to a donor: before running it, have the assistant show the donation ID, the amount (or that it refunds what is left), the reason and cancel_recurrence, and wait for your confirmation.
Both servers list the same four tools: the documentation server (https://docs.rostergiving.com/mcp) and the API server (https://mcp.scalar.com/@rostergiving/…). Both run in Scalar's dynamic mode for the same documentation and API, which is why the four names repeat. Only the API server forwards your key, so an execution on the documentation server answers 401. Do not claim an import or simulation ran when execution failed; see MCP troubleshooting.
