# Intelliboard (npm · intelliboard-mcp)

Kanban do Intelliboard por MCP: handoff entre agentes e validação imposta antes de concluir.

- Trust score: 78/100 (medium)
- Change this week: +3
- Registry status: active
- Liveness: live
- Owner verified: no
- Last scored: 2026-09-20

## Components

- npm · `intelliboard-mcp`: 78/100 (this document), [markdown](https://verifymcp.io/servers/aaglis-intelliboard-mcp/intelliboard-mcp.md), [page](https://verifymcp.io/servers/aaglis-intelliboard-mcp/intelliboard-mcp)

## Channel facts

- Registry: `npm`
- Package: `intelliboard-mcp`
- Version: `0.18.1`
- Transport: `stdio`

## Trust breakdown

How this component scores in each security and reliability category. Every signal is checked automatically from public evidence about the published package, including repeated runs of it in an isolated sandbox, and we only credit what we can confirm. Scores are 0–100 per category. Scoring method: https://verifymcp.io/docs/scoring (what has changed: https://verifymcp.io/docs/scoring/changelog)

Scored 2026-09-20.

- **Supply Chain Security**: 100/100
  - No malware found by supply-chain analysis.
  - No known CVEs affecting this package version or its production dependencies.
  - No install/post-install scripts declared.
  - No production dependencies, so there is no dependency health to assess.
- **Provenance & Transparency**: 19/100
  - Repository check failed: the declared repository URL returned HTTP 404.
  - Provenance check failed: no build-provenance attestation is published.
  - Clear OSI-approved license (MIT).
  - Actively maintained (last published 28 days ago).
  - Security-disclosure policy not yet verified: we couldn't inspect the source repository.
- **Schema Quality & AI Usability**: 72/100
  - AI-judged instruction clarity (excellent).
  - Context-footprint check failed: tool/resource definitions use about 6638 tokens (~144/item across 46 items; 46 tools + 0 resources), over budget; trim descriptions and params.
  - Usage-examples check failed: none of the tools include examples.
- **Stability & Change Management**: 97/100
  - Stability observed for 29 of 30 days with no destabilising changes; credit accrues until the full window elapses.
- **Tool Coverage**: 94/100
  - 100% of tools have a non-trivial description (not blank, and not just the tool's name).
  - 81% of tool parameters carry a description.
- **Tool Safety**: 100/100
  - No prompt-injection markers were found in the server instructions, tool names or descriptions we captured.
  - All 4 tool(s) whose name or description implies an irreversible operation declare an MCP destructiveHint annotation.
  - An AI judge read all 46 captured unit(s) of tool text and found none that tries to manipulate the model reading it.
- **Capabilities**: 100/100
  - Implements a supported MCP spec version (2025-11-25); the latest is 2026-07-28.

## Install

### How do I install the Intelliboard MCP server?

Intelliboard runs locally as an npm package, launched with npx -y intelliboard-mcp. Ready-made configuration for Claude, Cursor, VS Code, Codex and 5 more is on this page, copied from each client's own documentation.

### Claude

```bash
claude mcp add aaglis-intelliboard-mcp -- npx -y intelliboard-mcp
```

### Cursor

```json
{
  "mcpServers": {
    "aaglis-intelliboard-mcp": {
      "command": "npx",
      "args": [
        "-y",
        "intelliboard-mcp"
      ]
    }
  }
}
```

### VS Code

```json
{
  "servers": {
    "aaglis-intelliboard-mcp": {
      "command": "npx",
      "args": [
        "-y",
        "intelliboard-mcp"
      ]
    }
  }
}
```

### Codex

```bash
codex mcp add aaglis-intelliboard-mcp -- npx -y intelliboard-mcp
```

### opencode

```json
{
  "$schema": "https://opencode.ai/config.json",
  "mcp": {
    "aaglis-intelliboard-mcp": {
      "type": "local",
      "command": [
        "npx",
        "-y",
        "intelliboard-mcp"
      ],
      "enabled": true
    }
  }
}
```

### OpenClaw

```bash
openclaw mcp add aaglis-intelliboard-mcp --command npx --arg -y --arg intelliboard-mcp
```

### Hermes

```yaml
mcp_servers:
  aaglis-intelliboard-mcp:
    command: "npx"
    args: ["-y", "intelliboard-mcp"]
```

### Netclaw

```json
{
  "McpServers": {
    "aaglis-intelliboard-mcp": {
      "Transport": "stdio",
      "Command": "npx",
      "Arguments": [
        "-y",
        "intelliboard-mcp"
      ]
    }
  }
}
```

### Vellum

```bash
assistant mcp add aaglis-intelliboard-mcp -t stdio -c npx -a -y intelliboard-mcp
```

### Other

```json
{
  "mcpServers": {
    "aaglis-intelliboard-mcp": {
      "command": "npx",
      "args": [
        "-y",
        "intelliboard-mcp"
      ]
    }
  }
}
```

## Changelog

Every change recorded for this component, newest first. Days that predate change tracking, or that we cannot explain, say so: "we were watching and nothing happened" and "we were not watching" are different claims.

### 2026-09-20 (score 78, +1)

No change was recorded against any check on this day. Stability & Change Management went from 93 to 97. That category is still filling its 30-day observation window: 28 days of observed history at the previous scan, 29 at this one. The score rises as the window fills, whether or not the server changes.

### 2026-09-18 (score 77, +1)

No change was recorded against any check on this day. Stability & Change Management went from 87 to 90. That category is still filling its 30-day observation window: 26 days of observed history at the previous scan, 27 at this one. The score rises as the window fills, whether or not the server changes.

### 2026-09-16 (score 76, +1)

No change was recorded against any check on this day. Stability & Change Management went from 80 to 83. That category is still filling its 30-day observation window: 24 days of observed history at the previous scan, 25 at this one. The score rises as the window fills, whether or not the server changes.

### 2026-09-13 (score 75, +1)

No change was recorded against any check on this day. Stability & Change Management went from 70 to 73. That category is still filling its 30-day observation window: 21 days of observed history at the previous scan, 22 at this one. The score rises as the window fills, whether or not the server changes.

### 2026-09-11 (score 74, +1)

No change was recorded against any check on this day. Stability & Change Management went from 63 to 67. That category is still filling its 30-day observation window: 19 days of observed history at the previous scan, 20 at this one. The score rises as the window fills, whether or not the server changes.

### 2026-09-09 (score 73, +1)

No change was recorded against any check on this day. Stability & Change Management went from 57 to 60. That category is still filling its 30-day observation window: 17 days of observed history at the previous scan, 18 at this one. The score rises as the window fills, whether or not the server changes.

### 2026-09-07 (score 72, +1)

No change was recorded against any check on this day. Stability & Change Management went from 50 to 53. That category is still filling its 30-day observation window: 15 days of observed history at the previous scan, 16 at this one. The score rises as the window fills, whether or not the server changes.

### 2026-09-05 (score 71, +1)

No change was recorded against any check on this day. Stability & Change Management went from 43 to 47. That category is still filling its 30-day observation window: 13 days of observed history at the previous scan, 14 at this one. The score rises as the window fills, whether or not the server changes.

## MCP tools (46)

### `intelliboard_status` (~58 tokens)

Status da conexão

Diz se o MCP está conectado e autenticado no Intelliboard. Chame logo após instalar para confirmar a conexão. Retorna { authenticated, apiUrl, user? }. Se authenticated=false, chame a tool `login`.

### `check_update` (~54 tokens)

Checar atualização

Verifica no npm se há uma versão mais nova do intelliboard-mcp (ignora o cache de 24h). Retorna a versão atual, a última publicada, se há atualização e o comando para atualizar.

### `update` (~97 tokens)

Atualizar o MCP

Explica como atualizar o intelliboard-mcp. O processo em execução NÃO se auto-substitui: a versão nova entra ao REABRIR a sessão do agente. A ordem importa — chame `prepare_update` ANTES de pedir o reinício, senão o download acontece dentro da janela de startup do cliente e a sessão pode abrir sem nenhuma tool. Não é preciso relogar: o token do device flow persiste.

### `prepare_update` (~117 tokens)

Preparar a atualização antes do reinício

Baixa e prepara a versão publicada AGORA, com a sessão ainda de pé, para que o próximo start do cliente seja cache hit em vez de uma instalação fria. Use isto antes de pedir ao usuário para reabrir a sessão. Só faz sentido quando o servidor é lançado por npx (o caminho recomendado). Não substitui o processo em execução e não altera nada do seu board. Pode levar dezenas de segundos numa primeira instalação; se o cliente cortar a chamada por timeout, o download continua e o reinício ainda sai beneficiado.

### `login` (~90 tokens)

Autenticar (device flow)

Autentica o usuário no Intelliboard por device flow (OAuth). PASSO DO HUMANO: NÃO tente abrir a URL, aprovar ou autenticar você mesmo. Retorna { verification_url, user_code } — MOSTRE a URL ao usuário e peça para abrir no navegador e aprovar. O token é salvo automaticamente quando ele aprova; depois chame intelliboard_status para confirmar.

### `list_boards` (~94 tokens)

Listar boards da organização

Lista os boards da organização efetiva. Com allOrganizations=true, descobre boards de TODAS as orgs em uma chamada e inclui organizationId/organizationName, sem alterar seleção, vínculo ou board ativo. O escopo normal segue: select da sessão > vínculo do workspace > config legada > app ativo.

Input parameters:

- `allOrganizations` (boolean): Se true, lista boards de todas as organizações sem mudar o contexto atual.

### `create_board` (~149 tokens)

Criar board

Cria um board na organização efetiva (select da sessão > vínculo do workspace > config legada > app). O backend já cria as 3 colunas essenciais (Planejamento/Em andamento/Concluído). Recusa nome DUPLICADO na org — o board é resolvido por ID no vínculo e por nome em selects/config legada. Respeita o teto de boards da org (erro claro no limite). Opção select=true passa a operar neste board NESTA sessão (equivale a select_board).

Input parameters:

- `name` (string, required): Nome do board.
- `select` (boolean): Se true, passa a operar neste board na sessão (equivale a select_board).

### `rename_board` (~88 tokens)

Renomear board

Renomeia um board (por nome ou id) da organização efetiva. Vínculos de workspace continuam válidos pelo ID; workspace status informa se o nome local ficou desatualizado. Config legada por nome precisa ser atualizada.

Input parameters:

- `board` (string, required): Nome ou id do board a renomear (ver list_boards).
- `name` (string, required): Novo nome.

### `list_organizations` (~52 tokens)

Listar organizações

Lista as organizações do usuário (id, nome, papel, e memberCount — 1 = pessoal, >1 = compartilhada/time). Use para escolher em qual org o agente vai atuar com select_organization.

### `select_organization` (~102 tokens)

Selecionar organização (sessão)

Fixa a ORG que ESTA instância do MCP opera, por nome ou id — override em memória do processo. NÃO altera o navegador nem outras instâncias (não toca user_context). Reseta o board (re-resolve na nova org). Depois use list_boards + select_board. Recusa se há card em andamento neste agente (o escopo é por-card).

Input parameters:

- `org` (string, required): Nome ou id da org (ver list_organizations).

### `select_board` (~77 tokens)

Selecionar board (sessão)

Fixa o BOARD (da org atual) que ESTA instância opera, por nome ou id — override em memória do processo. NÃO toca o navegador nem outras instâncias. Board de outra org → erro. Recusa se há card em andamento neste agente.

Input parameters:

- `board` (string, required): Nome ou id do board (ver list_boards).

### `workspace_status` (~68 tokens)

Status do vínculo do workspace

Read-only: mostra o workspace detectado (identidade Git ou caminho), o vínculo local de organização/board, a validade dele contra o backend, a precedência de escopo em vigor e o que a config legada ainda declara. Use antes de link_workspace para saber se já existe vínculo.

### `list_workspace_links` (~54 tokens)

Listar vínculos de workspace

Read-only: lista TODOS os workspaces vinculados nesta máquina para a API atual (caminho local, organização e board). Útil para descobrir a que board um outro repositório está ligado sem precisar entrar nele.

### `link_workspace` (~187 tokens)

Vincular workspace a um board

Vincula ESTE repositório a uma organização + board. Aceita nome ou id; omita o campo quando só há uma opção acessível. O board é procurado DENTRO da organização já resolvida, então um par cruzado (org de um lado, board de outro) não chega a existir. Se faltar informação ou houver ambiguidade, devolve `candidates` tipados em vez de escolher sozinho — repita passando o id. O vínculo grava em disco, vale imediatamente para este processo e para os demais, e substitui um vínculo anterior. Recusa enquanto houver card em andamento neste agente.

Input parameters:

- `board` (string): Nome ou id do board DENTRO dessa organização (ver list_boards). Omita se só houver um.
- `organization` (string): Nome ou id da organização (ver list_organizations). Omita se só houver uma.

### `unlink_workspace` (~62 tokens)

Remover vínculo do workspace

Remove o vínculo local deste repositório. Depois disso o escopo volta à precedência seguinte (config legada, ou org/board ativos no app). Idempotente: sem vínculo, responde ok sem erro. Recusa enquanto houver card em andamento neste agente.

### `validation_status` (~65 tokens)

Status do gate de validação

Read-only: diz se este workspace tem perfil de validação e qual. Sem perfil, devolve `recommendation` com os comandos detectados a partir do projeto (package.json, Cargo, go.mod, pyproject) — passe-os a setup_validation ou aceite a detecção.

### `setup_validation` (~157 tokens)

Configurar o gate de validação

Grava o perfil de validação deste workspace — o gate que complete_card exige antes de concluir um card. Sem `commands`, usa o que for detectado do projeto (ou o `validate` da config legada). Com `commands`, grava exatamente o argv informado (sem shell). Nada é executado durante o setup. Sobrescreve um perfil anterior. O perfil fica fora do repositório, em ~/.config/intelliboard/validation.json.

Input parameters:

- `commands` (array): Etapas do gate, em ordem. Omita para aceitar a detecção automática.
- `overwrite` (boolean): Obrigatório para substituir um perfil que o USUÁRIO configurou. Configurar um workspace ainda sem perfil não precisa disto.

### `list_columns` (~386 tokens)

Listar board

Lista as colunas do board ativo (com role) e seus cards. Por padrão os cards vêm ENXUTOS (id, título, coluna, assignee, épico, sprint, dependências, prazo) — SEM description, executionReport nem validationLog, que são os campos longos que estouram o contexto num board grande.
\- Precisa da descrição/report de um card? Peça por nome: `fields: ['description']` — de preferência junto com `columns` e/ou `limit` para não trazer o corpo de todos.
\- Só quer o tamanho do board? `summaryOnly: true` (contagem por coluna, mais barato ainda).
\- Procurando um card específico num board grande? Prefira `search_cards`.
Filtros combináveis: `sprintId`, `epic`, `columns`, `limit` (máx por coluna).

Input parameters:

- `columns` (array): IDs de colunas a incluir (subconjunto).
- `epic` (string): Filtra os cards por épico/área (ex.: 'edge-cv').
- `fields` (array): Campos EXTRA do card, somados ao conjunto enxuto padrão. Use p/ pedir os longos sob demanda: description, executionReport, validationLog, changedFiles, residualRisks, knownLimitations, securityNotes,…
- `limit` (integer): Máx. de cards POR COLUNA (não global). Colunas nunca somem por causa do limite.
- `sprintId` (string): Filtra os cards por sprint (ex.: só o sprint ativo).
- `summaryOnly` (boolean): Só a contagem de cards por coluna (sem os cards). Visão geral mais barata.

### `create_column` (~74 tokens)

Criar coluna

Cria uma coluna. Verifique duplicatas com list_columns antes. role opcional: todo|doing|done.

Input parameters:

- `color` (string): Cor hex, ex: #1A1A1A.
- `role` (string): Papel no fluxo do agente.
- `title` (string, required): Título da coluna.

### `delete_column` (~31 tokens)

Deletar coluna

Remove uma coluna e TODOS os cards dela. Use com cuidado.

Input parameters:

- `id` (string, required): ID da coluna.

### `create_card` (~640 tokens)

Criar card

Cria um card a partir de um relato/task. ANTES, LEIA o código relevante para entender a causa real. Descrição em markdown com Problema, Comportamento atual vs Esperado, Causa raiz (arquivo:linha), Como reproduzir, e Critérios de aceite. columnId vem de list_columns. PREFIXE o título com o tipo Conventional Commits em colchetes, ex.: `[fix] corrige expiração do convite`, `[feat] ...`, `[hotfix] ...`, `[chore] ...`, `[docs] ...`, `[refactor] ...`, `[test] ...`. Esse prefixo alimenta o nome da branch e o commit na conclusão. Para criar VÁRIOS cards (ex.: planejar uma sprint), use create_cards_bulk — ele aceita os mesmos campos e ainda liga as dependências entre os cards do lote.

Input parameters:

- `columnId` (string, required): ID da coluna (ver list_columns).
- `deadline` (string): ISO 8601, opcional.
- `dependsOn` (array): IDs de cards pré-requisitos (mesmo board). get_next_task não entrega este card enquanto eles não estiverem 'done'.
- `description` (string): Markdown detalhado (máx. 10.000 caracteres).
- `epic`: Épico/área (máx. 40 caracteres); null limpa; omitido = inalterado.
- `knownLimitations`: Limitações conhecidas (máx. 5.000 caracteres); null limpa; omitido = inalterado.
- `residualRisks`: Riscos residuais conhecidos (máx. 5.000 caracteres); null limpa; omitido = inalterado.
- `securityNotes`: Notas de segurança (máx. 5.000 caracteres); null limpa; omitido = inalterado.
- `sprintId` (string|null): Sprint do card. OMITIDO = entra no sprint ATIVO (se houver) — é o único lugar de onde get_next_task puxa; um card fora dele fica invisível para o loop do agente. null = manda explicitamente para o ba…
- `title` (string, required): Título curto e claro, prefixado com o tipo em colchetes (ex.: '[fix] ...').
- `unverifiedClaims` (array): Afirmações do card que você NÃO verificou, uma por item (ex.: 'suponho que o jsdom falta no standalone — não conferi'). Aparece na listagem enxuta para a próxima sessão não ler isto como fato estabel…
- `validationCommands` (array): Substitui os comandos específicos do card (máx. 50 comandos de 500 caracteres); [] limpa.
- `verificationEvidence`: O que sustenta a verificação: comando rodado, saída observada, teste que cobre, arquivo:linha lido.
- `verificationMethod`: Como o resultado central foi verificado. Níveis: measured > tested > reviewed > unverified. Na dúvida, use o MAIS FRACO. Definição completa em complete_card.

### `create_cards_bulk` (~309 tokens)

Criar cards em lote

Cria VÁRIOS cards de uma vez (tudo-ou-nada) — ideal p/ planejar uma sprint inteira numa chamada só, revisando o plano antes de persistir. Aceita os MESMOS campos do create_card (epic, validationCommands, etc.), então NÃO é preciso criar e depois corrigir card a card. Cada título DEVE ter prefixo [tipo] (ex.: '[feat] ...'); se algum faltar/for inválido, o lote INTEIRO é rejeitado apontando o índice — nenhum card é criado.

DEPENDÊNCIAS DENTRO DO LOTE: os ids ainda não existem quando você monta a chamada, então dê um `ref` (apelido, ex.: 'auth-api') ao card pré-requisito e cite esse ref no `dependsOn` de quem depende dele. O `ref` é resolvido na criação e descartado (não é salvo). `dependsOn` também aceita IDs de cards que já existem no board. Ciclos e refs inexistentes são rejeitados com o lote inteiro. Declarar a ordem importa: get_next_task só entrega um card quando TODAS as suas dependências estiverem 'done'.

columnId vem de list_columns; sprintId (opcional) de list_sprints (mesmo board). A posição segue a ordem do array. Máx. 100.

Input parameters:

- `cards` (array, required): Cards a criar, na ordem desejada (posição = ordem do array).

### `update_card` (~488 tokens)

Atualizar card

Atualiza campos de planejamento e handoff de um card, inclusive comandos de validação, riscos, limitações e notas de segurança. Use `sprintId` para mover o card para outro sprint (grooming de backlog) ou `null` para tirá-lo do sprint. O backend valida que o sprint é do mesmo board do card. Campos omitidos ficam inalterados; null limpa campos textuais nullable.

Input parameters:

- `deadline` (string|null)
- `dependsOn` (array): Substitui os pré-requisitos do card (IDs do mesmo board); [] limpa; omitido = inalterado.
- `description` (string): Markdown detalhado (máx. 10.000 caracteres); omitido = inalterado.
- `epic`: Épico/área (máx. 40 caracteres); null limpa; omitido = inalterado.
- `id` (string, required)
- `knownLimitations`: Limitações conhecidas (máx. 5.000 caracteres); null limpa; omitido = inalterado.
- `residualRisks`: Riscos residuais conhecidos (máx. 5.000 caracteres); null limpa; omitido = inalterado.
- `securityNotes`: Notas de segurança (máx. 5.000 caracteres); null limpa; omitido = inalterado.
- `sprintId` (string|null): ID do sprint (mesmo board) para mover o card; null tira do sprint; omitido = inalterado.
- `title` (string)
- `unverifiedClaims` (array): Afirmações do card que você NÃO verificou, uma por item (ex.: 'suponho que o jsdom falta no standalone — não conferi'). Aparece na listagem enxuta para a próxima sessão não ler isto como fato estabel…
- `validationCommands` (array): Substitui os comandos específicos do card (máx. 50 comandos de 500 caracteres); [] limpa.
- `verificationEvidence`: O que sustenta a verificação: comando rodado, saída observada, teste que cobre, arquivo:linha lido.
- `verificationMethod`: Como o resultado central foi verificado. Níveis: measured > tested > reviewed > unverified. Na dúvida, use o MAIS FRACO. Definição completa em complete_card.

### `move_card` (~120 tokens)

Mover card

Move um card para outra coluna/posição. Mover para a coluna 'doing' TAMBÉM faz o claim no backend; esta tool alinha o estado local (baseline + heartbeat) ao claim resultante, então não existe card pego pelo servidor e desconhecido pelo agente. Para pegar um card para trabalhar, prefira claim_card — ele valida dependências, bloqueio e conflito de claim antes de mover.

Input parameters:

- `cardId` (string, required)
- `columnId` (string, required)
- `position` (integer, required): 0 = topo.

### `list_sprints` (~60 tokens)

Listar sprints

Lista os sprints do board atual (id, nome, status, período, meta). Num board compartilhado todos os membros veem os mesmos sprints. Use para achar o sprintId de um card ou saber qual está ativo (status 'active').

### `create_sprint` (~113 tokens)

Criar sprint

Cria um sprint no board atual (status inicial 'planning'). Datas em YYYY-MM-DD (opcionais). NÃO ativa automaticamente — use activate_sprint. Num board compartilhado o sprint fica visível a todos os membros/agentes.

Input parameters:

- `endDate` (string): Data de fim, YYYY-MM-DD.
- `goal` (string): Meta/objetivo do sprint (markdown curto).
- `name` (string, required): Nome do sprint.
- `startDate` (string): Data de início, YYYY-MM-DD.

### `update_sprint` (~122 tokens)

Configurar sprint

Atualiza nome, meta, período (YYYY-MM-DD) ou status ('planning'|'active'|'done') de um sprint. Para trocar o sprint ativo, prefira activate_sprint (garante no máximo 1 ativo por board).

Input parameters:

- `endDate` (string|null): YYYY-MM-DD ou null.
- `goal` (string)
- `id` (string, required): ID do sprint (ver list_sprints).
- `name` (string)
- `startDate` (string|null): YYYY-MM-DD ou null.
- `status` (string)

### `activate_sprint` (~212 tokens)

Ativar sprint

Torna este o sprint ATIVO do board — os demais ativos viram 'done' (no máximo 1 ativo por board). Num board compartilhado isso muda o sprint ativo para TODOS os membros e seus agentes. AÇÃO SENSÍVEL: chame primeiro com `dryRun:true` para ver o diff (willActivate/willDeactivate + quantos cards abertos cada sprint a encerrar tem). SEM `force`, a ativação é RECUSADA (409) se algum sprint que seria encerrado ainda tiver cards não-concluídos — revise o dryRun e, se for intencional, chame com `force:true`.

Input parameters:

- `dryRun` (boolean): Só mostra o diff (não persiste): willActivate, willDeactivate[{sprintId,name,openCards}], openCards, requiresForce.
- `force` (boolean): Confirma a ativação mesmo encerrando sprint(s) com cards abertos.
- `id` (string, required): ID do sprint a ativar.

### `complete_card` (~729 tokens)

Concluir card

Conclui um card movendo-o para 'done'. EXIGE comprovante local vinculado ao fingerprint atual; sem ele devolve ticket + comandos exatos para execução pela autorização nativa do agente. Código alterado ou validação falha BLOQUEIAM a conclusão. IMPORTANTE: o executionReport é OBRIGATÓRIO e deve ser detalhado — ele é salvo no campo dedicado execution_report do card e fica visível na aba RELATÓRIO do frontend para auditoria futura.

Input parameters:

- `architecturalChange` (object): OPCIONAL. Preencha SÓ se este card mudou COMO o projeto funciona (troca de lib, arquitetura, re-implementação de entidade). Gera uma entrada vinculada ao card no log de decisões; o backend deriva o e…
- `cardId` (string, required): ID do card a concluir.
- `changedFiles` (array): Arquivos alterados (caminhos) — versão estruturada e consultável do que o report descreve em prosa.
- `epic` (string): Épico/área do card: edge-cv|api|web|security|ops|product (livre). Permite filtrar por área.
- `executionReport` (string, required): Markdown DETALHADO da execução. OBRIGATÓRIO. Três seções, nesta ordem: `## Resumo` (1-2 frases do que foi feito), `## Arquivos alterados` (caminho + o que mudou em cada um), `## Validação` (resultado…
- `followUpCards` (array): IDs de cards de follow-up gerados a partir deste.
- `knownLimitations` (string): Limitações conhecidas do que foi entregue (texto).
- `residualRisks` (string): Riscos residuais que ficam após a conclusão (texto).
- `securityNotes` (string): Notas de segurança relevantes (texto).
- `unverifiedClaims` (array): Afirmações do seu relatório que você NÃO verificou, uma por item. Se o relatório contém dedução, suposição ou análise não confirmada, ela vai AQUI — não some no meio da prosa.
- `validationCommands` (array): Comandos de validação ESPECÍFICOS deste card, além do gate global (ex.: 'docker compose up redis', 'alembic upgrade head', 'smoke CV_MODE=real').
- `verification` (object, required): OBRIGATÓRIO. Como o resultado central deste card foi verificado. O card vira fonte de verdade para a próxima sessão: sem esta marca, hipótese e fato medido chegam lá com a mesma autoridade. measured…
- `workPrecededClaim` (string): Use SOMENTE quando a investigação definiu o card e o trabalho já estava pronto/commitado antes do claim — aí não há mudança de código depois do claim e o gate recusaria a conclusão. Explique o que fo…

### `amend_execution_report` (~203 tokens)

Corrigir um relatório de execução (append-only)

ACRESCENTA uma correção datada ao executionReport de um card. O texto original NUNCA é alterado — a correção fica ao lado dele, com data, autor e método de verificação. Use quando descobrir um erro num relatório já registrado (seu ou de outra sessão): auditoria com erro fixado é pior que auditoria com a correção registrada. Não serve para editar o relatório 'direito' — o histórico não se reescreve.

Input parameters:

- `cardId` (string, required): ID do card cujo relatório será corrigido.
- `correction` (string, required): O que estava ERRADO no relatório e qual é a informação correta. Cite o trecho original.
- `verificationMethod` (string, required): Como você verificou a CORREÇÃO (a correção não escapa da própria regra). Níveis: measured > tested > reviewed > unverified. Na dúvida, use o MAIS FRACO. Definição completa em complete_card.

### `validate` (~58 tokens)

Validar implementação

Prepara um ticket de validação e devolve os comandos exatos para execução pela ferramenta nativa de terminal. Não executa comandos dentro da tool.

Input parameters:

- `cardId` (string): Card a validar; omitido usa o card atual da sessão.

### `get_next_task` (~55 tokens)

Pegar próxima tarefa

Pega o primeiro card disponível da coluna 'todo', trava por assignee e move para 'doing'. Retorna { done: true } quando não há mais. Loop: get_next_task → implementar → complete_card → repetir.

### `claim_card` (~178 tokens)

Pegar um card específico (por id)

Pega o card indicado, trava por assignee e move para 'doing' — o mesmo claim atômico do get_next_task, mas no card que VOCÊ escolheu, sem reordenar o board. Devolve o mesmo briefing (project_context, recent_decisions, git, validação).
RECUSA: card já pego por outro agente (409), card bloqueado, card já concluído, e card com dependências não-concluídas (a ordem declarada no board vale igual aqui). Se o card JÁ é seu, readota o claim sem perder o baseline — é o caminho de recuperação depois de um restart do MCP.
Para varrer o backlog na ordem do board, continue usando get_next_task.

Input parameters:

- `cardId` (string, required): ID do card a pegar (ver search_cards / list_columns).

### `list_my_cards` (~21 tokens)

Listar meus cards

Cards atribuídos a você (assignee = seu usuário).

### `block_card` (~35 tokens)

Bloquear card

Bloqueia explicitamente um card e para heartbeat local.

Input parameters:

- `cardId` (string, required)
- `reason` (string, required)

### `release_card` (~27 tokens)

Liberar card

Libera o claim do card e para heartbeat local.

Input parameters:

- `cardId` (string, required)

### `unblock_card` (~27 tokens)

Desbloquear card

Remove o bloqueio manual sem iniciar claim/heartbeat.

Input parameters:

- `cardId` (string, required)

### `list_agents` (~106 tokens)

Ver agentes ativos neste board

Lista os agentes com claim ativo no board (sessão, cliente, estado, card e heartbeat). Use ANTES de pegar trabalho num board compartilhado: mostra quem já está em quê, evita dois agentes editando as mesmas áreas e permite escrever handoff endereçado. `stale: true` = claim sem heartbeat recente (o agente provavelmente morreu; o servidor libera o card). Não expõe PID, host, caminho, comando nem diff — só a identidade mínima do processo.

### `inspect_claim_changes` (~28 tokens)

Inspecionar mudanças desde o claim

Read-only: compara baseline atual com o working tree.

Input parameters:

- `cardId` (string, required)

### `get_project_context` (~96 tokens)

Ler o briefing/contexto do projeto

Retorna a nota de CONTEXTO do projeto (kind=context) — o briefing que descreve convenções, decisões e objetivos. LEIA antes de implementar cards para seguir o padrão do projeto. Retorna SEMPRE { hasContext, text }: hasContext=false + text=null significa que o board não tem briefing (não é erro). Não existe resposta ambígua aqui — se hasContext=true, `text` tem conteúdo.

### `list_decisions` (~93 tokens)

Ler o log de decisões do board

Lê o log append-only de decisões do board (mais recentes primeiro). Filtros: source, q, cardId, epic, limit. Cada entrada traz id, summary, detail, source, cardId, epic, at.

Input parameters:

- `cardId` (string)
- `epic` (string)
- `limit` (integer)
- `q` (string)
- `source` (string)

### `search_cards` (~234 tokens)

Buscar cards no board

Busca cards do board ativo por texto (título e descrição, case-insensitive) e/ou filtra por épico, sprint e assignee. Resultado ENXUTO por padrão (sem description/report) — a forma barata de achar um card num board grande, em vez de listar tudo com list_columns e varrer. Achou o card e precisa do corpo? Chame list_columns com `fields: ['description']` e `columns` da coluna dele. Escopo: SOMENTE o board ativo desta instância. Sem `q`, funciona como filtro puro (ex.: só `epic`).

Input parameters:

- `epic` (string): Filtra por épico/área exato (ex.: 'api').
- `limit` (integer): Máx. de resultados (default 20, máx 200).
- `mine` (boolean): Só cards atribuídos a você.
- `q` (string): Texto a buscar em título/descrição (mín. 2 chars). Omita para filtrar sem busca textual.
- `sprintId` (string): Filtra por sprint (ver list_sprints).

### `log_decision` (~235 tokens)

Registrar decisão (log append-only)

APPENDA uma decisão ao log do board — histórico datado do que mudou e por quê (ex.: troca de biblioteca, mudança de arquitetura, re-implementação de entidade). Append-only: NUNCA sobrescreve nada. O próximo agente lê essas decisões no get_next_task, então registre mudanças que afetam COMO o projeto funciona. Não use isto para editar o BRIEFING (estado atual) — a mudança do briefing é aprovada por um humano.

Input parameters:

- `cardId` (string)
- `confidence` (string, required): OBRIGATÓRIO. Como esta decisão foi verificada. Ela volta em recent_decisions na próxima sessão: registrar hipótese com voz de fato propaga o erro. Níveis: measured > tested > reviewed > unverified. N…
- `epic` (string)
- `summary` (string, required): Uma linha: o que mudou (ex.: 'trocado Axios por fetch nativo').
- `why` (string): Motivo/impacto (ex.: 'menos deps, bundle menor').

### `delete_card` (~21 tokens)

Deletar card

Remove um card permanentemente.

Input parameters:

- `id` (string, required)

### `commit_card` (~222 tokens)

Commitar o card (commit-only — sem push/PR)

Faz APENAS commit local das mudanças do card — NUNCA push, NUNCA PR. Antes de commitar, garante a branch correta: se o repo estiver numa branch protegida (main/master), cria/troca para uma branch do card ({type}/slug, onde {type} vem do prefixo [tipo] do título). Estageia só arquivos rastreados (git add -u). COMMIT É OPCIONAL: commit="off" recusa. Nos demais modos, a tool faz um preflight e exige aprovação local separada para git_branch e git_commit. Confirmação no chat NÃO autoriza execução; o usuário decide no terminal. A message deve seguir Conventional Commits (ver commit_convention), usando o [tipo] do título como prefixo.

Input parameters:

- `cardId` (string, required): ID do card implementado.
- `message` (string, required): Mensagem COMPLETA em Conventional Commits (o agente compõe conforme commit_convention). Ex.: 'fix: corrige checagem de expiração do convite'.

### `set_git_mode` (~144 tokens)

Definir preferência de fluxo git (local, por-dev)

Persiste, na máquina do dev (~/.config/intelliboard/prefs.json), como o MCP trata branch/commit ao concluir cards. Isto controla a preferência de fluxo, NÃO concede permissão para executar Git. Mesmo em auto, branch/commit passam pelo broker local e podem exigir aprovação no terminal. mode="off" impede a operação. action="branch", "commit" ou "both". mode="ask" volta a perguntar. Não afeta outros devs nem o board compartilhado.

Input parameters:

- `action` (string, required): Qual ação configurar.
- `mode` (string, required): ask = perguntar; auto = sempre fazer; off = não fazer (dev cuida).

## Diagnostics

Captured diagnostic sections: Provenance, Dependencies. The full working is on the page: https://verifymcp.io/servers/aaglis-intelliboard-mcp/intelliboard-mcp#diagnostics

## Score history

- 2026-09-20: 78
- 2026-09-19: 77
- 2026-09-18: 77
- 2026-09-17: 76
- 2026-09-16: 76
- 2026-09-15: 75
- 2026-09-14: 75
- 2026-09-13: 75
- 2026-09-12: 74
- 2026-09-11: 74
- 2026-09-10: 73
- 2026-09-09: 73
- 2026-09-08: 72
- 2026-09-07: 72
- 2026-09-06: 71
- 2026-09-05: 71
- 2026-09-04: 70
- 2026-09-03: 70
- 2026-09-02: 69
- 2026-09-01: 69
- 2026-08-31: 68
- 2026-08-30: 68
- 2026-08-29: 64
- 2026-08-28: 64
- 2026-08-27: 64
- 2026-08-26: 64
- 2026-08-25: 63
- 2026-08-24: 63
- 2026-08-23: 63
- 2026-08-22: 52

## Common questions

### What is the Intelliboard MCP server?

Intelliboard is an MCP server listed in the public MCP registry as io.github.aaglis/intelliboard-mcp. Kanban do Intelliboard por MCP: handoff entre agentes e validação imposta antes de concluir. This page covers its npm package (intelliboard-mcp).

### Is the Intelliboard MCP server safe to use?

Intelliboard scores 78 out of 100 on VerifyMCP. We found no known CVEs affecting it as of 20 September 2026. It declares no install or post-install scripts. That is a record of what we were able to check automatically, not an endorsement. The category breakdown on this page shows every signal behind the number, including the ones we could not confirm.

### What tools does the Intelliboard MCP server expose?

Intelliboard exposes 46 tools: intelliboard_status, check_update, update, prepare_update, login, and 41 more. Their descriptions and schemas cost roughly 6,638 tokens of context every time the server is loaded.

### Is the Intelliboard MCP server still maintained?

Intelliboard is still listed as active in the MCP registry. We last reached this channel on 20 September 2026. Those dates come from our own scans of the registry and the channel itself, not from anything the publisher announced.

### What licence is the Intelliboard MCP server under?

Intelliboard declares the MIT licence, which is OSI-approved. That covers the source only, and says nothing about the cost of any service it calls.

## Links

- npm package: https://www.npmjs.com/package/intelliboard-mcp
- Socket report: https://socket.dev/npm/package/intelliboard-mcp
- Changelog RSS feed: https://verifymcp.io/servers/aaglis-intelliboard-mcp/intelliboard-mcp.xml
- Changelog JSON feed: https://verifymcp.io/servers/aaglis-intelliboard-mcp/intelliboard-mcp.json
- HTML version of this page: https://verifymcp.io/servers/aaglis-intelliboard-mcp/intelliboard-mcp