Instalar o servidor MCP da SignDocs pelo registro oficial
Instalar um servidor MCP copiando um trecho de configuração de um site é o caminho normal hoje, e vale reparar no que ele exige de confiança: você está executando código na sua máquina, com credenciais, a partir de uma instrução que alguém publicou numa página. O registro oficial de MCP existe para reduzir essa dependência — ele é o índice em que servidores são publicados sob um nome que prova quem os publicou. O servidor da SignDocs Brasil está lá, sob um namespace verificado por DNS. Este guia explica o que isso garante, o que não garante e como instalar a partir dali.
O essencial: o servidor está publicado no registro oficial de MCP sob um namespace derivado de signdocs.com.br, com o controle do domínio comprovado por DNS. Isso prova procedência — que quem publicou controla o domínio. Não é uma auditoria de segurança, e vale entender a diferença.
O problema que o registro resolve
O caminho normal para instalar um servidor MCP hoje é copiar um bloco de configuração de uma página e colá-lo no cliente. Vale olhar para o que esse gesto envolve: você passa a executar código na sua máquina, com credenciais em variáveis de ambiente, a partir de uma instrução publicada em algum lugar da internet.
Na maior parte das vezes está tudo bem. O risco aparece nas bordas — uma página desatualizada, um nome de pacote parecido com o certo, um tutorial de terceiro que ninguém revisou. O registro oficial existe para dar um ponto de referência: um índice em que cada servidor é publicado sob um nome que identifica quem o publicou.
O que o namespace verificado por DNS significa
Servidores no registro podem ser publicados sob dois tipos de namespace. Um deriva de uma conta de repositório; o outro deriva de um domínio, com o controle comprovado por um registro DNS.
O servidor da SignDocs usa o segundo: o namespace vem de signdocs.com.br — o mesmo domínio do site, da API e do painel. A publicação só é aceita porque quem publicou demonstrou controlar aquele domínio.
A diferença prática, para quem avalia:
| Namespace por conta de repositório | Namespace por domínio |
|---|---|
| Liga a publicação a um perfil | Liga a publicação a um domínio |
| O perfil pode ser pessoal ou não ter relação óbvia com a empresa | É o mesmo domínio do produto que você já conhece |
| Verificar exige saber qual conta é a legítima | Verificar é reconhecer o domínio |
Para quem precisa aprovar a instalação numa máquina corporativa, a segunda forma é bem mais fácil de checar: o nome do servidor contém o domínio da empresa fornecedora, e não uma conta que exigiria uma investigação para confirmar.
O que o registro não garante
Vale ser explícito, porque a confusão é comum e cara:
- Não é auditoria de código. O registro não revisa o que o servidor faz.
- Não é selo de qualidade. Estar listado não diz nada sobre estabilidade ou manutenção.
- Não substitui o seu julgamento sobre permissões. Um servidor legítimo continua sendo um servidor que executa ações em seu nome.
A pergunta que a verificação responde é "é mesmo deles?". A pergunta "isto é seguro para o meu contexto?" continua sendo sua — e, no caso de ferramentas de assinatura, ela envolve escopo de credencial, aprovação de ferramentas consequentes e escolha de ambiente.
Os dados canônicos
Seja instalando pelo registro ou à mão, estes são os valores corretos:
| Item | Valor |
|---|---|
| Pacote npm | @signdocs-brasil/mcp-server |
| Execução | npx |
| Transporte | stdio |
| Variáveis obrigatórias | SIGNDOCS_CLIENT_ID, SIGNDOCS_CLIENT_SECRET |
| Variável opcional | SIGNDOCS_ENVIRONMENT — assume homologação |
Conferir o nome do pacote importa mais do que parece: pacotes com nomes parecidos são um vetor conhecido em qualquer ecossistema de distribuição, e o registro é justamente o lugar onde o nome correto está associado ao domínio verificado.
Instalando
Clientes com suporte a descoberta permitem buscar pelo nome e instalar direto — o cliente lê do registro o pacote, o transporte e quais variáveis pedir, e monta a configuração sozinho.
Onde isso ainda não existe, o registro serve como fonte confiável dos dados que você vai escrever à mão:
A tradução desse bloco para outros formatos de cliente está em conectar o servidor MCP a qualquer cliente.
Versões
O registro publica a versão do servidor junto do registro dele, acompanhando a versão do pacote npm. Como a execução por npx resolve o pacote a cada início, uma configuração assim tende a pegar a versão corrente sem esforço.
Se você optou por instalar globalmente — o que evita a resolução a cada início —, a atualização passa a ser explícita, e vale colocá-la na mesma rotina em que você atualiza outras dependências. É o preço de fixar a versão, e é uma escolha legítima em ambiente controlado.
Preciso do registro?
Não. Instalar direto pelo npm funciona igual, e é o que a maior parte das pessoas faz. O registro acrescenta duas coisas:
- Procedência verificável — útil principalmente quando outra pessoa precisa aprovar a instalação numa máquina da empresa. "O namespace é o domínio deles" é um argumento curto de checar.
- Descoberta — o servidor aparece para quem procura por capacidade em vez de por nome.
Se você está instalando na sua própria máquina, para testar, o caminho direto é perfeitamente adequado — começando por homologação, onde os dados expiram em cerca de sete dias e nenhuma assinatura tem efeito real.
Depois de conectado, o comportamento que vale conhecer antes do primeiro envio real é a ordem dos signatários em linguagem natural. Para o produto por trás das ferramentas, a visão geral da API de assinatura eletrônica.
Perguntas Frequentes
O que é o registro oficial de MCP?
Um índice público de servidores MCP, mantido pelo projeto do protocolo, em que cada servidor é publicado sob um namespace que identifica quem o publicou. Clientes e ferramentas podem consultá-lo para descobrir e instalar servidores sem depender de um trecho de configuração copiado de uma página qualquer.
O que significa namespace verificado por DNS?
Que o nome do servidor deriva de um domínio cujo controle foi comprovado por um registro DNS. No caso da SignDocs, o namespace é derivado do domínio signdocs.com.br — o mesmo do site e da API. É uma alternativa ao namespace baseado em conta de repositório, e liga a publicação ao domínio, não a um perfil individual.
Isso garante que o servidor é seguro?
Não, e é importante ser claro. O registro garante procedência: que quem publicou controla aquele domínio. Ele não audita o código, não avalia a qualidade nem promete que o servidor não faz algo indesejado. A verificação responde "é mesmo deles?", não "é seguro?".
Como instalo a partir do registro?
Clientes com suporte a descoberta permitem buscar pelo nome e instalar direto. Onde isso não existe, o registro é a fonte confiável dos dados que você vai colocar na configuração: o pacote npm correto, o transporte e as variáveis de ambiente exigidas.
Qual é o pacote e o transporte?
O pacote é @signdocs-brasil/mcp-server, no npm, executado via npx sobre stdio. As variáveis obrigatórias são o identificador e o segredo da credencial; o ambiente é opcional e assume homologação quando não informado.
Como sei se estou na versão atual?
O registro publica a versão junto do servidor, e ela acompanha a versão do pacote npm. Como a execução por npx resolve o pacote a cada início, uma instalação nova pega a versão corrente sem esforço; instalações globais precisam ser atualizadas explicitamente.
Preciso do registro para usar o servidor?
Não. Instalar direto pelo npm funciona igual e é o que a maioria faz. O registro adiciona procedência verificável e descoberta — úteis principalmente quando outra pessoa vai avaliar se aquele servidor deve rodar numa máquina da empresa.
Instale a partir de uma fonte verificável
O namespace verificado por DNS liga o servidor ao domínio que você já conhece. Comece em homologação, onde os dados expiram em cerca de 7 dias.
Criar credenciais de homologação Fale com o time comercial