MCP (Model Context Protocol)

1. Visão Geral do Conceito e Problema Sistêmico

Antes da chegada do protocolo MCP, o ecossistema de ferramentas agênticas sofria com o clássico problema de incompatibilidade $N \times M$:

1. Fragmentação de adaptadores: Se você possui 5 clientes de IA (Cursor, Claude Desktop, Continue, um agente CLI interno, interface web) e 10 fontes de dados (PostgreSQL, GitHub, Slack, Sentry, sistema de arquivos local), os engenheiros eram obrigados a criar e manter 50 conectores de integração distintos.
2. Vazamento de chaves sensíveis: As aplicações cliente exigiam a passagem direta de tokens de API para seu contexto, aumentando a superfície de ataque.
3. Ausência de tipificação unificada de recursos: Não havia um padrão sobre como o modelo deveria receber dados passivos (documentos para leitura) separadamente das ações ativas com efeitos colaterais (mutações no banco de dados).

O Model Context Protocol (MCP) resolve esse problema por analogia ao Language Server Protocol (LSP) no mundo das IDEs: é o "USB-C para Inteligência Artificial", unificando a interação entre clientes de IA e ferramentas backend através de um protocolo aberto JSON-RPC 2.0.

2. Taxonomia Arquitetural e Modelo Mental

O protocolo MCP baseia-se em uma clara divisão cliente-servidor e opera com três primitivas principais:

• 1. Tools (Ferramentas Ativas com Efeitos Colaterais): Funções executáveis que o modelo pode chamar para alterar o estado do mundo externo (executar uma query SQL, iniciar um build, enviar um comentário no GitHub). São descritas através de um esquema rigoroso JSON Schema.
• 2. Resources (Fontes Passivas de Dados para Leitura): Dados endereçados por URI sem efeitos colaterais, transmitidos ao contexto do modelo como documentos (conteúdo de arquivos, logs de servidor, esquema de tabelas, documentação).
• 3. Prompts (Templates de Interação): Prompts pré-parametrizados e cadeias de contexto que o servidor oferece ao cliente (por exemplo, uma instrução pronta para auditoria de vulnerabilidades ou geração de migração).
• 4. Camada de Transporte (Transport Layer):
  • stdio: iniciação do servidor como processo filho na mesma máquina. Não requer portas de rede, possui overhead de latência zero.
  • SSE (Server-Sent Events): operação via HTTP/HTTPS, permitindo conectar microsserviços corporativos remotos e agentes em nuvem.

3. Pipeline Técnico e Mecânica Interna

O ciclo de vida de uma sessão pelo protocolo MCP passa por 4 estágios:

1. Handshake & Capabilities Negotiation (Aperto de Mão): O cliente envia uma requisição initialize, declarando suas capacidades (por exemplo, suporte a notificações ou pastas raiz). O servidor responde com sua lista de capacidades (Tools, Resources, Prompts) e a versão do protocolo.
2. Dynamic Discovery (Descoberta de Serviços): O cliente solicita manifestos via tools/list ou resources/list. As descrições de funções e parâmetros obtidas são automaticamente traduzidas para o formato Function Calling para o LLM alvo.
3. Execution & Context Invocation (Chamada de Ação): Quando o modelo gera uma chamada de função, o cliente a traduz em uma requisição tools/call para o servidor MCP correspondente, com parâmetros JSON validados.
4. Result Streaming & State Notification (Retorno do Resultado): O servidor executa a ação localmente, utilizando suas próprias configurações seguras (sem passar senhas ao cliente), e retorna o resultado em formato de texto, imagens ou recursos embutidos.

4. Cenários Práticos de Engenharia em Produção

01. Acesso Seguro ao Banco de Dados de Produção

Um servidor MCP para PostgreSQL roda dentro de um perímetro VPC fechado. Ele expõe apenas a ferramenta execute_read_only_query para o Cursor ou Claude Code. O agente pode analisar o esquema e otimizar queries lentas sem ter acesso direto à senha do banco e sem permissões para excluir dados.

02. Ferramental Único Local do Desenvolvedor

Um único servidor MCP escrito para interagir com o GitLab corporativo, Jira interna e serviço de métricas Datadog conecta-se simultaneamente ao terminal CLI (Claude Code), editor gráfico (Cursor) e GitHub Actions automatizadas.

03. Automação de Browser com Puppeteer/Playwright

Um servidor MCP controla um browser headless, fornecendo ao cliente as ferramentas navigate_to, click_element, take_screenshot. O agente testa interfaces e valida designs autonomamente, sem necessidade de conectar plugins externos pesados.

5. Armadilhas, Erros Comuns e Segurança

• Poluição da Janela de Contexto (Context Bloat): Conectar 15 servidores MCP com centenas de esquemas JSON detalhados pode consumir mais de 30.000 tokens antes mesmo da primeira palavra do usuário ser inserida. Utilize filtragem dinâmica ou carregamento sob demanda de ferramentas (Dynamic Tool Selection).
• Perigo de Servidores de Terceiros (Arbitrary Code Execution): Um servidor MCP local executa com privilégios completos da sua conta no SO. Rodar servidores não verificados via npx -y sem inspeção do código-fonte pode levar ao roubo de chaves SSH locais.
• Violação do Contrato do Protocolo via Logging: O uso de console.log() ou print() padrão dentro do código do servidor corrompe o canal stdout no transporte stdio. Escreva diagnósticos exclusivamente em stderr.