Chaindoc MCP Server (Beta): Turn Claude and ChatGPT Into Your AI Document Employee

Um servidor MCP é um pequeno programa que permite a assistentes IA como o Claude Desktop ou o ChatGPT chamarem serviços externos como se fossem ferramentas integradas. O Model Context Protocol (MCP) foi apresentado pela Anthropic em novembro de 2024 como um padrão aberto para ligar agentes IA a sistemas reais. Em vez de dizer à IA "explica como funciona o Chaindoc", dizes "envia este NDA ao John para assinatura" e a IA executa diretamente através do servidor MCP, sem copiar e colar, sem logins, sem trocar de ferramenta.

O Chaindoc MCP é o primeiro servidor MCP nativo de assinatura eletrónica, atualmente em beta privada. Transforma o Claude Desktop, o ChatGPT (através do OpenAI Apps SDK), o Cursor e o Zed numa interface operacional para todo o ciclo de vida do contrato: redação, assinatura, verificação e seguimento. Honestamente, da primeira vez que vês o Claude redigir e enviar um contrato por ti, parece quase batota.

A mudança é real. Segundo o relatório Salesforce State of Sales 2024, os comerciais passam apenas 28% da semana a vender ativamente; o resto vai para trabalho administrativo como redigir contratos, perseguir documentos e atualizar o CRM. Funcionários IA construídos sobre MCP podem reduzir grande parte desses 72% a instruções de chat. Pesquisas da Aberdeen Group mostram que organizações que usam fluxos de assinatura eletrónica fecham contratos 80% mais depressa e processam 22,6 propostas por comercial por mês, contra 10,4 com fluxos manuais. Combina esses ganhos com um agente IA que trata do trabalho de ponta a ponta e o teto de produtividade sobe bastante.

Este guia explica o que faz o Chaindoc MCP server, como difere de uma integração API tradicional, o que está disponível na beta e como pedir acesso. Para mais contexto sobre integrações, vê a nossa página REST API para assinatura eletrónica e automação de documentos e o nosso guia já existente sobre integração CRM com Chaindoc e Pipedrive.

Um funcionário IA, neste contexto, não é um chatbot que finge ser uma pessoa. É um agente IA com um conjunto específico de ferramentas e autoridade para usá-las em teu nome. O protocolo MCP dá à IA três coisas que antes não tinha: um diretório de ferramentas disponíveis (operações Chaindoc como "criar documento" ou "verificar assinatura"), uma forma estruturada de as chamar e um caminho para ler os resultados de volta de modo a planear o passo seguinte.

Pensa em como um funcionário humano trata uma tarefa contratual. Mandas-lhe um email "envia o NDA ao John, copia as nossas cláusulas padrão de PI, faz seguimento se ele não assinar numa semana". Abre o Chaindoc, encontra o modelo de NDA, preenche-o, envia-o, marca um lembrete no calendário para o follow-up e verifica o estado quando chega o prazo. Cada um desses passos corresponde a uma ferramenta do Chaindoc MCP: `chaindoc_create_document`, `chaindoc_create_signature_request`, `chaindoc_get_status`, `chaindoc_subscribe_webhook`. O agente IA decide que ferramentas chamar, em que ordem, e adapta-se ao que cada passo devolve.

O que muda para ti, o humano:

• Deixas de abrir 14 separadores do navegador para trabalho contratual. A maioria das operações contratuais vai para uma única interface de chat.
• O agente IA trata do meio aborrecido (preencher modelos, vigiar assinaturas, mandar lembretes), tu só intervéns no início (intenção) e no fim (revisão).
• As trilhas de auditoria ficam mais fortes, não mais fracas, porque cada ação da IA é registada pelo Chaindoc do mesmo modo que uma ação humana, com a mesma ancoragem em blockchain descrita no nosso guia de conformidade da trilha de auditoria.

Aviso justo: agentes IA cometem erros. Por vezes escolhem o modelo errado, contam mal os signatários ou enviam para o email errado perante instruções ambíguas. O servidor MCP devolve mensagens de erro completas, por isso a IA costuma apanhar os próprios erros a meio da tarefa, mas continua a recomendar-se um passo de revisão humana para contratos de elevado valor.

A maioria dos primeiros servidores MCP liga agentes IA a dados só de leitura: pesquisar na web, consultar uma base de dados, ler um ficheiro. A assinatura eletrónica é diferente porque é o raro fluxo em que o valor não está em recuperar mas em agir. A IA não te fala apenas de um contrato; envia-o. Isso muda a matemática da produtividade numa ordem de grandeza completa.

Três razões pelas quais a assinatura eletrónica encaixa invulgarmente bem no MCP:

1. 1.
   Ações discretas e bem definidas. As operações contratuais decompõem-se em primitivas limpas (criar, enviar, assinar, verificar, estado, listar). Os agentes IA são bons a escolher a primitiva certa para uma instrução; são piores a improvisar fluxos difusos com várias etapas. As operações de assinatura eletrónica são exatamente o tipo de coisa que descreverias a um colaborador júnior numa única frase.
2. 2.
   Elevado rigor da trilha de auditoria. A maioria dos fluxos que os agentes IA tocam têm proveniência fraca. Será que o agente realmente enviou aquele email? Os dados estavam limpos? Com o Chaindoc, cada ação da IA aterra numa trilha de auditoria à prova de adulteração ancorada numa blockchain pública, o mesmo registo que um utilizador humano produziria. Isto torna a contratação conduzida por IA conforme por defeito para ESIGN, eIDAS e SOX; vê o nosso guia de trilha de auditoria e prova legal.
3. 3.
   Cauda longa de variantes contratuais. Uma empresa típica gere dezenas de tipos de contratos (NDAs, MSAs, SOWs, acordos com fornecedores, contratos de trabalho, contratos de prestação). Cada um tem ligeiras variações por jurisdição, setor e contraparte. Os agentes IA lidam bem com essa variabilidade porque conseguem raciocinar sobre modelos e cláusulas; a automação baseada em regras não consegue.

Para cenários contratuais concretos onde o Chaindoc MCP está a ser testado em beta, vê os nossos artigos sobre o NDA para prestadores em empresas de software, o guia do formulário W-9 para prestadores e a classificação prestador independente vs colaborador.

O Chaindoc MCP server em beta expõe sete ferramentas que cobrem todo o ciclo de vida do contrato. Cada ferramenta corresponde a um endpoint REST API específico do Chaindoc, com a camada MCP a tratar da autenticação, do parsing de respostas e do contexto de erro para que o agente IA receba algo sobre o qual realmente possa raciocinar.

Ferramentas disponíveis em beta

• `chaindoc_create_document` , carrega um ficheiro ou variante de modelo e devolve um ID de documento e um URL de visualizador. A IA usa-a para redigir a partir de um modelo seguindo instruções do chat.
• `chaindoc_create_signature_request` , envia um documento para assinatura a um ou mais signatários, com verificação KYC opcional, ordem de assinatura e calendário de lembretes.
• `chaindoc_get_status` , devolve o estado completo de um pedido de assinatura: quem assinou, quem está pendente, URLs de assinatura para os signatários ativos e a trilha de auditoria até à data.
• `chaindoc_verify_document` , passa um documento assinado pelo Chaindoc por uma verificação à prova de adulteração e devolve o certificado de assinatura, a âncora blockchain e o resultado de integridade.
• `chaindoc_list_documents` , lista paginada de documentos com filtros opcionais (estado, intervalo de datas, email do signatário). Permite à IA escolher o documento certo a partir de uma referência vaga.
• `chaindoc_get_template` — obtém um modelo guardado e o respetivo esquema de variáveis, para que a IA saiba exatamente que campos preencher.
• `chaindoc_subscribe_webhook` — regista um webhook para eventos de estado, devolvendo o ID do webhook e o segredo HMAC. Serve para configurar notificações assíncronas que a IA pode consultar mais tarde.

O que ainda não está em beta

Ferramentas de faturação, orquestração KYC e OAuth multi-tenant estão no roadmap (vê a secção abaixo). A beta atual baseia-se em chave API, o que serve para utilizadores individuais e equipas pequenas mas ainda não suporta o fluxo OAuth por utilizador de que precisarão os deploys multi-tenant em produção.

Se já integraste o Chaindoc através da REST API e SDKs, a pergunta é justa: porquê adicionar uma nova camada? A resposta é que o MCP não substitui a API; é uma superfície diferente para um consumidor diferente. As integrações API tradicionais são escritas para código (um serviço backend, um plugin de CRM). O MCP é escrito para agentes IA (Claude, ChatGPT, Cursor).

Uma vez configurado o servidor MCP (vê a secção de acesso à beta mais abaixo), o fluxo do lado do utilizador é conversacional. Aqui vai um exemplo real dos testes em beta.

Passo 1: abrir o Claude Desktop e descrever o que precisas

Escreves: "Envia o NDA de prestador ao John Smith em john@acme.example, prazo de assinatura na próxima sexta, copia a cláusula de cessão de PI do nosso modelo de software".

Passo 2: o Claude raciocina sobre que ferramentas chamar

O Claude chama `chaindoc_get_template` para obter o teu modelo de NDA de prestador, identifica os espaços variáveis (nome da contraparte, email, prazo, jurisdição) e funde a cláusula de cessão de PI a partir da tua biblioteca padrão. Depois chama `chaindoc_create_document` com o modelo preenchido.

Passo 3: o Claude prepara o pedido de assinatura

O Claude chama `chaindoc_create_signature_request` com o email do John, o prazo de assinatura e (opcional) verificação KYC. Devolve uma confirmação: "Documento redigido a partir do modelo `Contractor NDA v3`, enviado para john@acme.example, URL de assinatura ativo até sexta-feira, 9 de maio, às 23:59 UTC".

Passo 4: o Claude regista um webhook de estado

O Claude chama `chaindoc_subscribe_webhook` para escutar o evento `signature.completed`, assim recebes uma notificação no Claude quando o John assinar sem teres de consultar tu mesmo. Todo o fluxo demora cerca de 60 segundos entre a tua mensagem inicial e o pedido de assinatura ficar ativo na caixa do John.

Passo 5: verificação na conclusão

Quando o John assina, o webhook dispara e o Claude reporta o resultado. Podes pedir ao Claude para verificar a assinatura e ele chama `chaindoc_verify_document` para confirmar a âncora blockchain, o certificado de assinatura e a trilha de auditoria. A mesma verificação que farias manualmente em /verify-document, mas dentro do chat onde começaste.

Para ser direto, a experiência varia consoante o modelo de IA. O Claude Desktop é neste momento o mais fluido porque a Anthropic construiu o MCP. O ChatGPT via Apps SDK funciona bem mas com um pouco mais de latência. O Cursor e o Zed são ótimos se vives num editor de código de qualquer forma. O protocolo é padronizado, por isso ao longo do tempo a experiência deverá convergir entre clientes.

Cada ação que um agente IA executa através do servidor MCP passa pelo mesmo backend do Chaindoc que trata das ações humanas. Não há um caminho paralelo, nem registo separado, nem modo de "bypass IA". A trilha de auditoria capta os mesmos sete campos obrigatórios descritos no nosso guia de conformidade da trilha de auditoria, com um acréscimo: a sessão do agente IA fica marcada para que vejas quais ações foram iniciadas pela IA versus iniciadas por um humano.

Em concreto:

• Identidade: a chave API (em beta) ou o token OAuth de utilizador (em GA) identifica a conta humana em cujo nome a IA atua. Cada ação é rastreável até uma pessoa real, não a uma identidade genérica de "agente IA".
• Autenticação: as chaves API podem ter âmbito (só leitura, escrita, admin), pelo que utilizadores beta podem conceder o acesso mínimo necessário a clientes IA específicos.
• Proveniência da ação: o log de auditoria regista que a ação veio por MCP, mais que cliente (Claude Desktop, ChatGPT, Cursor, etc.) e que ferramenta foi chamada. Se o Claude enviou um contrato em teu nome, a trilha mostra "enviado via MCP, cliente: claude-desktop, ferramenta: chaindoc_create_signature_request, utilizador: alex@chaindoc.example".
• À prova de adulteração: cada entrada de auditoria está encadeada por hash e ancorada numa blockchain pública, exatamente como ações humanas diretas. Contratos conduzidos por IA não são menos defensáveis do que enviados manualmente; em alguns aspetos são até mais defensáveis, porque a chamada estruturada à ferramenta fica preservada lado a lado com a instrução humana do chat.

Para os enquadramentos de conformidade subjacentes, vê o nosso artigo sobre conformidade da assinatura digital com eIDAS, GDPR e NIST e sobre a força legal das assinaturas eletrónicas em blockchain. Para os controlos de acesso ao nível da equipa que regem quem pode ligar clientes IA à tua conta, vê /team-management.

Em maio de 2026, nenhum fornecedor importante de assinatura eletrónica lançou um servidor MCP público. As comparações mais próximas são anúncios de funcionalidades IA dentro dos produtos existentes (Docusign IAM e Docusign AI, as ferramentas de revisão IA da Ironclad), mas nenhum expõe essas capacidades a agentes IA externos através de um padrão aberto. A tabela abaixo resume o panorama.

A beta é por convite, com lugares limitados priorizados para clientes ativos do Chaindoc e organizações com forte componente de programação. Os participantes na beta recebem acesso gratuito até à disponibilidade geral, suporte dedicado por Slack da equipa de engenharia e uma linha direta para pedidos de funcionalidades.

Três formas de pedir acesso

1. 1.
   Clientes existentes: entra no teu painel Chaindoc e procura a secção "AI Agents" em Definições. O interruptor da beta está aí.
2. 2.
   Novos avaliadores: regista-te em /api-integration e marca a opção "MCP beta" no formulário de onboarding para programadores.
3. 3.
   Pedido direto: envia email para beta@chaindoc.io com o teu caso de uso (1-2 frases), tamanho da equipa e que cliente IA queres ligar (Claude Desktop, ChatGPT, Cursor, Zed). Respondemos em dois dias úteis.

Instalação, depois de teres acesso

A beta é entregue como pacote npm. Após receberes a tua chave API, adiciona o seguinte à tua configuração do Claude Desktop (`~/Library/Application Support/Claude/claude_desktop_config.json` em macOS, caminhos equivalentes em Windows e Linux):

Reinicia o Claude Desktop. O ícone 🔌 deve mostrar "chaindoc" ligado com sete ferramentas disponíveis. A primeira chamada a uma ferramenta costuma demorar 2-3 segundos.

Para Cursor, Zed e Windsurf a configuração é semelhante; as instruções completas chegam com o teu convite para a beta. O suporte para ChatGPT via OpenAI Apps SDK está em testes privados e será lançado depois de o Claude Desktop atingir GA.

A beta atual cobre redação, assinatura, verificação e seguimento de contratos. Há três capacidades em desenvolvimento ativo para fases posteriores da beta e para a disponibilidade geral:

Automação de faturação

Uma ferramenta `chaindoc_create_invoice` que gera uma fatura associada a um contrato assinado, com termos de pagamento, linhas e instruções Stripe / transferência. A ferramenta lê o calendário de pagamentos do contrato, gera a fatura na data certa e envia-a (opcionalmente) através da trilha de auditoria existente do Chaindoc. Vê o nosso artigo sobre pagamentos ligados a contratos e automação de faturação para o fluxo humano em que isto assenta, mais o aprofundamento sobre automação de faturação após assinatura eletrónica.

Orquestração KYC

Uma ferramenta `chaindoc_request_kyc` que dispara verificação de identidade de um signatário antes de ele assinar. O agente IA pode raciocinar sobre que signatários precisam de KYC completo (contratos de elevado valor, setores regulados) versus verificação ligeira (NDAs padrão) e configurar o pedido de assinatura em conformidade. Atualmente o KYC é configurado ao nível do pedido por humanos; o objetivo é deixar a IA tomar essa decisão.

Fluxos multiagente

Mais à frente, o MCP suporta comunicação entre agentes. Assim, um servidor Chaindoc MCP pode chamar um servidor MCP de CRM (HubSpot, Salesforce), um servidor MCP de calendário (Google, Outlook) ou um servidor MCP de pagamentos (Stripe). Um contrato assinado pode disparar uma atualização de CRM, um lembrete no calendário e a emissão de uma fatura, tudo coordenado pelo agente IA em vez de webhooks codificados à mão. Esta é a arquitetura que transforma a IA de uma ferramenta de escrita numa verdadeira camada operacional.

Funcionalidades IA coladas a produtos existentes estão por toda a parte neste momento. Redação automática de cláusulas, redlining inteligente, resumos de revisão de contrato: cada fornecedor histórico está a lançar isso. São úteis, mas são funcionalidades. Vivem dentro da interface do fornecedor e exigem que um utilizador humano conduza o fluxo.

A assinatura eletrónica IA-nativa é estruturalmente diferente. A unidade de valor não é "o que o nosso produto pode fazer por ti" mas "o que o teu agente IA pode fazer em teu nome, onde quer que viva" (Claude Desktop, ChatGPT, Cursor, o teu próprio cliente personalizado). Isso muda os critérios de compra. A velocidade de execução do contrato deixa de medir-se em minutos por assinatura e passa a medir-se em instruções de chat por resultado. As trilhas de auditoria deixam de ser uma função defensiva de conformidade e tornam-se uma condição prévia para confiar em fluxos conduzidos por IA.

O Chaindoc faz cedo a aposta de que esta categoria se torna dominante nos próximos 24 meses. O servidor MCP é o primeiro passo concreto. Se és cliente atual, o interruptor da beta está no teu painel agora. Se estás a avaliar ferramentas de assinatura eletrónica com IA no roadmap, pede acesso à beta através de /api-integration e diz-nos que cliente IA queres ligar.