MCP na prática: conectando agentes de IA a sistemas e dados

Um modelo de linguagem isolado sabe conversar, resumir e gerar código, mas não conhece o status do pedido que acabou de entrar, não vê os alertas da sua aplicação e não consegue consultar uma agenda sem integração.

Cada produto começou resolvendo isso de um jeito: funções próprias, plugins, wrappers de API e formatos diferentes para descrever ferramentas. O Model Context Protocol, conhecido como MCP, surgiu para padronizar essa ponte entre aplicações de IA e sistemas externos.

O interesse do mercado não está apenas em mais um protocolo. Está na possibilidade de implementar uma integração uma vez e torná-la utilizável por diferentes clientes compatíveis, mantendo contratos e limites mais claros.

Uma forma simples de entender MCP

Pense em uma aplicação de IA que precisa consultar issues no GitHub, buscar documentação interna e ler incidentes no Sentry. Sem um padrão, cada conexão teria configuração, formato e ciclo de vida próprios.

No MCP existem três papéis principais:

• Host: a aplicação onde o usuário interage com a IA
• Client: a conexão mantida pelo host com cada servidor
• Server: o componente que expõe dados e capacidades de um sistema

O host coordena a experiência, controla permissões e conecta um client para cada server. O servidor continua focado em um domínio: GitHub, banco de dados, arquivos, observabilidade ou uma API interna.

O protocolo usa JSON-RPC e negocia capacidades no início da conexão. Para quem implementa produto, o mais importante não é decorar mensagens internas, mas entender os três tipos de capacidade que um servidor pode apresentar.

Tools, resources e prompts

Tools são ações que o modelo pode solicitar. Criar uma issue, consultar o clima, executar uma busca ou atualizar um registro são exemplos. Como uma tool pode alterar estado, sua descrição e seu schema precisam ser objetivos.

Resources oferecem contexto que pode ser lido, como um arquivo, um documento ou o resultado de uma consulta. Eles ajudam o host a descobrir e selecionar informação sem transformar toda leitura em ação.

Prompts são templates reutilizáveis publicados pelo servidor para orientar interações frequentes. Podem estruturar, por exemplo, uma revisão de incidente ou a preparação de um relatório.

Essa separação importa. Nem tudo precisa virar ferramenta. Se o agente só precisa ler uma política, um resource representa melhor a intenção. Se precisa alterar algo, a operação deve aparecer claramente como tool.

MCP não substitui sua API

Uma API continua sendo o contrato do sistema. Ela atende interface web, aplicativo, integrações e automações previsíveis. O MCP cria uma camada adequada para aplicações de IA descobrirem capacidades e oferecerem argumentos estruturados para usá-las.

Na prática, um servidor MCP saudável costuma chamar services ou APIs que já existem. Ele traduz primitivas do protocolo para operações do domínio sem duplicar regra de negócio.

Se a validação de cancelamento de pedido existe apenas dentro da tool cancel_order, o desenho está invertido. A regra deveria continuar no backend; o servidor MCP é mais um consumidor autorizado.

Um contrato de ferramenta precisa ser estreito

Imagine uma tool genérica chamada execute_sql recebendo qualquer texto. Ela é flexível, mas entrega ao modelo um poder grande demais e dificulta auditoria.

Uma alternativa melhor seria oferecer operações específicas:

{
  "name": "find_overdue_invoices",
  "description": "Lista faturas vencidas de um cliente, sem alterar dados",
  "inputSchema": {
    "type": "object",
    "properties": {
      "customerId": { "type": "string" },
      "limit": { "type": "integer", "maximum": 50 }
    },
    "required": ["customerId"]
  }
}

O nome comunica intenção, o schema limita entrada e a descrição deixa claro que a operação é somente leitura. Esse contrato facilita escolha pelo modelo, validação no servidor e revisão por uma pessoa.

O padrão ganhou peso de ecossistema

Em dezembro de 2025, a Anthropic doou o MCP para a Agentic AI Foundation, ligada à Linux Foundation. O movimento colocou a especificação sob uma estrutura neutra e acompanhada por empresas como Block, OpenAI, Google, Microsoft, AWS e Cloudflare.

Esse tipo de governança importa porque integração vira infraestrutura. Um protocolo controlado de forma aberta tem mais chance de sobreviver à troca de fornecedor, receber SDKs consistentes e construir interoperabilidade real.

Ainda assim, adoção ampla não torna qualquer servidor seguro ou bem implementado. O cliente continua precisando avaliar o código, a origem e as permissões de cada integração.

Segurança precisa aparecer no desenho

Conectar um agente ao sistema significa permitir que texto produzido por um modelo influencie chamadas reais. Isso muda o risco.

Eu trataria alguns pontos como obrigatórios:

1. Aplicar menor privilégio para cada servidor e usuário.
2. Separar claramente leitura de escrita.
3. Pedir confirmação para ações destrutivas ou externas.
4. Validar todo argumento no backend, mesmo que o schema já limite o formato.
5. Registrar usuário, tool, parâmetros seguros e resultado da operação.
6. Nunca expor tokens, segredos ou respostas completas sem necessidade.
7. Considerar qualquer resource externo como entrada não confiável.

Prompt injection merece atenção especial. Um documento lido como contexto pode conter instruções tentando convencer o agente a ignorar regras ou chamar outra ferramenta. Conteúdo não vira confiável só porque está em um PDF corporativo ou em uma issue conhecida.

Para servidores remotos com dados protegidos, a documentação de autorização do MCP usa fluxos baseados em OAuth e recomenda tokens curtos, validação de audiência e scopes com menor privilégio. Autenticação identifica acesso; autorização ainda precisa decidir o que aquela identidade pode fazer.

Observabilidade também vale para agentes

Uma chamada feita por IA não deveria desaparecer dentro de um log genérico. Registre sinais que permitam reconstruir a decisão operacional:

• Quem iniciou a sessão
• Qual cliente e servidor participaram
• Qual tool foi solicitada
• Quanto tempo a execução levou
• Se houve confirmação humana
• Qual regra de autorização foi aplicada
• Se o resultado foi sucesso, recusa ou falha

Não é necessário armazenar toda conversa. Muitas vezes isso criaria um problema de privacidade maior. Metadados estruturados e correlation IDs já ajudam a investigar bastante.

Quando vale criar um servidor MCP

MCP faz sentido quando uma capacidade precisa aparecer em mais de uma aplicação de IA, quando existe benefício de descoberta padronizada ou quando você quer separar a integração do ciclo de vida do host.

Talvez não valha quando a aplicação tem uma única função interna estável, nenhum plano de interoperabilidade e uma chamada direta já resolve com menos componentes. Padrão não elimina custo operacional.

Eu começaria por um caso somente leitura: consultar documentação, buscar incidentes ou listar dados operacionais sem informação sensível. Depois mediria utilidade, latência, taxa de erro e escolhas incorretas do agente antes de liberar escrita.

Um caminho pragmático

Para introduzir MCP em um produto, seguiria esta ordem:

1. Escolher um domínio pequeno e um usuário real.
2. Reaproveitar regras da API ou service existente.
3. Modelar tools estreitas, com nomes e schemas claros.
4. Configurar autenticação, autorização e auditoria.
5. Testar entradas inválidas e tentativas de prompt injection.
6. Exigir confirmação em qualquer operação com impacto.
7. Só ampliar o catálogo depois de observar uso real.

Um servidor com cinco ferramentas previsíveis costuma ser mais útil do que um servidor com cinquenta operações ambíguas.

Conclusão

MCP organiza uma parte que estava fragmentada no mercado: como aplicações de IA descobrem e usam contexto, ferramentas e templates fornecidos por outros sistemas.

Seu valor está na interoperabilidade, não em substituir APIs nem em entregar acesso irrestrito ao modelo. O servidor MCP deve permanecer uma borda fina sobre regras confiáveis, com contrato específico, menor privilégio, consentimento e observabilidade.

Quando esse desenho é respeitado, agentes deixam de ser chats isolados e passam a colaborar com software real de maneira mais reaproveitável e controlada.