Ferramentas MCP

O Stellar expõe um servidor MCP local. É por ele que um agente em execução enxerga o board e age sobre ele. Toda ferramenta que mexe numa coisa que você não pediu passa por consentimento — no fluxo padrão, um pedido com motivo declarado. Leitura é passiva e não pergunta.

Ler sem perguntar

spawn_lineage existe porque o conector é só a aresta visual: o motivo do spawn e a profundidade da cadeia sobrevivem a restart no registro, não no desenho.

unreported_work não acusa: ele confronta o store de sessão do próprio provider com o que o app capturou, e distingue “trabalhou e não reportou” de “não deixou sessão nenhuma” e de “este provider não declara store” — três respostas diferentes, e as duas últimas não são falha de ninguém.

Pedir primeiro

Fechar arquiva, e só o pedido explícito apaga — delete_card, ou a ação do dono sobre um card arquivado. Um card de outro board só aceita exclusão se aquele board estiver em modo autônomo: ali não há interface viva para perguntar a alguém.

Digitar num card

send_to_card não passa por modal: ele enfileira texto para o card de destino e volta na hora. O que existe no caminho é a fila do card — se a pessoa está no meio de uma linha, a entrega espera — e o desfecho da entrega tem estados que importam (delivered, parked, unconfirmed, entre outros). Confira com get_delivery e, se precisar de prova, com read_card. O cancel_deliveries recolhe o que ainda não começou a ser digitado.

O texto vai prefixado com quem enviou. Na mesma chamada você pode vincular o card de destino a uma task com linkTaskId + linkRole (implementer ou reviewer) — o papel é obrigatório quando o vínculo existe; não há default.

Estrutural

create_task, update_task, request_task_status, answer_blocked_task, link_task_card, reorder_reservations, as de sprint (list_sprints, open_sprint, close_sprint, rename_sprint, delete_sprint), set_connector_kind, set_connector_label, write_sticky, update_card_content, set_sticky_color e set_sticky_mode mudam o registro do trabalho, não um processo. Elas são a mecânica de A Fila e de Dependências e sprints.

request_task_status existe porque nem todo agente pode julgar: quem está vinculado como implementer de uma task não escreve done/failed nela — ele pede, e quem decide é o humano (ou um revisor vinculado, quando a task declara que quer revisão).

answer_blocked_task responde a pergunta estruturada de uma task em blocked (lida em get_task → blockedQuestion): limpa a pergunta, volta o status a pending e entrega a resposta no card da task. Sem a resposta, blocked não desbloqueia sozinho.

link_task_card com mode: "reserve" coloca a task na fila do card sem entregar o contrato ainda — list_reservations / reorder_reservations leem e reordenam essa fila. Território aceita shared:<caminho> (<nota>); overrideTerritory (só orquestrador, na entrega) passa um conflito de território com motivo gravado na trilha.

Comando pesado sob lock

run_locked (e o espelho acbridge gate-lock --) roda um comando seu sob o mesmo lock que o app usa nos gates: repo (padrão) serializa contra outros pesados no mesmo repositório; machine usa um lock global para o que mede desempenho. Não é sandbox — só a fila. Gates declarados na task correm em subprocesso isolado; ferramenta fora do repo entra em gateToolPaths no contexto do board.

Navegador

Um conjunto próprio de ferramentas age dentro de um card de navegador já aberto: clicar, digitar, rolar, avaliar JavaScript, ler console, ler rede, esperar por um elemento e tirar um snapshot. Os nove, pelos nomes: browser_click, browser_type, browser_scroll, browser_query, browser_snapshot, browser_console, browser_network, browser_wait_for e browser_eval. É o que permite a um agente conferir o que a própria mudança fez numa página real.

Duas dessas ferramentas recusam em vez de fazer pela metade:

• browser_click relê a página imediatamente antes de clicar e recusa quando não consegue mirar — o alvo mudou de lugar, algo passou a cobri-lo, ou o ponto caiu fora da área visível. Uma coordenada descreve o que estava ali naquele instante, não a identidade de um elemento; por isso o caminho confiável é apontar por seletor ou pela referência do snapshot, e não por x/y.
• browser_type aceita replace: true, que limpa antes de digitar. Sem isso ele soma ao que já estava lá — foi assim que um campo virou “Idy PlatformIdy Platform” com o agente achando que tinha escrito uma vez. O replace usa o comando de edição real do Chromium (o mesmo do Ctrl+A) e ainda entra como um único insertText, para não quebrar entrada por composição. Ele é recusado, nomeando o motivo, quando o alvo não é um campo editável — limpar um alvo não editável selecionaria a página inteira.

browser_eval é a exceção de tom, e vale dizer por quê: ele roda JavaScript no contexto real da página e devolve o resultado, então carrega o poder do console do DevTools — inclusive ler cookies e o sessionStorage da página logada. Os outros browser_* mexem na página; este lê o que a página consegue ler. Use-o contra páginas e dados que você não se importaria que um colaborador humano abrisse no console.

Nem todo provider expõe o catálogo

O app deriva, por provider, se o agente recebe as ferramentas declaradas, se só recebe a dica da CLI pelo scrollback, se não alcança nenhuma das duas, ou se nem se aplica (um shell puro). Por isso o briefing certo é “reporte com a ferramenta se ela estiver no seu catálogo; senão use a CLI” — não uma ordem cega por um caminho só. Ver acbridge (CLI), inclusive a limitação conhecida de cards cline.