Skip to main content
Quiva exposes its own build surface — flows, records, document templates, spaces and tasks, assistants, distribution, and Abbie’s settings — as a set of MCP servers. Point an MCP-aware client at them and it can create and change real configuration on your account, with reference documentation and local validation built in so it doesn’t have to guess at payload shapes.
This is the other direction from Tools & Connectors, which is about your assistants calling out to external MCP servers. This page is about your own AI coding tool (Claude Code, Cursor, VS Code, Claude Desktop) calling into Quiva.

What you can build with it

Flows

Create, publish, run and debug workflows — every node type, with the rules-engine DSL and JSONPath data references explained.

Records

Define record configs (schema and form views) and manage the records in them.

Document templates

Build DOCX and PDF templates, generate documents from them, and request e-signatures.

Spaces & tasks

Create spaces, tasks, comments and files, and manage time logs and task templates.

Assistants

Define assistant configurations and invoke them — the same objects you build in the Assistants tab.

Distribution

Manage products, product definitions, invitations and messages between publisher and distributor accounts.

Abbie's settings

Read, and carefully change, Abbie’s organisation profile, backlog, memory, corrections and environment variables.

Hosted remote vs. running it yourself

Hosted (recommended)

One URL — https://api.quiva.ai/mcp — authenticated with an API key. Nothing to install or run. Works with Claude Code, Cursor, VS Code and Claude Desktop — not claude.ai in the browser or a ChatGPT custom connector, which need OAuth and aren’t supported here.

Run it locally

Clone the servers and run them as local stdio processes, one per area of the platform. Useful for development on the servers themselves, or where a hosted connection isn’t an option.
Both connect to the same production API and understand the same tools. The hosted server is stateless: it builds a fresh client for every request from whatever credential you send, and never stores one.

Tool prefixes

The hosted server composes every area of the platform into one endpoint, so tool names carry a prefix to keep them from colliding (each area separately exposes list_examples, get_example and list_reference_topics). Running a server locally, the same tools appear unprefixed since only one is loaded at a time. Each area has its own list_reference_topics tool. Point your client at it before it builds anything — the reference topics describe how the platform actually behaves, including the cases where a request succeeds but quietly does nothing.

Connect a client

Claude Code, Cursor, VS Code and Claude Desktop, step by step

API keys

Create and scope the key your client authenticates with

Run it locally

Clone the servers and run them as stdio processes

Tool reference

Every tool, by area, with what it does