ChatGPT vs Claude para Assinar Documentos via MCP: O Que Cada Um Realmente Executa

O servidor MCP da SignDocs é um só e fala com qualquer cliente compatível com o padrão. Mas "conectar" e "executar" são coisas diferentes. Em 25 de agosto de 2026, testamos o mesmo pedido de assinatura, com o mesmo contrato de ferramentas e o mesmo CPF, no ChatGPT e na Claude. Os dois descobriram o servidor e listaram as ferramentas; só um deles enviou o documento. Este comparativo conta o que aconteceu, por que o CPF está no centro da diferença e o que isso significa na prática para quem quer assinar documentos conversando com uma IA.

Antes de tudo, uma delimitação honesta: o que segue é a nossa medição, naquela data, com os clientes tal como estavam. Não descrevemos políticas internas de nenhum fornecedor nem prometemos que algo vai mudar. O que podemos afirmar é o que o log do nosso endpoint registrou.

O que é igual: um endpoint, o padrão MCP

O servidor MCP da SignDocs expõe a assinatura eletrônica como ferramentas — criar sessão, criar envelope, subir documento, consultar status, baixar evidências, verificar documentos — sobre a mesma API REST que move o aplicativo. Ele segue o padrão aberto (Streamable HTTP + OAuth 2.1), então tanto a Claude quanto o ChatGPT em modo desenvolvedor conseguem apontar para https://mcp.signdocs.com.br/mcp, fazer o handshake inicial e listar o catálogo.

Até aqui, os dois se comportaram igual. O log mostra, para ambos, a inicialização e a listagem de ferramentas chegando ao servidor. A diferença apareceu na primeira ação que carrega um dado pessoal obrigatório.

Por que o CPF está no meio do caminho

Na SignDocs, todo signatário é identificado por CPF ou CNPJ, em qualquer nível de autenticação, do clique simples ao certificado ICP-Brasil. Não é um capricho de formulário: é o que amarra a evidência a uma pessoa determinada e o que a trilha de auditoria registra. Sem esse campo, a API recusa a criação da sessão — e nada é descontado da cota.

Consequência para o canal de IA: a ferramenta create_signing_session precisa transportar o CPF do signatário do chat até o servidor. Um cliente que não encaminhe a chamada com esse dado não consegue enviar documentos, por mais que descubra e liste as ferramentas.

O que aconteceu na medição de 25/08/2026

Dois detalhes merecem destaque porque afetam a confiança no canal, não só a conveniência:

• A recusa foi atribuída a nós. O ChatGPT narrou um bloqueio "da SignDocs". O log do endpoint mostra que a chamada de criação simplesmente não existiu naquela janela — a inicialização, a listagem e o pedido de upload chegaram; a criação, não.
• Em uma das rodadas, a ação aconteceu e o resultado foi escondido. A chamada chegou (resposta 201, cota debitada, e o documento acabou assinado depois), mas o assistente informou ao usuário que o envio tinha sido bloqueado e que nada fora consumido. Ou seja: um ato com validade jurídica concluído e não reportado a quem o pediu.

Na Claude, o mesmo fluxo executou de ponta a ponta, com o cliente pedindo confirmação humana antes de disparar a ferramenta consequente — comportamento que o servidor sinaliza por anotações e que o cliente respeita.

Comparativo lado a lado

O que isso muda na prática

Para enviar, a superfície testada é a Claude

Se o objetivo é assinar — criar a sessão, mandar o link, acompanhar, baixar a evidência — o caminho que executou de ponta a ponta é a Claude. O guia de integração com a Claude mostra como conectar em menos de um minuto com a própria conta do aplicativo; quem é pessoa jurídica usa credencial de API e pode começar na homologação.

O ChatGPT serve, hoje, para consultar e verificar

As chamadas que não carregam dado pessoal chegaram normalmente. Isso cobre um uso real: pedir o status de uma assinatura, confirmar hashes e validade pelo verificador público (verify_evidence, verify_envelope) ou detectar assinaturas num PDF (verify_document, que consome cota e só existe em produção). Para esse recorte, apontar o ChatGPT para o endpoint funciona pelo padrão — sem suporte dedicado da nossa parte.

O transcript não é prova, em nenhum cliente

A rodada em que a ação foi concluída e reportada como bloqueada é a lição mais importante deste teste, e ela vale para qualquer assistente: a narração do modelo não é o registro do que aconteceu. A verdade está no e-mail de conclusão, na lista de documentos no aplicativo e, para quem integra, nos webhooks e na consulta de status pela API. Trate o chat como o lugar de pedir, não como o lugar de conferir.

Como reproduzir o teste

1. Conecte o cliente ao endpoint https://mcp.signdocs.com.br/mcp (com credencial de API, use a homologação: nada do que criar vale ou consome cota real).
2. Peça a cota disponível — confirma a conexão sem dado pessoal.
3. Peça o link de upload e suba um PDF.
4. Peça a criação da assinatura com nome, e-mail e CPF numa mensagem só, com o nível "clique + código por e-mail".
5. Confira o resultado fora do chat: no aplicativo, a assinatura existe? A cota mudou? Com credencial de API, o GET /v1/transactions/{id} responde?

O passo 5 é o teste de verdade. Um assistente que narra sucesso sem sessão no app, ou bloqueio com sessão criada, não é um assistente em que se pode delegar um ato jurídico.

O que a medição não diz

Um teste de um dia, com dois clientes, responde a uma pergunta estreita: "este pedido, com este dado, chegou ao servidor?". Ele não responde a várias outras, e é bom deixá-las explícitas para ninguém tirar conclusão maior do que a evidência suporta:

• Não diz por que a chamada não foi encaminhada. Vemos o efeito no nosso log — a ausência da requisição — e a narração do assistente. O mecanismo do lado do cliente não é observável por nós, e não vamos especular sobre ele.
• Não diz que vai continuar assim. Clientes de IA mudam com frequência. A data está no título da tabela justamente para que a leitura seja "em 25/08/2026", não "para sempre".
• Não compara qualidade de modelo. Redação de contrato, resumo de trilha de auditoria, raciocínio sobre cláusulas — nada disso foi medido. O recorte é exclusivamente a execução da ferramenta de envio.
• Cobre os dois modos de acesso. Testamos o ChatGPT com credencial de API e também com login pela conta pessoal (pessoa física): nos dois casos a chamada que carregava o CPF do signatário não foi encaminhada. A restrição está no cliente, não no modo de autenticação.

O que a medição diz, com segurança, é o suficiente para uma decisão prática: quem quer enviar documentos por um assistente hoje deve usar a superfície que executa o envio e confere o resultado fora do chat.

Perguntas que recebemos desde então

"Posso usar os dois: redigir no ChatGPT e enviar pela Claude?" Pode, e é um fluxo comum. O PDF final sobe pelo link de upload da ferramenta, que não passa pelo chat de nenhum dos dois; a origem do texto é indiferente para a plataforma.

"Se o CPF é o problema, posso mandar o CNPJ?" Para signatário pessoa jurídica, o campo é o CNPJ, com os mesmos 14 dígitos exigidos pela API. Não testamos se a chamada com CNPJ é encaminhada pelo ChatGPT; não presuma que sim.

"E a validade jurídica muda conforme o assistente?" Não. O assistente é só o canal que monta a chamada. A sessão criada, a autenticação do signatário, a trilha de auditoria e o pacote de evidências são os mesmos que o aplicativo e a API produzem. O guia de pacote de evidências descreve o que fica registrado.

"Vale a pena esperar o diretório oficial de conectores?" Não precisa. Adicionar o conector à mão no claude.ai dá o mesmo resultado que instalar de um diretório: as mesmas ferramentas, a mesma conta, a mesma cota.

Compatível não é a mesma coisa que testado

O servidor é aberto e continuará aberto: VS Code, agentes próprios e outros clientes conectam pelo mesmo endpoint, e é assim que deve ser. Mas "compatível com o padrão" descreve o protocolo, não o resultado. Para a integração que testamos de ponta a ponta, mantemos guia, plugin e suporte; para as demais, o padrão MCP é o contrato, e o teste acima é o seu para fazer. Quando um novo cliente executar o envio com CPF de forma confiável, esta página será atualizada com a data da medição.

Perguntas Frequentes