Ligar o primeiro servidor MCP

O essencial

Uma ligação é feita de três indicações: o programa que é iniciado, os seus argumentos e as credenciais como variáveis de ambiente.
As credenciais nunca pertencem ao próprio ficheiro de configuração, mas a uma variável de ambiente ou a um cofre de chaves.
Os três erros mais frequentes: caminho errado para o programa, falta de reinício da aplicação, e uma chave de acesso com permissões demasiado amplas.
Antes da entrada em produção há uma pequena lista de verificação – sobretudo a pergunta sobre o dano máximo que um passo em falso pode causar.

O Model Context Protocol é uma norma aberta através da qual um modelo de linguagem pode aceder a ferramentas e dados – ficheiros, calendário, um CRM, uma base de dados. A vantagem face às soluções isoladas: o que existe uma vez como servidor MCP funciona com qualquer aplicação que fale a norma.

A primeira ligação é o ponto em que muitos desistem – não por ser complicado, mas porque as mensagens de erro são pouco específicas.

As três partes de uma ligação

O servidor

Um pequeno programa que disponibiliza uma fonte de dados ou uma ferramenta. Corre no vosso computador ou num servidor e é iniciado quando é preciso – não têm de o escrever, para os sistemas correntes já existem servidores prontos.

O cliente

A aplicação em que trabalham e que fala com o servidor. Inicia-o, pergunta-lhe que ferramentas oferece e apresenta-as ao modelo.

A configuração

Um pequeno ficheiro que diz ao cliente: iniciar este programa, com estes argumentos, com estas credenciais. Não tem mais nada – e é precisamente aqui que acontecem a maioria dos erros.

A configuração em seis passos

Escolher o servidor. Comecem com um acesso de leitura a algo não crítico – uma pasta de ficheiros, uma documentação. Não com o CRM.
Verificar o ambiente de execução. A maioria dos servidores precisa de Node.js ou Python. Verifiquem a versão antes de começar: node --version ou python --version.
Criar a chave de acesso – o mais restrita possível. Se o servidor só tiver de ler, deem-lhe apenas direitos de leitura. É o passo que mais vezes é feito com demasiada generosidade.
Introduzir a configuração. Programa, argumentos, variáveis de ambiente. Usar caminhos absolutos, não relativos.
Terminar a aplicação por completo e reiniciar. Não basta fechar a janela – a configuração é lida no arranque.
Verificar se as ferramentas apareceram. O cliente mostra que ferramentas um servidor oferece. Se ali não aparecer nada, o servidor não arrancou.

Atenção Nunca escrevam uma chave de acesso diretamente num ficheiro de configuração que esteja numa pasta de projeto. Esses ficheiros acabam, pela experiência, em cópias de segurança, em sistemas de controlo de versões e em capturas de ecrã. Usem uma variável de ambiente ou o cofre de chaves do sistema operativo.

Os obstáculos que não constam de nenhuma documentação

O caminho não está certo

O erro mais frequente de todos. A aplicação inicia o servidor num ambiente diferente do da vossa linha de comandos – um programa que é encontrado no terminal pode ali ser desconhecido.

Solução: indicar o caminho completo. No macOS e no Linux descobre-se com which node, no Windows com where node.

Sem reinício

A configuração é lida no arranque da aplicação. Fechar a janela não chega – no macOS a aplicação continua a correr.

Solução: terminar por completo e reiniciar. Parece banal, custa com regularidade meia hora.

A chave tem permissões a mais

Uma chave de acesso com direitos de escrita e de eliminação não dá nas vistas na configuração. Dá nas vistas quando uma instrução é mal interpretada.

Solução: criar duas chaves – uma de leitura para o dia a dia, uma de escrita apenas onde escrever é mesmo preciso.

O servidor arranca, mas não anuncia nada

Um servidor que aborta no arranque aparece no cliente, na maior parte das vezes, simplesmente vazio – sem mensagem de erro.

Solução: executar o comando de arranque uma vez à mão na linha de comandos. Aí aparece o que falta.

Sabia que…?

Um servidor MCP descreve as suas próprias ferramentas – nome, finalidade, dados esperados. O modelo só fica a saber em tempo de execução o que consegue fazer.

Daí resulta algo prático: a qualidade dessas descrições determina em boa medida a fiabilidade com que uma ferramenta é usada. Um servidor com a descrição «Procura contactos» é pior servido do que um com «Procura contactos por nome de empresa ou endereço de e-mail; devolve no máximo 50 resultados; não encontra registos eliminados». Quem constrói um servidor próprio investe melhor o tempo nestes textos.

Lista de verificação antes da entrada em produção

Pergunta	Porque conta
Qual é o dano máximo de um passo em falso?	determina se os direitos de escrita são defensáveis
O acesso está registado?	sem registo, nada se consegue reconstruir depois
Quem conhece a chave de acesso?	determina quem a tem de mudar quando alguém sai
Há dados pessoais no acesso?	então aplicam-se deveres de proteção de dados – também junto do fornecedor do modelo
Como se desliga rapidamente?	tem de estar esclarecido antes de ser preciso

Da prática

A quarta linha é quase sempre saltada durante as experiências e é a de maiores consequências. Assim que um servidor tem acesso a dados de clientes, esses dados são transmitidos ao fornecedor do modelo – é uma subcontratação com tudo o que isso implica.

Para a primeira tentativa isso significa: usar uma pasta com ficheiros não críticos, não a lista de clientes. A diferença entre «experimentar» e «em produção» não é de natureza técnica – nasce no momento em que entram dados reais.

Prompt

Ajuda-me a configurar e verificar a minha primeira ligação MCP.

A minha situação:
- Sistema operativo: [macOS / Windows / Linux]
- Aplicação em que trabalho: [cliente]
- O que quero ligar: [fonte de dados ou ferramenta]
- O acesso deve ler ou também escrever? [ler / ambos]
- Há dados pessoais no acesso? [sim / não / não sei]

Tarefas:
1. Indica as informações que tenho de introduzir na configuração
   e explica cada uma numa frase.
2. Diz-me como descubro, no meu sistema operativo, o caminho
   completo para o programa.
3. Indica as permissões mais restritas possíveis para a chave de
   acesso. Fundamenta porque permissões mais amplas não são
   necessárias.
4. Dá-me três passos de verificação para saber se o servidor está
   a correr – e o que fazer em cada caso se não estiver.
5. Se houver dados pessoais no acesso: indica o que tem de estar
   resolvido antes.

Não me peças as credenciais em si – essas introduzo eu como
variável de ambiente.

Conclusão

A barreira técnica é mais baixa do que parece: três indicações num ficheiro de configuração, um reinício, pronto. Os três erros recorrentes são um caminho relativo em vez de absoluto, um reinício esquecido e uma chave de acesso demasiado generosa.

A verdadeira decisão não é técnica: está em decidir a que concedem acesso. Comecem por algo em que um passo em falso não tenha consequências – e resolvam as questões de proteção de dados antes de entrarem dados reais de clientes, não depois.

Perguntas frequentes

Como se configura um servidor MCP?

Em seis passos: escolher um servidor para uma fonte de dados não crítica, verificar o ambiente de execução (normalmente Node.js ou Python), criar uma chave de acesso com permissões o mais restritas possível, introduzir programa, argumentos e variáveis de ambiente na configuração, reiniciar a aplicação por completo e verificar se as ferramentas aparecem no cliente.

São precisos conhecimentos de programação para uma ligação MCP?

Não, se existir um servidor pronto para o sistema em causa. A configuração consiste em introduzir três indicações num ficheiro. Conhecimentos de programação só são precisos para quem escreve um servidor próprio para um sistema que ainda não o tem.

Porque é que o servidor MCP não aparece na aplicação?

Normalmente por uma de três razões: o caminho para o programa está indicado como relativo em vez de absoluto e não é encontrado no ambiente da aplicação, a aplicação não foi terminada por completo e reiniciada, ou o servidor aborta no arranque. O último caso descobre-se executando o comando de arranque uma vez à mão na linha de comandos.

Onde se guardam as credenciais de um servidor MCP?

Numa variável de ambiente ou no cofre de chaves do sistema operativo – nunca diretamente no ficheiro de configuração. Esses ficheiros acabam, pela experiência, em cópias de segurança, sistemas de controlo de versões e capturas de ecrã. Fazem também sentido duas chaves separadas: uma de leitura para o dia a dia, uma de escrita apenas onde é precisa.

O que é preciso ter em conta na proteção de dados?

Assim que um servidor tem acesso a dados pessoais, esses dados são transmitidos ao fornecedor do modelo – é uma subcontratação, com contrato, menção na política de privacidade e uma base para a transferência para o estrangeiro. Para as primeiras experiências, uma pasta com ficheiros não críticos é por isso o ponto de partida certo.