O que é MCP e o que muda quando um agente de IA envia o contrato para assinatura

O que é MCP? É o padrão que deixa um programa pequeno, o servidor MCP, descrever os endpoints de uma API como ferramentas que um modelo de IA encontra e chama sozinho. A API, por si, é um conjunto de endpoints sobre os quais um desenvolvedor escreve código. A diferença entre MCP e API cabe numa linha: a API é para o seu código, o servidor MCP é para um agente. Na assinatura eletrônica, isso decide quem escolhe o próximo passo. Com a API REST da Chaindoc, o seu código decide quando um contrato sai. Com o servidor MCP, quem decide é o agente, dentro dos limites da chave dele. A assinatura nunca passa para o agente.

O que é um servidor MCP? É o lado servidor do Model Context Protocol (MCP), um padrão aberto que a Anthropic publicou em 25 de novembro de 2024 para conectar aplicações de IA a ferramentas e dados externos. Em dezembro de 2025 o protocolo passou para a Agentic AI Foundation, dentro da Linux Foundation, então não pertence mais a um único fornecedor de modelos. A especificação atual tem a data 2026-07-28.

O MCP tem três papéis. O host é a aplicação de IA com a qual você conversa, o cliente é o conector dentro dela, e o servidor expõe o que um sistema externo sabe fazer, de três formas:

• Tools (ferramentas): funções que o modelo pode chamar, como «criar uma solicitação de assinatura».
• Resources (recursos): dados que o modelo ou o usuário podem ler, como o status de um contrato.
• Prompts, tarefas com nome que um usuário pode iniciar.

As mensagens são JSON-RPC 2.0. Um servidor roda como processo local que o cliente inicia (transporte stdio) ou atrás de um endpoint HTTP (Streamable HTTP).

Um servidor MCP é um servidor de verdade? Às vezes. Um servidor stdio é um processo no seu computador, que liga e desliga junto com o seu cliente de IA. Um servidor HTTP é um serviço que alguém precisa hospedar.

Por que «MCP ou API» é uma falsa escolha? Porque quase todo MCP server útil envolve uma API que já existe. O da Chaindoc liga suas ferramentas aos mesmos endpoints REST que o seu backend chamaria. Você não escolhe entre os dois. Você escolhe quem dirige: o seu código ou um modelo.

Os endpoints por baixo são idênticos. A diferença entre MCP e API é tudo o que cerca a chamada, e cinco partes dela aparecem assim que quem chama é um agente.

1. 1.
   Descoberta. O seu código conhece a API porque um desenvolvedor leu a documentação. Um cliente MCP pede ao servidor a lista de ferramentas (tools/list) em tempo de execução e repassa nomes, descrições e esquemas de entrada ao modelo. Se você conhece o function calling, é a mesma ideia num formato comum: um servidor funciona em qualquer cliente MCP.
2. 2.
   Quem escolhe a chamada. Numa integração por API, a sequência está escrita no código e roda igual toda vez. Com MCP, o modelo escolhe a ferramenta e preenche os argumentos a partir da sua frase, então o mesmo pedido pode seguir dois caminhos diferentes em dois dias.
3. 3.
   Os erros voltam para o modelo. A especificação separa erros de protocolo de erros de execução de uma ferramenta, e os segundos são feitos para chegar ao modelo, que pode corrigir um argumento e tentar de novo. Um backend registraria o erro e pararia.
4. 4.
   As credenciais ficam num arquivo de configuração. Um servidor stdio lê a chave de uma variável de ambiente que o seu cliente de IA repassa. Quem pode editar esse arquivo decide o que o agente pode fazer.
5. 5.
   A aprovação é tarefa do cliente. A página de ferramentas da especificação MCP recomenda (SHOULD) que uma pessoa possa intervir nas chamadas de ferramentas e recusá-las, e que os clientes peçam confirmação nas operações sensíveis. Uma chamada vinda do seu backend não tem essa etapa, a não ser que você a construa.

Falando com franqueza: o ponto dois é o que importa em contratos. Um script que envia um NDA envia exatamente o NDA para o qual foi escrito. Um agente envia o que entendeu que você queria. Para um documento que alguém vai assinar, essa distância precisa de uma trava.

O servidor MCP da Chaindoc é de código aberto. O código está no GitHub sob licença MIT, e o pacote se chama @chaindoc_io/mcp-server no npm, na versão 0.2.0 quando conferimos em 14 de outubro de 2026. A maioria das ferramentas corresponde a um único endpoint REST e devolve o resultado numa forma que o modelo sabe ler.

As ferramentas, por grupo

As tabelas principais do README listam 35 ferramentas em dez grupos:

• Documentos: criar, atualizar, definir permissões de acesso, verificar uma versão, ler o status de verificação.
• Assinaturas: criar uma solicitação, ler o status, listar as suas solicitações e assinar.
• Contratos, o grupo mais longo: criar, listar, ler, enviar, cancelar, rescindir, ler a atividade, anexar uma configuração de pagamento.
• Faturas e transações para a cobrança a partir de um contrato assinado: criar, enviar, cobrar, marcar como paga, listar pagamentos.
• Modelos: transformá-los em documento ou contrato, ou enviá-los direto para assinatura.
• Upload de mídia, sessões de assinatura incorporadas, duas verificações de conta e um verificador de webhook.

A versão 0.2.0 acrescentou busca, versões, lembretes, cancelamentos, download do arquivo assinado com o certificado e o ciclo de vida dos modelos.

Resources e prompts

Resources somente leitura, como chaindoc://contracts/{id}/status, ficam ao lado de prompts nomeados, como prepare_signature_request, que conduzem o modelo por uma tarefa mais longa.

Há duas coisas que ele não faz. Não registra webhooks: eles são definidos por chave de API no painel, e a ferramenta de webhook só confere um evento que você já recebeu. E a Chaindoc não hospeda nenhum endpoint: você o executa por stdio ou hospeda o modo HTTP por conta própria.

A verificação é a parte própria da Chaindoc. O servidor calcula o hash do arquivo no upload; quando uma versão é publicada, esse hash vai para a blockchain, e a prova de cada signatário é registrada quando a assinatura termina. As ferramentas de verificação comparam uma versão com esse registro, então um agente consegue responder «este é o arquivo que foi assinado?» sem que ninguém abra o aplicativo.

Não existe uma chave de API de MCP separada. O servidor roda com uma chave de API comum da Chaindoc, e as chaves são criadas no plano Business. Contas Team podem pedir acesso à API; Free e Personal não criam chaves, e os webhooks são só do Business.

Dois limites moldam o comportamento de um agente. O servidor se limita sozinho a 10 requisições por minuto por padrão, o limite que o guia da API da Chaindoc define, então um agente que percorre cinquenta documentos é lento de propósito. E o tráfego do agente corre pela sua conta como qualquer chamada de API: as solicitações que ele envia saem da mesma cota mensal de assinaturas. Veja os preços atuais antes de deixar um agente enviar em massa.

Resumindo: um agente pode apertar o botão, mas a lei nunca o trata como signatário. Signatário é aquele por quem o agente age, e é aí que acabam quase todas as dúvidas sobre contratos com IA.

Nos EUA: ESIGN e UETA

O ESIGN define a assinatura eletrônica como um som, símbolo ou processo executado ou adotado por uma pessoa com a intenção de assinar (15 U.S.C. § 7006(5)): a intenção é de uma pessoa. Para software, 15 U.S.C. § 7001(h) diz que um contrato não perde o efeito porque um agente eletrônico ajudou a formá-lo, desde que a ação do agente seja juridicamente atribuível à pessoa obrigada. A UETA, adotada por todos os estados menos Nova York, atribui a assinatura a quem praticou o ato (§ 9, por exemplo pelo procedimento de segurança usado: num servidor MCP, a chave de API), permite que um contrato se forme entre agentes sem revisão humana (§ 14) e deixa quem lidou com o seu agente e não pôde corrigir um erro anular o registro errado, se agir rápido (§ 10). Um fluxo sem etapa de revisão é um risco que você mesmo constrói.

No Brasil: MP 2.200-2, Lei 14.063 e Código Civil

A lei brasileira parte da mesma ideia: quem assina é uma pessoa. A Lei 14.063/2020, no art. 4º, divide as assinaturas eletrônicas em simples, avançada e qualificada e diz que cada tipo mede o nível de confiança sobre a identidade e a manifestação de vontade do titular. Um agente de IA não tem titularidade nenhuma, então a assinatura que ele dispara é sempre a de alguém. A MP 2.200-2/2001, no art. 10, § 2º, admite outros meios de comprovação de autoria e integridade, desde que as partes os aceitem como válidos ou que sejam aceitos pela pessoa a quem o documento for oposto. Na prática, vale o que as partes aceitaram, e vale ter isso por escrito.

No Código Civil, o art. 116 diz que a manifestação de vontade pelo representante, nos limites de seus poderes, produz efeitos em relação ao representado, e o art. 663 faz do mandante o único responsável quando o mandatário negocia expressamente em seu nome (o mandato nasce do art. 653). Um agente de IA não tem personalidade jurídica e não pode ser mandatário, mas o resultado prático é parecido: o que ele faz dentro do que você permitiu, você assume. Num servidor MCP, esse limite é o alcance da chave de API. O projeto do marco legal da inteligência artificial (PL 2.338/2023) ainda está em tramitação na Câmara dos Deputados, aguardando parecer do relator na comissão especial, e ainda não é lei.

Em Portugal, o ponto de partida é o eIDAS, que no art. 3, ponto 9, define o signatário como pessoa física, e o Decreto-Lei n.º 12/2021, que o executa na ordem jurídica portuguesa. Para empresas que querem marcar documentos sem uma pessoa atrás de cada um, o instrumento europeu é o selo eletrônico, criado por uma pessoa jurídica (art. 3, ponto 24); nosso guia sobre selos eletrônicos para empresas explica quando ele cabe.

Para um fluxo com MCP, a linha prática é simples. Deixe o agente preparar, enviar, cobrar retorno e verificar. A assinatura fica com a pessoa cuja vontade ela registra. Se um agente específico puder assinar um tipo específico de documento por você, decida isso por escrito e de propósito, nunca como padrão. Tome isto como um quadro de referência, não como parecer jurídico sobre o seu contrato.

Quatro pontos de um fluxo de assinatura merecem uma pessoa. O meio, chato, não é um deles.

• Antes de enviar qualquer coisa. A confirmação do seu cliente deveria cobrir toda ferramenta que envia, assina, cancela, rescinde ou cobra. Chamadas somente de leitura podem rodar sem perguntar.
• Os signatários e a ordem deles. Uma solicitação criada pelo agente convida todos os signatários de uma vez. Se a ordem importa (primeiro o gestor aprova, depois o cliente assina), isso é uma rota de aprovação que você configura no aplicativo da Chaindoc no plano Business, não algo que o agente improvisa.
• A identidade, quando o risco pede. O KYC dos signatários é opcional, pela verificação de identidade da Chaindoc, com cota mensal por plano. Decida por tipo de contrato, não deixe para o modelo.
• O que o agente lê. Um texto pode trazer instruções que você não escreveu: uma linha num PDF enviado, uma nota num registro do CRM. A especificação MCP trata, pelo mesmo motivo, como não confiáveis as anotações de ferramentas de um servidor em que você não confia.

O que pode rodar sem supervisão? Consultas de status, lembretes para quem já tem o documento, a verificação de um arquivo contra o registro na blockchain. Cada documento guarda a sua própria trilha de auditoria, então até as chamadas sem supervisão deixam um registro que você pode reler.

A DocuSign anunciou em 4 de setembro de 2026 que o seu servidor MCP ficaria disponível para todos em 30 de setembro, com chamadas a partir do Claude, ChatGPT, Gemini, Copilot, Slack e qualquer cliente MCP. A DocuSign o hospeda, e a conexão passa por um login OAuth e uma tela de consentimento, em vez de uma chave colada num arquivo de configuração. É uma vantagem real para a empresa que não quer chaves de API em notebooks, e a Chaindoc hoje não oferece um endpoint hospedado.

No eixo MCP vs API, os dois se parecem: cada servidor envolve a API do seu fornecedor. No controle, porém, a troca vai no sentido oposto. O servidor da Chaindoc é código sob licença MIT que você pode ler, bifurcar e hospedar dentro da sua própria rede, e as ferramentas dele alcançam o registro de verificação na blockchain, além da assinatura. Se você compara uma conexão MCP da DocuSign com a da Chaindoc para um agente, faça três perguntas práticas: quem guarda a credencial, onde o servidor roda e quais ações o agente pode fazer sem a aprovação de uma pessoa.

Use a API quando o fluxo é fixo. Um negócio vira «ganho», um contrato sai de um modelo, um webhook atualiza o CRM quando alguém assina. Isso é código, precisa se comportar igual toda vez, e um agente só acrescenta variação. Se você quer automação de documentos com IA dentro de um fluxo fixo, chame um modelo a partir do seu próprio código e deixe a API fazer o envio. Nosso comparativo de APIs de assinatura eletrônica diz o que olhar desse lado.

Use o servidor MCP quando o pedido muda toda vez e há uma pessoa na conversa de qualquer jeito: «envie o contrato de prestação de serviços para as duas pessoas da call de ontem», «quais NDAs do mês passado ainda não foram assinados?», «este PDF é a versão que assinamos?». É chato de programar e fácil de dizer. Um exemplo: uma startup em São Paulo deixa um agente preparar e enviar contratos de prestação de serviços, e quem assina é o sócio, pelo link, com o nome dele.

A maioria das equipes acaba com os dois, em chaves separadas, e essa é a resposta honesta sobre MCP ou API. A API executa o que você já decidiu, e o agente cuida do que você ainda não decidiu. Quem chegou aqui perguntando o que é MCP leva o essencial: é a camada que deixa um agente usar a API que você já tem. Nos dois casos, a assinatura fica com uma pessoa.