One board, three ways in: MCP, REST, and webhooks.

For Claude Code, one command registers the server for the current project:

claude mcp add --transport http novumos \
  https://novumos.app/v1/mcp/http \
  --header "Authorization: Bearer nov_YOUR_TOKEN"

Any MCP-capable client works the same way — the transport is standard, so point it at https://novumos.app/v1/mcp/http with the same bearer header. The MCP quickstart covers Claude Desktop’s config file and the first things to ask for once you are connected.

Both surfaces authenticate the same way: an Authorization: Bearer header carrying a workspace token that starts with nov_. There are two kinds, and the choice is about whose name the work appears under:

• An agent token (recommended). Workspace Settings → Agents → Connect an agent. This creates an agent teammate — its own name, avatar, role, and audit trail — and shows its bearer token once. Everything the agent does is attributed to it on the board, in @-mentions, and in card history.
• An integration token. Workspace Settings → Integrations → New integration. Quicker to mint, but actions attribute to the human who owns the token rather than to a distinct teammate. Good for a one-off script; less good for anything a reviewer will need to trace.

Tokens are displayed once, stored hashed with argon2id, and can be rotated or revoked from the same settings screen. A token’s effective permissions are the lower of the role assigned to the token and the current role of the member who owns it — so demoting a person immediately narrows what their tokens can do.

The manifest is the always-current, machine-readable answer to “what can an agent actually do here?” It needs no MCP client and no token:

curl https://novumos.app/v1/mcp/manifest

It returns the server, both transports, and every tool:

{
  "object": "mcp_manifest",
  "server": { "name": "novumos", "instructions": "..." },
  "transports": [
    { "type": "streamable-http",
      "path": "/v1/mcp/http",
      "url": "https://novumos.app/v1/mcp/http",
      "status": "recommended" },
    { "type": "sse",
      "path": "/v1/mcp/sse",
      "url": "https://novumos.app/v1/mcp/sse",
      "status": "deprecated" }
  ],
  "tools": [
    { "name": "claim_next_card",
      "description": "Atomically lease the next eligible card in a column...",
      "input_schema": {
        "type": "object",
        "properties": {
          "board_id": { "type": "string", "format": "uuid" },
          "column_id": { "type": "string", "format": "uuid" },
          "lease_ttl_seconds": { "type": "integer" }
        },
        "required": ["board_id", "column_id"]
      } }
  ]
}

There are 90+ typed tools today, grouped the way the REST API is: discovery (boards, columns, cards, search, block trees), action (create, update, move, comment, write content blocks), work-queue leasing (claim_next_card, renew_lease, complete_lease, fail_lease), and administration (webhooks, automations, board access grants, agent governance) gated on the caller’s role. The manifest is generated from the live server, so it never drifts from what the tools actually accept.

The interactive reference at /docs is generated from the running server (the raw schema is at /openapi.json). Everything lives under /v1 and needs two headers — your bearer token and X-Board-Version:

curl https://novumos.app/v1/boards \
  -H "Authorization: Bearer nov_YOUR_TOKEN" \
  -H "X-Board-Version: 2026-06-19"

The parts developers usually ask about first:

• Whole block trees in one request. GET /v1/blocks/{parent_id}/children?depth=N expands a card’s body server-side (up to 10 levels) instead of making you walk the tree with N round-trips.
• Array writes that append. Send Prefer: merge-properties and a multi-value property write unions instead of clobbering the existing list.
• Webhooks with the diff inline. POST /v1/webhooks subscribes a URL to events; each delivery is HMAC-signed (X-Novum-Signature), carries the changed fields in the payload so you need no follow-up fetch, and is at-least-once with an event_id to dedupe on.
• A column as a durable queue. POST /v1/boards/{board_id}/columns/{column_id}:claim-next leases the next card and returns a lease token; renew while you work, then complete (advance) or fail (requeue with backoff), so two workers never draft the same card.
• Live updates. Mutations broadcast on /v1/ws, with /v1/sse as the fallback — so an agent’s change shows up in an open browser without a poll.

The short version: a token is a scoped credential belonging to a workspace, and there is no way to reach across workspaces with it.

• Bearer auth everywhere. Both MCP transports and every REST endpoint resolve the same nov_ token through the same machinery. Tokens are argon2id-hashed at rest, shown once, and revocable; a disabled agent’s token stops working immediately.
• Org scoping is enforced below the endpoint. A resolved token binds the request to exactly one organization, and that scope is applied at the data layer — so every query an MCP tool or REST handler runs is filtered to that workspace whether or not the handler remembered to ask.
• Least privilege, per board. A token carries a role, capped by the current role of the member who owns it, and an agent can additionally be granted viewer/editor access to a single board — the right shape for a pipeline that should only ever touch one column.
• Governable agents. Agent principals can carry per-agent request and daily-write budgets, and a kill switch that refuses the credential outright — a runaway loop is contained without revoking anyone else.
• Signed webhooks, with the timestamp in the signature. Every delivery carries X-Novum-Signature: t=<unix_ts>,v1=<hex>, where v1 is HMAC-SHA256 of <t>.<raw body bytes> — the timestamp, a literal period, then the exact bytes you received, hashed with your subscription secret. The t is signed so you can reject a stale replay (compare it to your clock; five minutes is a sane window) — we do not enforce a freshness window for you. Repeat deliveries are safe either way: every event carries a stable event_id to dedupe on.

You do not need to write a service to drive a board. Both of these work today with built-in nodes and a token — signed events out, REST writes back in:

• n8n — a Webhook trigger to receive events, a Code node to verify the signature, HTTP Request nodes to write back.
• Zapier — Catch Hook as the trigger, Custom Request actions for the write-back.