MCP tools

Cheqq's MCP server is at https://cheqq.ai/api/mcp. Any assistant that supports remote MCP servers over HTTP can connect, with an API key in the Authorization header or by signing in. Setup for each assistant: Claude Code, Cursor, Claude.ai, ChatGPT.

When an assistant connects, Cheqq tells it which workspace it's in, which Wapp is mounted, and what it may do, so it can plan before it calls anything.

The tools

An assistant only sees the tools its key or connection is allowed to use.

Cheqq tools

Every tool named cheqq_… works across the whole workspace. There is one for each endpoint in the REST reference, such as cheqq_list_records, cheqq_add_field, cheqq_run_workflow or cheqq_update_document, and they take the same inputs.

Start with cheqq_whoami: it says which workspace the connection works in, what it may do and how many requests a minute it has. It's always offered.

One Wapp's own tools

Add ?wapp= and a Wapp's slug (or its install id) to the address:

https://cheqq.ai/api/mcp?wapp=content-studio

The assistant then also gets the tools that Wapp is built with, named after it, such as content_studio_list_collections and content_studio_create_record. The list shows every collection with its fields and choices, and the record tools take the collection it names, so they stay right after you add or rename a field. Only one Wapp can be mounted per connection; add a second server for a second Wapp.

A Wapp's tools follow your role in it: if you can only view the Wapp, its tools can only read.

Automation building tools

With workflows:write, the assistant can build automations the way Cheqq's own agent does: on a draft, one step and trigger at a time. Like every other Cheqq tool they start with cheqq_, for example cheqq_create_workflow_draft, cheqq_add_workflow_ai_step, cheqq_add_workflow_schedule_trigger, cheqq_validate_workflow_draft, cheqq_test_workflow_draft, cheqq_finalize_workflow_draft and cheqq_save_workflow_draft. Each step and trigger kind has its own cheqq_add_workflow_<kind>_step (or _trigger) and cheqq_update_workflow_<kind>_step tool. See Automations for how drafts work.

Choose which tools

With every scope, Cheqq offers well over a hundred tools, which is more than some assistants handle well. Add ?tools= with the groups you want, comma separated:

https://cheqq.ai/api/mcp?wapp=content-studio&tools=records,structure

A mounted Wapp's tools are sorted into the same groups. An unknown group name is refused with the list of valid ones, rather than leaving the assistant with no tools.

Giving a key fewer scopes narrows the list the same way, and also limits what the REST API allows.

Tools that delete or publish

What protects you instead:

• Your AI client's confirmation. Tools that delete or take something offline are marked as destructive, and tools that only read are marked as read-only, so clients like Claude Code, Cursor, Claude.ai and ChatGPT can ask you before running the rest. cheqq_edit_document_blocks is marked destructive too, because it can delete a whole tab. Keep those confirmations on for Cheqq.
• Scopes. Leave records:delete, structure:write, documents:delete and apps:publish off unless the assistant needs them. Without the scope, the tool isn't offered at all.
• Two steps to delete a Wapp. cheqq_delete_wapp only says what would go the first time; it deletes when called again with confirmed: true, and the Wapp can be restored from Trash for 30 days.
• Undo. Deleted records and collections go to the Wapp's Trash, field and view changes can be undone from the Wapp's history, documents keep every version, and Apps keep a checkpoint before every edit.
• Things only a person can do. Publishing an App to more people than can see it now needs you in the App Builder (see Documents and Apps), and an approval can only be answered by the people it asks.

Results

Tools answer with JSON text. An answer over 200 KB is replaced by a note saying how large it was and how to ask that tool for less: a big App file is read in parts (offset, length, then nextOffset), a big run as a summary and then one step at a time, dashboards as a summary and then one by id, and records with a smaller page or a filter. When a call fails, the result says so with the same code and message the REST API would give, such as INSUFFICIENT_SCOPE: This key isn't allowed to delete records…, so the assistant can tell you what's missing. An unexpected failure carries a request id; quote it when you report it.

Verifying an App returns its screenshots as images the assistant can look at.

Who did what

Everything an assistant does is done as the person who connected it. Records it creates are yours, and its changes to a Wapp appear in the Wapp's history with "(API)" at the end.