Como pôr o teu servidor MCP no teu próprio domínio (e porque é que isso importa para a tua marca)

Pôr o teu servidor MCP no teu próprio domínio pede apenas um registo DNS: escolhe um subdomínio — mcp.atuaempresa.com é a convenção que se está a formar —, aponta-o para onde o painel do SuperCognit te indicar, e o teu servidor passa a ser servido a partir do teu endereço, com o certificado tratado. Nada muda no protocolo. O que muda é a quem o servidor parece pertencer — e, para um servidor MCP, isso vale mais do que parece.

O URL é quase toda a superfície do produto

Um produto tradicional tem uma homepage, capturas de ecrã, uma listagem algures. Um servidor MCP tem um URL. Esse URL é o que se cola na configuração de um cliente, o que aparece na tua documentação, o que um colega reenvia a outro com as palavras 'adiciona isto'. Não há embalagem à volta. Quando o endereço é um subdomínio da plataforma, é a plataforma que as pessoas veem; quando é o teu domínio, o servidor lê-se como infraestrutura tua — porque é.

O momento OAuth

A primeira vez que alguém se liga, o servidor pede autenticação — os servidores SuperCognit implementam OAuth 2.1 conforme a especificação atual do MCP, com validação de emissor e registo CIMD incluídos. Um pedido de autenticação é um momento de julgamento: as pessoas decidem em cerca de dois segundos se iniciar sessão parece bem. Um início de sessão associado ao teu próprio domínio condiz com aquilo a que elas acreditam estar a ligar-se. Um início de sessão vindo de um endereço de que nunca ouviram falar acaba numa captura de ecrã publicada no chat da empresa com um ponto de interrogação.

Se cobras por ele, isto deixa de ser cosmético

O SuperCognit permite-te vender acesso a um servidor MCP por utilizador — subscrições Stripe, faturas e pagamentos vêm incluídos, com o SuperCognit como merchant of record, que fica com uma comissão de plataforma. No momento em que há dinheiro envolvido, o endereço faz parte do argumento de venda. Uma firma de contabilidade de 40 pessoas que vende aos clientes um servidor de regras fiscais está a pedir-lhes que ponham um endereço nas suas ferramentas e uma subscrição no cartão; um endereço que a firma visivelmente possui torna mais fácil dizer que sim a ambos os pedidos.

Os endereços são estruturais

A partir do momento em que o teu URL está em cinquenta configurações de clientes, é infraestrutura — todas as configurações que o referenciam partem-se se ele mudar de sítio. Isso é um argumento para acertar no endereço antes de o distribuíres em larga escala, e acertar significa um que controlas. A versão honesta deste argumento corta nos dois sentidos: um domínio que possuis é um domínio que podias apontar para outro lado. Que o argumento mais forte a favor de um domínio personalizado sirva também de porta de saída é, achamos nós, como as relações com fornecedores deviam funcionar.

O que não muda

• Comportamento do protocolo: ferramentas, conhecimento e autenticação funcionam de forma idêntica em qualquer dos endereços, no Claude e em qualquer cliente MCP.
• Segurança: OAuth 2.1, validação de emissor e isolamento por espaço de trabalho são iguais nos dois casos — um domínio personalizado é identidade, não armadura.
• A construção: a mesma base de conhecimento, as mesmas ferramentas, o mesmo agente de chat publicado em paralelo.

Como configurar

Um domínio personalizado não torna bom um servidor mau. Faz com que um bom servidor pareça o que é: uma peça da infraestrutura da tua empresa que por acaso fala MCP, num endereço em que os teus clientes ainda vão confiar — e a que ainda vão chegar — daqui a uns anos.