The CheckFlow MCP Server: Run Your Processes From an AI Assistant

"Start the Northwind onboarding, assign the kickoff to Priya, and tell me what's overdue for the delivery team this week." That is one sentence to an assistant. Behind it are four API calls, two lookups and a filter, and with the CheckFlow MCP server the assistant makes all of them, checks what it is about to change, and reports back.

MCP — the Model Context Protocol — is the open standard that lets an AI assistant use tools. An MCP server describes what it can do, in a form a model can read, and the assistant calls those tools on the user's behalf. The CheckFlow MCP server exposes the same surface as the REST API v3, so anything you could do with a script you can now ask for in plain language: start a checklist, work the Tasks grid, raise and attach a task, look up and update Data Set records, draft a template.

This guide is concrete about what the server can do, honest about what it cannot, and specific about the safety model, because the question every operations lead asks first is not "what can it do?" but "what can it do to me?". It covers the protocol in plain terms, the 147 tools, how a client connects, how keys and annotations keep an agent inside its lane, setup, six real conversations with the tools they call, and the governance an AI agent in your process tool deserves. The MCP server is live now and included on every CheckFlow plan.

What MCP Is

What makes MCP useful is that it is a standard rather than a product. CheckFlow publishes one server; any assistant that speaks the protocol can use it. The assistant does the reasoning — which tools to call, in what order, what to do with the answers — and CheckFlow does exactly what the tools say and nothing else. You do not write the integration. You describe what you want.

What the CheckFlow Server Exposes

The server, which identifies itself as checkflow version 3.0.0, offers 147 tools in eight families. Of those, 57 only read, 26 are marked destructive, and the other 64 write in ways you can see and undo in the app.

The server also offers one resource: the template authoring guide, at checkflow://guides/template-authoring, titled "Writing a CheckFlow template", as Markdown. It is the same document that get_authoring_guide returns as a tool — a resource is what a client offers a person to attach once, a tool is what a model calls — and its worked example is checked by a test in CheckFlow's own build, so it cannot drift from what the API accepts. An assistant that reads it before drafting a template produces a valid one first time far more often.

How It Connects

The endpoint is https://api.checkflow.io/mcp. It speaks the Streamable HTTP transport and is stateless: every request is a POST carrying a JSON-RPC message, there is no session to keep alive, no event stream to hold open, and tools/list and tools/call work without an initialize handshake first. GET and DELETE on the endpoint answer 405. JSON-RPC batches are accepted. The practical consequence is that the server reconnects cleanly after a network blip and scales without any stickiness, and a client can make one call and go away.

Authentication is the same X-API-KEY header the REST API uses, over the same middleware, so the same team boundary, rate limits and idempotency rules apply. That is also the one real constraint on client support:

Rate limits are enforced per workspace exactly as on the REST API, with one difference in how a refusal is delivered: a REST call gets a 429, but an MCP call gets a 200 whose answer tells the model how many seconds to wait, because a 429 would reach the client's transport layer rather than the model that needs to know.

The Safety Model

Four mechanisms decide what an agent can do, and they stack.

The key decides who the agent is

Every API key is bound at creation to an actor — an Administrator, a specific Member, or the workspace — and the agent acts as that actor. It can reach no further than that person can. A key bound to a Member sees the checklists that Member's template permissions admit and completes tasks as that Member; the activity feed records the Member's name. There is no way for the model to ask to act as someone else, because the request carries no actor at all, only the key.

Tools are annotated read-only or destructive

Each tool declares whether it reads or writes and whether a write is destructive. A well-behaved client uses those annotations to decide when to ask you before proceeding — list_my_work runs freely, delete_standalone_task asks first — and you can configure most clients to require confirmation for every destructive tool.

Writes take an idempotency key

Every tool that writes and is not safe to repeat accepts an idempotencyKey. A model that retries after a timeout, sending the same key, gets the first answer back instead of doing the work twice. The cleanest illustration is raise_task: it is annotated non-destructive, but without a key, calling it twice raises two tasks, and the tool's own description says so.

The same boundary as the API

The MCP server sits behind the same middleware as REST: the same team isolation, the same rate limits, the same audit trail. Nothing an agent does is invisible, because everything it does is an ordinary CheckFlow action by an ordinary actor.

Setting It Up

claude mcp add --transport http checkflow https://api.checkflow.io/mcp --header "X-API-KEY: your-api-key"

Six Conversations

Each of these is a request an operations manager might actually make, the tools an assistant would call, and what comes back.

1. "Start the Client Onboarding checklist for Northwind Traders and assign the kickoff to Priya."

list templates            → finds "Client Onboarding"
                            start checklist           → name "Northwind Traders onboarding", parameter Client Name = Northwind Traders
                            list_checklist_tasks      → finds "Kickoff call"
                            set_task_assignees        → Priya

Started Northwind Traders onboarding (12 tasks). Kickoff call is assigned to Priya Shah, due Thursday. Nothing is overdue yet.

2. "What's overdue across the team this week, grouped by person?"

list_my_work              → status = overdue, assignee = all, includeStandalone = true

Fourteen overdue tasks. Sam Okafor: 6 (five on Month-End Close, one standalone). Priya Shah: 4. Unassigned: 4 — all on the Q3 vendor review. Want me to snooze the vendor review tasks until Monday, or reassign them?

3. "Raise a task to renew the SSL certificate, due Friday 5pm, and attach it to the Contoso migration checklist."

search checklists         → "Contoso migration", in progress
                            raise_task                → name, dueDateTime, attachedChecklistKey, idempotencyKey
                            list_attached_tasks       → confirms it is on the checklist

Raised "Renew SSL certificate" and attached it to Contoso migration, which is now 9 of 11 tasks complete and will not close until this one is done. It is unassigned — who should own it?

4. "In the Clients Data Set, change every record whose Region is 'UK' to 'United Kingdom'."

list_data_sets            → "Clients"
                            list_data_set_records     → filter Region = UK → 37 records
                            update_data_set_record    → ×37, each with an idempotencyKey

Updated 37 client records from UK to United Kingdom. Every linked dropdown will show the new value the next time a checklist loads; answers already captured keep their snapshot. The Data Set has 3 template controls connected — Client Onboarding, Quarterly Review and Offboarding — so all three see the change.

5. "Draft a vendor onboarding template with a due-diligence section. Validate it and show me the problems before you commit anything."

get_authoring_guide       → reads the document format
                            create draft              → applies operations: tasks, controls, a conditional due-diligence section
                            validate draft            → returns violations
                            (fix)                     → applies corrections
                            validate draft            → clean
                            — stops and shows you the outline —

Draft ready: 9 tasks in three sections, with the due-diligence section shown only when Risk Tier is High. Validation passed after two fixes (a required control had no label; a due date referred to a task that did not exist). Nothing is committed. Say the word and I will commit it as version 1 in the Procurement folder.

6. "Which webhook deliveries failed yesterday? Replay them."

list webhooks             → 3 subscriptions
                            list deliveries           → yesterday, failed → 5 on "crm-bridge"
                            replay delivery           → ×5

Five deliveries to the crm-bridge subscription failed yesterday between 02:10 and 02:14 with a 503 from your endpoint. Replayed all five; all accepted. The subscription is still active — it was two short of the automatic disable.

What It Does Not Do (Yet)

Three things, said plainly.

• No analytics or reporting tools. The Analytics dashboard has no MCP surface and no v3 endpoint. An assistant can count what it reads from My Work, but it cannot ask for cycle time or a bottleneck table. Use the dashboard, or the v2 analytics endpoint.
• No Library tools. Folders, articles and files are not reachable through MCP or the API. Templates and Data Sets are; the folder they sit in is not.
• No OAuth. Authentication is the API key header, so a client that cannot send one needs a bridge such as mcp-remote, and there is no per-user consent screen. The key's actor binding is the consent.

Governance for an Agent in Your Process Tool

An assistant with write access to your processes deserves the same care as a new employee with the same access. Six habits:

MCP Server vs REST API vs Zapier

Most teams end up with all three: the API for the nightly sync, Zapier for the Slack notification, and the MCP server for the operations lead who wants to ask a question at 4pm and get an answer without opening a screen.

Frequently Asked Questions