O que é, afinal, um servidor MCP?
Retirado o marketing, o MCP é um protocolo pequeno e aborrecido. Essa é a sua melhor qualidade.
Um modelo de linguagem, sozinho, não consegue ler os seus ficheiros, consultar a sua base de dados nem lembrar-se de ontem. Produz texto. Tudo o resto — cada ação, cada consulta — acontece porque algum programa exterior ao modelo foi fazê-lo.
Antes do Model Context Protocol, cada uma dessas ligações era feita à medida. Se queria que o Claude lesse o seu Notion e que o ChatGPT lesse o seu Notion, escrevia duas integrações contra dois sistemas de plugins diferentes, e nenhuma sobrevivia à versão seguinte do fornecedor. O MCP é o acordo que põe fim a isso: um servidor, qualquer cliente que fale o protocolo.
A forma geral
Há três partes. O host é a aplicação que efetivamente usa — um assistente de secretária, um IDE, uma interface de conversa. O cliente vive dentro do host e gere uma ligação. O servidor é a coisa que você, ou outra pessoa, escreveu, e é ele que detém a capacidade: acesso a um sistema de ficheiros, a uma instância Postgres, a um calendário, a uma memória.
Falam JSON-RPC 2.0. Não é um detalhe em que valha a pena demorar-se, mas vale a pena sabê-lo, porque significa que o conjunto é inspecionável. Pode ler as mensagens. Não há nenhuma camada mágica onde o modelo «decide» algo que não consegue ver.
A sequência é monótona de propósito: o cliente liga-se, os dois lados trocam capacidades, o cliente pergunta o que o servidor oferece, e a partir daí o modelo pode pedir uma dessas coisas pelo nome. O servidor executa. O resultado volta sob a forma de texto que o modelo lê.
As três coisas que um servidor pode expor
Quase todos os servidores com que se vai cruzar usam a primeira e ignoram as outras duas. Vale a pena compreender as três, porque a diferença é sobre quem decide.
- Tools (ferramentas) — funções que o modelo pode invocar por iniciativa própria. `search_memory`, `create_issue`, `run_query`. O modelo lê a sua descrição da ferramenta e decide quando se aplica. É aqui que está a potência, e é aqui que está o risco.
- Resources (recursos) — dados que o *host* lê e coloca no contexto. Um ficheiro, um registo, um documento. Não é o modelo que despoleta, é a aplicação. Menos autonomia, mais previsibilidade.
- Prompts — modelos reutilizáveis que o utilizador escolhe deliberadamente. O mais próximo de um comando slash.
Uma consequência que se descobre tarde: a descrição de uma ferramenta não é documentação, são instruções ao modelo. Se uma ferramenta nunca é invocada quando devia ser, a correção não costuma estar no código — está em que a descrição não soube dizer ao modelo a que situação pertence. Reescrevemos as nossas exatamente por esta razão e a taxa de invocação mudou de imediato.
Local ou remoto: a escolha que conta
Existem dois transportes, e a escolha entre eles decide a maior parte daquilo que a sua instalação vai parecer.
stdio corre o servidor como um processo filho na sua própria máquina. O host lança um comando, fala com ele pela entrada e saída padrão, e mata-o ao sair. Nada sai do dispositivo. É a resposta certa para tudo o que toque em ficheiros locais, e é por isso que os servidores de filesystem e de git funcionam como funcionam. O custo: só existe nessa máquina. O seu portátil e o seu telemóvel não o partilham, e o servidor só está vivo enquanto a aplicação estiver.
HTTP corre o servidor algures acessível. O host liga-se pela rede, autenticando-se normalmente com OAuth 2.0. A partir daí todos os dispositivos veem o mesmo servidor, e um serviço alojado pode ser um deles. O custo: está a confiar em quem o opera, e devia saber onde corre — que é o assunto de outro artigo aqui.
Para a memória em particular, a decisão não é renhida. Uma memória que só existe num portátil é um caderno. Todo o interesse da coisa é que o assistente que abre noutro dispositivo já saiba.
O que um servidor lhe pode fazer
Um servidor MCP é código a que concedeu o direito de agir. Trate-o em conformidade.
Um servidor local corre com as permissões do seu utilizador — pode ler tudo o que você pode ler. Um servidor remoto recebe tudo o que o modelo lhe envia, o que com o tempo é muita coisa sobre si. E a descrição de uma ferramenta é texto dirigido ao modelo, pelo que um servidor pode moldar o comportamento do assistente, e não apenas responder-lhe.
Quatro perguntas que vale a pena fazer antes de instalar um:
- Posso ler o código-fonte, ou isto é um binário de um desconhecido?
- Que permissões detém — uma única pasta, ou toda a minha pasta pessoal?
- Se for remoto: quem o opera, em que país, e posso apagar os meus dados?
- Escreve, ou apenas lê? Um servidor de leitura apenas tem um raio de impacto muito menor.
O ecossistema é jovem e maioritariamente construído por indivíduos de boa-fé. Isso não é o mesmo que auditado. O registo oficial e as listas comunitárias são ferramentas de descoberta, não garantias.
Quando deve escrever um
A fasquia é baixa — um servidor que expõe duas ferramentas cabe num ficheiro curto em Python ou TypeScript, e os SDK tratam do protocolo. A verdadeira questão é se uma ferramenta é a forma certa para aquilo que quer.
Normalmente é, quando o assistente precisa de *agir* sobre um sistema vivo, ou de ir buscar algo que muda. Normalmente não é, quando só precisa que o modelo conheça um corpo de texto fixo — colá-lo, ou expô-lo como recurso, é mais simples e mais fiável do que ensinar o modelo a ir pedi-lo.
Se quiser os detalhes, a especificação é curta e legível, o que é raro e diz algo de bom sobre o projeto.
O Pryzm é um servidor MCP remoto cujo único ofício é a memória: guarda o que lhe diz e recupera as partes pertinentes mais tarde, em qualquer cliente que fale o protocolo. Se preferir alojar o seu próprio, existem vários servidores de memória gratuitos e auto-alojáveis, e listamo-los na nossa comparação.