Preciso de um IP dedicado para hospedar um servidor MCP?

Para um endpoint HTTPS público, sim. Planos NAT encaminham uma única porta SSH e não expõem a porta 443 à internet. Um plano com IP dedicado te dá todas as portas e um domínio que você pode apontar direto para a máquina.

stdio ou HTTP — qual transporte eu hospedo?

HTTP (SSE ou o mais novo streamable-HTTP). Um servidor stdio só conversa com um cliente na mesma máquina; qualquer coisa que você queira alcançável pela rede tem que falar HTTP por trás de uma URL.

Um VPS pode rodar vários servidores MCP?

Sim. Vincule cada servidor a uma porta local diferente e dê a cada um o próprio subdomínio no reverse proxy. A RAM é o limite prático, e servidores de ferramentas usam muito pouca dela.

Quanta RAM um servidor MCP precisa?

Geralmente pouca. Um servidor de ferramentas é limitado por I/O — ele espera por APIs e bancos de dados em vez de triturar números, então 1–2 GB dão conta da maioria. Rodar um modelo para gerar as respostas é um trabalho separado, muito mais pesado.

Hospede o seu próprio servidor MCP num VPS

Você escreveu um servidor MCP. Localmente ele funciona bem — seu agente o chama, as ferramentas disparam, tudo conectado. Depois você fecha o notebook e ele some. Se você quer esse servidor alcançável sempre que seu agente precisar — de outra máquina, do setup de um colega, de um job agendado às 3 da manhã — ele tem que morar em algum lugar sempre ligado, com um endereço estável e HTTPS. É para isso que serve um VPS.

Eis como tirar seu servidor MCP do notebook e colocá-lo numa máquina que você de fato controla, com notas honestas sobre onde o esforço vai.

Local vs remoto: o que "hospedar" de fato significa

Servidores MCP vêm em duas formas.

Um servidor stdio roda como um processo local e conversa com um cliente na mesma máquina por entrada/saída padrão. É perfeito enquanto você está construindo — mas não pode ser alcançado por nada através da rede.

Um servidor remoto fala HTTP (Server-Sent Events, ou o mais novo transporte streamable-HTTP) por uma URL. Qualquer cliente que conhece a URL e tem as credenciais certas pode chamá-lo. Hospedar o seu próprio servidor MCP significa rodar o tipo remoto em algum lugar público e estável.

Por que não só tunelar o seu notebook

Você tecnicamente pode expor uma máquina de casa com um túnel, e para uma demo rápida isso está bem. Para qualquer coisa em que você confia, você herda os problemas da máquina: ela dorme, seu provedor rotaciona o seu IP, seu upload é lento, e agora um serviço cheio de ferramentas reais está na sua rede doméstica ao lado de tudo o mais. Um VPS te dá um IP público fixo, um domínio real, uptime adequado e isolamento. Por alguns dólares por mês ele apaga uma categoria inteira de perguntas do tipo "por que meu agente perdeu a conexão".

A stack, concretamente

Escolha uma máquina pequena. Um servidor de ferramentas MCP é na maior parte I/O — ele espera por APIs, arquivos e bancos de dados; não faz matemática pesada. 1–2 GB de RAM são bastante para a maioria. (Rodar um modelo inline para responder é outra história — veja auto-hospedar um LLM com o Ollama.)

Rode seu servidor vinculado ao localhost, digamos Node ou Python escutando em 127.0.0.1:3100. Mantenha-o fora da interface pública diretamente — o proxy cuida disso.

Coloque um reverse proxy na frente para terminar o TLS no seu domínio. O Caddy faz isso em cerca de quatro linhas e busca um certificado gratuito automaticamente:

mcp.seudominio.com {
    reverse_proxy 127.0.0.1:3100
}

Aponte mcp.seudominio.com para o IP do seu VPS, recarregue o Caddy, e seu servidor fica no ar em https://mcp.seudominio.com por streamable-HTTP.

Mantenha-o sempre ligado

Um servidor que morre na primeira queda ou reboot não está "hospedado" — está "rodando por ora". Envolva-o numa unit systemd para que ele reinicie em quedas e volte após um reboot:

[Unit]
Description=My MCP server
After=network.target

[Service]
ExecStart=/usr/bin/node /opt/mcp/server.js
Restart=always
RestartSec=2

[Install]
WantedBy=multi-user.target

systemctl enable --now my-mcp e ele está genuinamente sempre ligado. (O mesmo padrão mantém qualquer agente ou bot vivo 24/7.)

A parte que as pessoas perdem: você precisa de uma porta alcançável

Um endpoint MCP público precisa de uma porta de entrada — a 443 — alcançável da internet. Num plano NAT você ganha exatamente uma porta encaminhada para SSH e nada mais; você não pode abrir a 443 para o mundo. Para hospedar um servidor MCP HTTPS público você quer um plano com IP dedicado, onde toda porta é sua e você pode apontar um domínio direto para a máquina. Essa é a diferença entre "meu agente no mesmo notebook consegue alcançá-lo" e "qualquer cliente em qualquer lugar consegue".

Tranque — é uma API com privilégios

Um servidor MCP geralmente expõe ferramentas que fazem coisas: leem arquivos, batem em APIs pagas, movem dinheiro. Não coloque isso na internet aberta pelado.

Exija um token em toda chamada. Rejeite requisições anônimas; cheque um token bearer ou chave de API antes de qualquer ferramenta rodar.
Firewall em tudo exceto a 443 e sua porta SSH.
SSH só por chaves, sem login por senha. (Eis o checklist de dez minutos.)

Trate o endpoint pelo que ele é — uma API com autoridade real — e a maior parte do risco desaparece.

Os limites honestos

Agora a operação é sua. Atualizações do SO, manter o processo saudável, observar logs. O Caddy renova o certificado por você, mas o resto é seu. Uma função de nuvem gerenciada esconde isso; um VPS a entrega a você em troca de controle e uma conta muito mais baixa.
A spec do MCP ainda está se mexendo. Transportes e padrões de autenticação mudam de release para release. Fixe a versão do seu SDK e espere atualizá-la de vez em quando.
Uma máquina de CPU é certa para servidores de ferramentas, não para gerar respostas com um modelo local. Se o seu servidor roda um LLM para responder, essa é uma máquina separada e mais pesada — veja o guia do Ollama.
Nunca exponha ferramentas destrutivas sem autenticação e um passo de confirmação. Uma ferramenta aberta que apaga coisas eventualmente vai encontrar um bot que escaneia tudo.

Pagando por ele

Cadastre-se com um e-mail e pague em USDC ou USDT — sem cartão, sem documento. E se você está conectando isto para um agente, o mesmo tipo de máquina pode ser pedido e pago programaticamente pelo nosso próprio servidor MCP — o agente se cadastra, abastece um saldo e pede sozinho.

Hospede o servidor uma vez, e suas ferramentas estarão lá sempre que o agente as buscar.

Setup pronto: veja VPS para servidores MCP — o plano recomendado e um deploy em cripto de um minuto.