MCP

VoidTrack ships an MCP server so agents can read and write issues, projects, initiatives, and more, using the same REST API and the same permissions a human user would have.

Streamable HTTP

The hosted server exposes MCP over streamable HTTP at /api/mcp. Authenticate the same way you would for the REST API, with a bearer API key.

{
  "mcpServers": {
    "voidtrack": {
      "url": "https://your-domain/api/mcp",
      "headers": {
        "Authorization": "Bearer vt_..."
      }
    }
  }
}

This is the simplest option for a hosted or self hosted deployment: no build step, no local binary, just an endpoint and a key.

One connection, several workspaces

An account scoped API key (Settings > API keys > "All my workspaces") reaches every workspace you belong to, so one MCP connection covers all of them instead of one per workspace.

Every workspace scoped tool takes an optional workspace argument, naming a slug, name, or id. list_workspaces shows what the token can reach, and set_active_workspace sets the one used when a call names none. A workspace pinned key ignores none of this: it keeps working exactly as before, and refuses calls that name a different workspace.

Every workspace scoped tool result carries a top level workspace field naming the workspace the call acted in, so a wrong workspace write shows up in the result itself rather than only in the audit log. list_workspaces is the exception: it runs before a workspace is chosen. An account scoped token can move it per call with the workspace argument, or for the rest of the connection with set_active_workspace.

stdio

For local development, or a client that only speaks stdio, run the packaged binary against any VoidTrack instance:

{
  "mcpServers": {
    "voidtrack": {
      "command": "node",
      "args": ["/path/to/voidtrack/packages/mcp/dist/index.js"],
      "env": {
        "VOIDTRACK_URL": "https://your-domain",
        "VOIDTRACK_API_KEY": "vt_..."
      }
    }
  }
}

Build it first with pnpm --filter voidtrack-mcp build (the package is not yet published to npm, so it has to be built from the repo).

What the tools cover

The tools mirror the REST API: teams, issues, comments, projects, initiatives, cycles, labels, updates, relations, documents, members and invites, saved views, and workspace settings. Each tool's parameters, and whether they are required, are listed in the MCP tool reference, which is generated straight from the server's tool definitions so it never drifts from what is actually registered.