Automation & AI — the REST API and the MCP server

Two surfaces, one credential model: whoever calls is a user (§14).

REST API — for scripts and automation#

A request authenticates as an agent user with its qva_ key. What it may reach is simply the projects that agent has a role on — Viewer reads, User and Lead read and write — so there is no second permission list to keep in step with the real one. The API covers projects, users, tasks (list/filter/search, create, patch, delete — including archive / restore, with archived tasks excluded from listings unless asked for) and comments, with the app's field validation (statuses, priorities, the 80-character title cap, week pairing) — and anything the agent can't read is a plain 404, indistinguishable from nonexistent. Archived projects follow the app: the project list shows the live ones (?archived=true for the other side), an archived project's tasks are out of the task list unless you name the project, and creating a task in one is refused by name.

• A viewer role reads and nothing more, and a grant is per project, so an agent reaches exactly the projects it was added to and nothing else in the organization's work — least privilege at a grain most PM APIs don't offer.
• API writes are signed: the agent is the actor in the activity feed and the author of comments it posts. Attempts to claim a different author are rejected — you are only ever yourself.

MCP server — for AI assistants#

Every person mints personal tokens (Settings → User account → MCP access); the page even generates a ready-made claude mcp add … command. An agent user connects with its own key instead (§14). Claude Code, Claude Desktop or any MCP client then operates Qivo conversationally with eleven tools: list teams / projects / users / tasks, get task, list & add comments, create / update / delete tasks, and set someone's plannable week. list_projects shows the live projects and takes archived: true for the ones that have been put away; an archived project's tasks stay out of list_issues unless you name the project, and creating a task in one comes back with a sentence saying which project to restore.

The token is you: every call runs under your permissions — the assistant sees the projects you see and writes only where you could. One qualification since guests exist: a token belongs to the seat that minted it and stays inside that organization, so a token made in your own organization never reaches a project someone else shared with you (mint a second token from that account if you want it). Its task writes appear in the activity feed under your name, labeled "via MCP"; comments it posts are simply your comments (a comment is its own feed entry).

Both tiers share the same credential hygiene: secrets shown once and stored hashed, a display prefix plus created / last-used dates on every row (the at-a-glance "is this integration still alive?" audit), and two-click revocation that cuts access immediately.

✦ What sets this apart — A first-party MCP server as a co-equal product surface: AI assistants get per-user permission fidelity (no over-privileged bot accounts, no "the integration sees more than I do"), one-paste setup, and attributed task writes. Combined with the agent-user REST tier, human edits, team automation and personal AI are visibly distinct actors.