Model Context Protocol (MCP): Como Criar e Hospedar Servidores MCP em VPS Docker com PostgreSQL

1. A Padronização de Agentes de IA: Por Que o MCP Importa em 2027

Até recentemente, conectar um agente de inteligência artificial a um banco de dados de produção ou a uma API interna exigia a construção manual de esquemas no formato Function Calling do provedor escolhido (OpenAI, Anthropic Claude, Google Vertex AI). Sempre que a equipe decidia trocar o modelo de fundação ou orquestrar agentes entre diferentes provedores, todos os esquemas JSON, funções de parsing e tratamentos de erro precisavam ser reescritos do zero.

O Model Context Protocol (MCP) resolveu essa fragmentação da mesma forma que o Language Server Protocol (LSP) padronizou o suporte a linguagens de programação nas IDEs modernas. Ao desacoplar o cliente de IA da implementação concreta das ferramentas, o MCP viabiliza uma arquitetura modular na qual um único servidor de ferramentas pode servir simultaneamente a interfaces como Claude Desktop, Cursor, ambientes de desenvolvimento autônomo e pipelines orquestrados em uma VPS para n8n.

Quando você gerencia dados sensíveis — como registros financeiros, informações de clientes e catálogos operacionais —, expor seu banco de dados diretamente para a internet pública é uma violação grave de segurança. A hospedagem de um servidor MCP privado em uma VPS sem fidelidade no Brasil permite que a conexão com o banco relacional PostgreSQL 16 ocorra dentro de uma rede virtual isolada (Docker bridge privada ou localhost), enquanto apenas o endpoint autenticado do servidor MCP é exposto via HTTPS seguro com certificado SSL automático.

2. Anatomia do Protocolo: Host, Client e Server

Para entender como projetar servidores robustos, é fundamental dissecar os três pilares que compõem o ecossistema do Model Context Protocol:

• MCP Host: A aplicação de nível superior com a qual o usuário ou o fluxo interage (por exemplo, Cursor, Claude Desktop, uma interface web interna ou um nó de execução de IA em n8n). O Host é quem toma a decisão de iniciar ou conectar-se aos clientes MCP.
• MCP Client: A camada de biblioteca que mantém o canal de comunicação aberto com o servidor, negociando capacidades no handshake inicial (método initialize), listando ferramentas disponíveis e despachando as mensagens JSON-RPC.
• MCP Server: O processo especializado que expõe capacidades concretas ao cliente. Essas capacidades dividem-se em três primitivas fundamentais:
  • Resources (Recursos): Dados estáticos ou dinâmicos somente-leitura (como esquemas de tabelas, logs do sistema ou relatórios cadastrais).
  • Tools (Ferramentas): Funções executáveis que podem realizar efeitos colaterais e receber parâmetros validados (como consultar vendas do mês, criar faturas ou disparar eventos).
  • Prompts: Modelos estruturados e parametrizados de comandos que auxiliam o modelo a executar tarefas recorrentes com precisão determinística.

[MCP Host: Cursor / n8n / Agente]
             │
             ▼
[MCP Client: JSON-RPC over HTTPS/SSE]
             │ (Rede Externa com Token Bearer)
             ▼
[Reverse Proxy: Caddy / Nginx com SSL] (Porta 443)
             │
             ▼ (Rede Docker Interna: 172.20.0.0/16)
[Servidor MCP FastMCP (Python)] ──(asyncpg pool)──► [PostgreSQL 16 NVMe]
                                                    [Redis 7 (Rate Limit)]
  

3. Transportes: Por Que STDIO Falha na Nuvem e SSE é Obrigatório

O protocolo MCP suporta oficialmente duas modalidades de transporte de mensagens:

1. STDIO (Standard Input / Output): O Host inicia o servidor MCP como um subprocesso filho local na mesma máquina operacional e troca dados via canais padrão de entrada e saída. Esse modo é excelente para testes em notebooks locais, mas completamente inviável quando o servidor de banco de dados reside em uma infraestrutura remota de alta performance e múltiplos membros da equipe precisam acessar as mesmas ferramentas.
2. SSE (Server-Sent Events) sobre HTTP: O servidor MCP atua como um microserviço HTTP. O cliente abre uma conexão HTTP persistente de longa duração (SSE) para receber eventos e streaming do servidor, enquanto requisições de execução de ferramentas são enviadas via requisições HTTP POST tradicionais. Em 2027, o transporte SSE tornou-se o padrão corporativo por atravessar firewalls sem atrito e permitir balanceamento de carga nativo.

4. Implementação Completa: Servidor MCP em Python com FastMCP e PostgreSQL 16

A biblioteca FastMCP (integrada ao SDK oficial do MCP em Python) oferece uma experiência declarativa inspirada no FastAPI, com tipagem estrita via Pydantic e documentação automática de parâmetros que os modelos de linguagem utilizam para entender exatamente quando e como acionar cada ferramenta.

Abaixo apresentamos o código completo de um servidor MCP pronto para produção, integrando pool de conexões assíncronas asyncpg ao PostgreSQL 16, com proteção estrita contra SQL Injection e validação de permissões:

# server.py - Servidor MCP de Produção com FastMCP e PostgreSQL 16
import os
import asyncio
from typing import List, Dict, Any, Optional
import asyncpg
from mcp.server.fastmcp import FastMCP
from pydantic import BaseModel, Field

# Inicialização do servidor com metadados para o modelo
mcp = FastMCP(
    name="Enterprise-Database-MCP",
    dependencies=["asyncpg", "pydantic"],
)

DATABASE_URL = os.getenv(
    "DATABASE_URL", 
    "postgresql://app_user:StrongPassword2027@postgres:5432/enterprise_db"
)
AUTH_TOKEN = os.getenv("MCP_AUTH_TOKEN", "yousecure_mcp_secret_token_2027")

db_pool: Optional[asyncpg.Pool] = None

async def get_db_pool() -> asyncpg.Pool:
    global db_pool
    if db_pool is None:
        db_pool = await asyncpg.create_pool(
            dsn=DATABASE_URL,
            min_size=2,
            max_size=10,
            command_timeout=30,
        )
    return db_pool

# 1. RECURSO: Esquema estruturado das tabelas (somente leitura)
@mcp.resource("schema://database/tables")
async def get_schema_definition() -> str:
    # Retorna o esquema DDL simplificado das tabelas publicas para orientar o agente
    pool = await get_db_pool()
    query = '''
        SELECT table_name, column_name, data_type, is_nullable
        FROM information_schema.columns
        WHERE table_schema = 'public'
        ORDER BY table_name, ordinal_position;
    '''
    async with pool.acquire() as conn:
        records = await conn.fetch(query)
    
    schema_map: Dict[str, List[str]] = {}
    for r in records:
        t = r["table_name"]
        schema_map.setdefault(t, []).append(f"{r['column_name']} ({r['data_type']})")
    
    output = ["### Esquema de Tabelas Disponíveis no PostgreSQL 16:"]
    for table, cols in schema_map.items():
        output.append(f"- **{table}**: {', '.join(cols)}")
    return "\n".join(output)

# 2. FERRAMENTA: Consulta parametrizada segura com limites estritos
class QueryCustomersInput(BaseModel):
    state: str = Field(..., min_length=2, max_length=2, description="UF brasileira com 2 letras, ex: SP, RJ")
    limit: int = Field(default=10, ge=1, le=50, description="Quantidade máxima de registros retornados")

@mcp.tool()
async def list_customers_by_state(input_data: QueryCustomersInput) -> List[Dict[str, Any]]:
    # Consulta clientes cadastrados filtrados por estado (UF) no PostgreSQL com paginacao segura
    pool = await get_db_pool()
    query = '''
        SELECT id, name, email, city, state, created_at
        FROM customers
        WHERE state = $1
        ORDER BY created_at DESC
        LIMIT $2;
    '''
    async with pool.acquire() as conn:
        rows = await conn.fetch(query, input_data.state.upper(), input_data.limit)
    return [dict(row) for row in rows]

# 3. PROMPT ESTRUTURADO: Guia de análise para relatórios gerenciais
@mcp.prompt()
def customer_churn_audit_prompt(state: str) -> str:
    # Gera um roteiro de raciocinio padronizado para auditoria de clientes por estado
    return f'''Voce e um engenheiro de dados senior. 
1. Use a ferramenta list_customers_by_state para inspecionar clientes no estado {state}.
2. Identifique os clientes mais antigos e correlacione com a tabela de faturas.
3. Resuma as oportunidades de retencao em formato de topicos estruturados.'''

if __name__ == "__main__":
    # Executa o servidor no modo SSE em produção
    port = int(os.getenv("PORT", "8000"))
    mcp.run(transport="sse")

5. Empacotando em Produção com Docker Compose e PostgreSQL 16

Para manter a infraestrutura 100% reproduzível e resiliente a falhas de energia ou reboots do sistema operacional, empacotamos o serviço em uma composição com Docker Compose. A topologia inclui o servidor MCP, uma instância de PostgreSQL 16 com volume persistente em disco NVMe de alta velocidade e o proxy reverso Caddy, que emite certificados SSL Let's Encrypt automaticamente:

# docker-compose.yml - Infraestrutura MCP Corporativa na You Secure
version: '3.8'

services:
  caddy:
    image: caddy:2-alpine
    container_name: mcp_caddy_gateway
    restart: always
    ports:
      - "80:80"
      - "443:443"
    volumes:
      - ./Caddyfile:/etc/caddy/Caddyfile:ro
      - caddy_data:/data
      - caddy_config:/config
    networks:
      - mcp_public
    depends_on:
      - mcp_server

  mcp_server:
    build:
      context: .
      dockerfile: Dockerfile
    container_name: mcp_fastmcp_app
    restart: unless-stopped
    environment:
      - PORT=8000
      - DATABASE_URL=postgresql://mcp_user:SecretKVM2027@mcp_postgres:5432/mcp_prod
      - MCP_AUTH_TOKEN=sk-live-yousecure-mcp-99f82a17cb
    networks:
      - mcp_public
      - mcp_internal
    depends_on:
      mcp_postgres:
        condition: service_healthy

  mcp_postgres:
    image: postgres:16-alpine
    container_name: mcp_postgres_db
    restart: always
    environment:
      POSTGRES_USER: mcp_user
      POSTGRES_PASSWORD: SecretKVM2027
      POSTGRES_DB: mcp_prod
    volumes:
      - pgdata_mcp:/var/lib/postgresql/data
    networks:
      - mcp_internal
    healthcheck:
      test: ["CMD-SHELL", "pg_isready -U mcp_user -d mcp_prod"]
      interval: 10s
      timeout: 5s
      retries: 5

networks:
  mcp_public:
    driver: bridge
  mcp_internal:
    internal: true

volumes:
  pgdata_mcp:
  caddy_data:
  caddy_config:

Observe o detalhe crucial da configuração de rede: o PostgreSQL reside exclusivamente na rede mcp_internal configurada com internal: true. Essa diretiva impede que o container do banco acesse ou seja acessado pela internet pública. Todo o tráfego externo passa pelo Caddy, que exige cabeçalho de autenticação Bearer antes de repassar a requisição ao FastMCP.

6. Por Que a Latência de 6,6ms em São Paulo é Crítica para MCP

Quando um agente autônomo executa uma tarefa corporativa — como consolidar vendas diárias, calcular comissões e gerar relatórios financeiros —, ele raramente executa uma única chamada. Na prática, o agente opera em um ReAct Loop (Reasoning + Acting), realizando de 5 a 12 iterações sequenciais de tool-calling:

1. O modelo raciocina e chama a ferramenta list_customers.
2. O resultado retorna; o modelo analisa e chama get_customer_invoices.
3. O resultado retorna; o modelo identifica uma pendência e chama generate_pix_qr_code.
4. O resultado é validado e persistido no banco.

Se o seu servidor MCP ou seu banco PostgreSQL estiverem hospedados na Europa (Frankfurt) ou nos Estados Unidos (Virgínia), cada requisição HTTP/SSE sofrerá um Round Trip Time (RTT) físico de 160ms a 220ms. Em um loop de 10 chamadas de ferramentas, você acumula mais de 2,2 segundos de latência pura de rede, além do tempo de processamento dos tokens do modelo.

Ao hospedar sua infraestrutura em um dos Melhores VPS do Brasil conectado diretamente ao Ponto de Troca de Tráfego de São Paulo (IX.br), o RTT despenca para apenas 6,6ms. As 10 iterações somam menos de 70 milissegundos de latência física, garantindo uma resposta praticamente instantânea para o usuário final e eliminando timeouts na VPS para Evolution API v3.

7. Dimensionamento de Hardware e Requisitos para Produção

Servidores MCP que executam conexões SSE mantêm sockets TCP abertos continuamente, enquanto o runtime do Python e o driver do PostgreSQL consomem pools de memória para buffers de consulta. Ambientes subdimensionados de 1GB ou 2GB de RAM (frequentes em hospedagens compartilhadas ultrapassadas) enfrentam o impiedoso OOM Killer (Out Of Memory) do Linux assim que múltiplos agentes disparam consultas simultâneas.

Para produção corporativa estável em 2027, a especificação técnica recomendada consiste em:

• Processamento: 4 vCPUs dedicadas baseadas em virtualização KVM estrita, impedindo sobrecarga de vizinhos de máquina (noisy neighbors).
• Memória RAM: 4GB de RAM dedicados (garantindo 1,5GB para o sistema operacional e Caddy, 1GB para o buffer pool do PostgreSQL 16 e 1,5GB para os workers ASGI do FastMCP).
• Armazenamento: 100GB em discos NVMe corporativos com mais de 50.000 IOPS, acelerando transações de banco de dados e geração de relatórios volumosos.
• Acesso Operacional: Acesso Root SSH irrestrito para configurar firewalls UFW, scripts de backup automatizados e monitoramento via Prometheus/Grafana.