Para ser profissional, um servidor MCP de empresa precisa de seis coisas antes de o partilhares: autenticação que corresponda à especificação atual, uma fronteira de dados que consigas explicar numa frase, respostas que citem as fontes, conteúdo tão fresco como o negócio, ferramentas pelas quais consegues responder e um nome que diga em nome de quem fala. Tudo o que se segue é essa lista, expandida em verificações que podes mesmo executar.

1. Autenticação que corresponde à especificação atual

A autenticação MCP evoluiu depressa, e os clientes seguem a especificação, não o teu calendário de lançamentos. Atual significa OAuth 2.1: os utilizadores iniciam sessão como eles próprios, os tokens trazem um issuer que o servidor valida e o registo de clientes segue o fluxo CIMD, para que novos clientes MCP se possam ligar sem um ticket de configuração manual. Os servidores SuperCognit implementam isto de origem; se construíste o teu à mão contra um rascunho mais antigo da especificação, corrige isto primeiro, porque é a coisa que falha no momento da ligação — à frente da pessoa com quem o partilhaste.

  • Cada utilizador autentica-se individualmente — nada de chaves partilhadas num ficheiro de configuração que sobrevivem à pessoa que as colou lá.
  • A validação de issuer está ligada. Um token vindo do sítio errado é um não.
  • A ligação funciona a partir do Claude e de pelo menos mais um cliente MCP. Testa os dois antes que outra pessoa o faça.

2. Uma fronteira que consegues explicar numa frase

A frase é: este servidor responde a partir deste workspace, e de mais nada. O isolamento por workspace torna isso estrutural em vez de aspiracional — o servidor não consegue alcançar conhecimento que não esteja no seu workspace. O teu trabalho é a parte deliberada: decidir o que entra e se o servidor é privado ou público. Um servidor privado é um cérebro interno da empresa — procedimentos, políticas, factos de produto para a tua própria equipa. Um público fala pela empresa a qualquer pessoa que se ligue. São produtos diferentes, e a escolha deve ter um nome associado, não ser um valor por omissão.

3. Respostas que mostram as fontes

Um MCP de empresa é citado — em documentos, em decisões, mais tarde ou mais cedo numa reunião em que alguém pergunta de onde veio aquilo. Respostas com citações tornam esse momento aborrecido em vez de perigoso para a carreira. Quando a base de conhecimento é construída por rastreio do teu site, cada resposta aponta para a página de onde veio; os documentos carregados são citados da mesma forma.

  • Faz as dez perguntas que a tua equipa realmente faz, e segue cada citação até à fonte.
  • A mesma construção produz um agente de chat — usa-o como teste rápido. Se as respostas do chat estiverem erradas, as respostas do MCP estão erradas com passos extra.
  • Nada na base de conhecimento te envergonharia citado palavra por palavra. Vai ser citado palavra por palavra.

4. Conteúdo tão fresco como o negócio

Respostas desatualizadas são piores do que resposta nenhuma, porque chegam com confiança. O conhecimento ressincroniza com uma cadência definida — até de hora a hora — e a cadência é uma decisão por fonte, não um interruptor global para ligar e esquecer. As páginas de preços, disponibilidade e políticas merecem uma cadência rápida; a página da história da empresa pode esperar. Nos documentos carregados, a sincronização não te salva: cada documento precisa de um dono que o substitua quando a realidade mudar, ou o servidor torna-se um arquivo muito confiante.

5. Ferramentas pelas quais consegues responder

O conhecimento responde a perguntas; as ferramentas executam ações. As ferramentas HTTP que associas tornam-se ferramentas MCP invocáveis, o que significa que qualquer pessoa ligada as pode invocar — por isso o padrão é mais rigoroso do que para o conteúdo. Antes de partilhar, deves conseguir dizer, sobre cada ferramenta do servidor: o que pode tocar, o que faz a pior chamada plausível e porque é que está sequer associada. Uma lista de ferramentas curta é uma funcionalidade, não uma lacuna. Um servidor é julgado pelo que consegue fazer, não apenas pelo que sabe.

6. Um nome que diz em nome de quem fala

Há suporte para domínios personalizados e, num servidor de empresa, não são cosméticos. Uma equipa que se liga ao teu próprio hostname sabe de quem é o produto e quem está por trás das respostas; um URL de plataforma diz o contrário. Se o servidor vai falar pela empresa, deve viver no nome da empresa.

Repara no padrão da lista: nada disto é código, tudo isto são decisões — o que entra, quem se liga, com que frescura, o que pode fazer, de quem é o nome que lá está. A construção em si é a parte rápida; uma base de conhecimento rastreada e citada existe cerca de dois minutos depois de importares o site. Gasta na checklist o tempo que poupaste.