IA MCP Agentes LLM Automação

MCP (Model Context Protocol): como conectar IA a qualquer ferramenta do seu negócio

Entenda o que é o Model Context Protocol (MCP), como ele funciona na prática, por que está mudando a forma de construir sistemas com IA e como implementar.

N
Neryx Digital Architects
18 de dezembro de 2025
16 min de leitura
280 profissionais leram
Categoria: Arquitetura Público: Times de engenharia e produto Etapa: Aprendizado

Imagine que você quer que um modelo de linguagem como o Claude ou o GPT-4 consulte dados do seu banco de dados interno, atualize um ticket no Jira, leia arquivos de um repositório Git e envie uma mensagem no Slack — tudo em uma única conversa, sem que o usuário precise copiar e colar nada entre sistemas.

Durante anos, fazer isso exigiu engenharia customizada para cada integração. A cada novo sistema que você queria conectar à IA, precisava escrever uma camada de integração específica, lidar com autenticação, formatar os dados para o modelo e torcer para o contexto caber no limite de tokens.

O Model Context Protocol (MCP) é a tentativa de padronizar tudo isso. Criado pela Anthropic e publicado como especificação aberta em novembro de 2024, o MCP define um protocolo padrão para que modelos de IA se comuniquem com ferramentas externas — da mesma forma que o HTTP padronizou a comunicação entre clientes e servidores web.

O problema que o MCP resolve

Antes do MCP, cada integração de IA com ferramentas externas era reinventada do zero. Você queria que o modelo buscasse dados no seu banco? Escrevia uma function call customizada. Queria que ele lesse arquivos? Mais uma integração ad hoc. Queria compartilhar o mesmo conjunto de ferramentas entre Claude, GPT e Gemini? Impossível — cada API de function calling tem seu próprio formato.

O resultado era um ecossistema fragmentado: cada empresa tinha uma "cola" proprietária entre seus LLMs e seus sistemas. Ferramentas úteis não podiam ser compartilhadas. Manutenção era cara.

O MCP muda isso com uma proposta simples: servidores MCP expõem capacidades padronizadas, e clientes MCP (modelos + aplicações) consomem essas capacidades usando o mesmo protocolo.

Arquitetura do MCP

O protocolo tem três componentes principais:

  • Host: a aplicação que o usuário usa diretamente — pode ser o Claude Desktop, uma IDE com IA integrada, um chatbot interno. O host coordena as conexões com servidores MCP.
  • Cliente MCP: componente dentro do host que se conecta a servidores e gerencia o protocolo de comunicação.
  • Servidor MCP: um processo separado (local ou remoto) que expõe capacidades — ferramentas, recursos e prompts — via protocolo padronizado.

A comunicação acontece via JSON-RPC 2.0 sobre stdio (para servidores locais) ou HTTP com SSE (para servidores remotos). O modelo nunca acessa diretamente os sistemas externos — ele pede ao cliente MCP que execute uma ferramenta, o cliente chama o servidor, e o resultado volta formatado para o modelo.

Os três primitivos do MCP

1. Tools (ferramentas)

Funções que o modelo pode chamar para executar ações. Cada tool tem um nome, descrição e schema JSON dos parâmetros. O modelo decide quando e como chamá-las com base no contexto da conversa.

// Exemplo: tool para buscar pedidos no banco
{
  "name": "buscar_pedido",
  "description": "Busca um pedido pelo número e retorna status, itens e histórico",
  "inputSchema": {
    "type": "object",
    "properties": {
      "numero_pedido": { "type": "string", "description": "Número do pedido (ex: PED-12345)" }
    },
    "required": ["numero_pedido"]
  }
}

2. Resources (recursos)

Dados que o servidor expõe para leitura — similar a endpoints GET de uma API REST. Podem ser arquivos, registros de banco, configurações ou qualquer dado estruturado. O modelo pode listar recursos disponíveis e solicitar o conteúdo de qualquer um.

3. Prompts (templates)

Templates de prompt reutilizáveis que o servidor define. Permitem padronizar como o modelo aborda tarefas comuns — "analisar um log de erro", "resumir um pull request", "gerar um relatório de vendas" — com o contexto certo já embutido.

Construindo um servidor MCP na prática

Vamos criar um servidor MCP simples em Node.js que expõe ferramentas para consultar pedidos em um sistema fictício:

// servidor-pedidos/index.ts
import { Server } from "@modelcontextprotocol/sdk/server/index.js";
import { StdioServerTransport } from "@modelcontextprotocol/sdk/server/stdio.js";
import {
  CallToolRequestSchema,
  ListToolsRequestSchema,
} from "@modelcontextprotocol/sdk/types.js";

// Simulação de banco de dados
const pedidos: Record<string, any> = {
  "PED-001": {
    id: "PED-001",
    cliente: "Empresa XPTO Ltda",
    status: "em_transporte",
    itens: [
      { produto: "Servidor Dell PowerEdge", quantidade: 2, valor: 18500 }
    ],
    criado_em: "2026-03-01",
    previsao_entrega: "2026-03-12"
  },
  "PED-002": {
    id: "PED-002",
    cliente: "Startup ABC",
    status: "aguardando_pagamento",
    itens: [
      { produto: "Licença .NET Enterprise", quantidade: 10, valor: 890 }
    ],
    criado_em: "2026-03-07",
    vencimento_pagamento: "2026-03-10"
  }
};

const server = new Server(
  { name: "servidor-pedidos", version: "1.0.0" },
  { capabilities: { tools: {} } }
);

// Define as ferramentas disponíveis
server.setRequestHandler(ListToolsRequestSchema, async () => ({
  tools: [
    {
      name: "buscar_pedido",
      description: "Busca detalhes de um pedido pelo número. Use quando o usuário perguntar sobre um pedido específico.",
      inputSchema: {
        type: "object",
        properties: {
          numero_pedido: {
            type: "string",
            description: "Número do pedido no formato PED-XXXX"
          }
        },
        required: ["numero_pedido"]
      }
    },
    {
      name: "listar_pedidos_cliente",
      description: "Lista todos os pedidos de um cliente específico",
      inputSchema: {
        type: "object",
        properties: {
          nome_cliente: { type: "string", description: "Nome ou parte do nome do cliente" }
        },
        required: ["nome_cliente"]
      }
    },
    {
      name: "pedidos_com_pagamento_pendente",
      description: "Retorna todos os pedidos aguardando pagamento, ordenados por vencimento",
      inputSchema: { type: "object", properties: {} }
    }
  ]
}));

// Executa as ferramentas quando chamadas
server.setRequestHandler(CallToolRequestSchema, async (request) => {
  const { name, arguments: args } = request.params;

  if (name === "buscar_pedido") {
    const pedido = pedidos[args.numero_pedido as string];
    if (!pedido) {
      return {
        content: [{ type: "text", text: `Pedido ${args.numero_pedido} não encontrado.` }]
      };
    }
    return {
      content: [{ type: "text", text: JSON.stringify(pedido, null, 2) }]
    };
  }

  if (name === "listar_pedidos_cliente") {
    const termo = (args.nome_cliente as string).toLowerCase();
    const resultado = Object.values(pedidos).filter(p =>
      p.cliente.toLowerCase().includes(termo)
    );
    return {
      content: [{ type: "text", text: JSON.stringify(resultado, null, 2) }]
    };
  }

  if (name === "pedidos_com_pagamento_pendente") {
    const pendentes = Object.values(pedidos).filter(p =>
      p.status === "aguardando_pagamento"
    );
    return {
      content: [{ type: "text", text: JSON.stringify(pendentes, null, 2) }]
    };
  }

  throw new Error(`Ferramenta desconhecida: ${name}`);
});

// Inicia o servidor via stdio
const transport = new StdioServerTransport();
await server.connect(transport);
console.error("Servidor MCP de pedidos iniciado");

Para usar no Claude Desktop, adicione ao arquivo de configuração:

// ~/Library/Application Support/Claude/claude_desktop_config.json (macOS)
{
  "mcpServers": {
    "pedidos": {
      "command": "node",
      "args": ["/caminho/para/servidor-pedidos/index.js"]
    }
  }
}

Pronto. A partir daí, você pode perguntar ao Claude: "Quais pedidos estão aguardando pagamento?" — e ele chamará automaticamente a ferramenta certa, processará os dados e responderá em linguagem natural.

Servidor MCP em Python com FastMCP

Para quem prefere Python, a biblioteca FastMCP reduz drasticamente o boilerplate:

from fastmcp import FastMCP
import httpx

mcp = FastMCP("integrador-crm")

@mcp.tool()
async def buscar_cliente(email: str) -> dict:
    """Busca dados de um cliente no CRM pelo e-mail."""
    async with httpx.AsyncClient() as client:
        resp = await client.get(
            f"https://api.seucrm.com/customers",
            params={"email": email},
            headers={"Authorization": "Bearer SEU_TOKEN"}
        )
        return resp.json()

@mcp.tool()
async def criar_oportunidade(
    cliente_id: str,
    titulo: str,
    valor_estimado: float,
    estagio: str = "prospeccao"
) -> dict:
    """Cria uma nova oportunidade de venda no CRM."""
    async with httpx.AsyncClient() as client:
        resp = await client.post(
            "https://api.seucrm.com/opportunities",
            json={
                "customer_id": cliente_id,
                "title": titulo,
                "estimated_value": valor_estimado,
                "stage": estagio
            },
            headers={"Authorization": "Bearer SEU_TOKEN"}
        )
        return resp.json()

@mcp.resource("relatorio://pipeline-vendas")
async def pipeline_vendas() -> str:
    """Resumo do pipeline de vendas atual."""
    # Busca dados do CRM e formata o relatório
    return "Pipeline atual: 12 oportunidades, R$ 340.000 em negociação..."

if __name__ == "__main__":
    mcp.run()

Casos de uso reais por área

Atendimento ao cliente

Um servidor MCP conectado ao sistema de tickets, ao histórico de pedidos e ao CRM permite que um agente de IA resolva chamados de suporte sem que o atendente precise abrir três sistemas diferentes. O modelo consulta o histórico, atualiza o ticket e propõe a solução — tudo numa interface conversacional.

Desenvolvimento de software

Servidores MCP podem expor: repositório Git (listar PRs, ler diffs), sistema de issues (criar, comentar, fechar), pipelines de CI/CD (status de builds, logs de erro), banco de dados de produção (queries somente leitura). Um desenvolvedor consegue perguntar "o que mudou no módulo de pagamentos na última semana?" e receber uma análise consolidada.

Financeiro e operações

Conecte o ERP, as planilhas de orçamento e o sistema de aprovações. Um gestor pode perguntar "qual o custo projetado do projeto X até junho?" e o agente consolida dados de múltiplas fontes, sem que o gestor precise saber onde cada dado vive.

RH e recrutamento

Servidor MCP com acesso ao ATS (Applicant Tracking System) permite que recrutadores perguntem "quais candidatos para a vaga de sênior .NET ainda estão em aberto há mais de 10 dias?" e recebam uma lista com resumo de cada candidato.

Servidores MCP open source disponíveis hoje

O ecossistema já tem dezenas de servidores prontos para uso:

  • @modelcontextprotocol/server-filesystem — acesso a arquivos locais
  • @modelcontextprotocol/server-github — repositórios, issues, PRs do GitHub
  • @modelcontextprotocol/server-postgres — queries SQL somente leitura
  • @modelcontextprotocol/server-slack — mensagens, canais, usuários
  • @modelcontextprotocol/server-google-drive — documentos, planilhas, busca
  • mcp-server-jira (community) — tickets, sprints, projetos
  • mcp-server-notion (community) — páginas, databases, busca

Segurança: o que você precisa pensar antes de sair conectando tudo

O MCP dá poder real ao modelo — e com poder vem responsabilidade. Alguns pontos críticos:

  • Princípio do menor privilégio: o servidor MCP deve expor apenas o que o agente precisa. Um servidor de suporte não precisa ter acesso ao banco de dados financeiro.
  • Operações destrutivas precisam de confirmação humana: deletar registros, enviar e-mails em massa, transferir valores — essas ações devem passar por aprovação explícita do usuário, nunca ser executadas automaticamente.
  • Logs de auditoria: registre todas as chamadas de ferramenta com timestamp, usuário, parâmetros e resultado. Se algo der errado, você precisa saber o que o agente fez.
  • Prompt injection: dados externos (registros de banco, e-mails, documentos) podem conter instruções maliciosas que tentam manipular o modelo. Sanitize entradas e use modelos com resistência a injection.

MCP vs. function calling tradicional

Function calling (como o da API da OpenAI) e MCP resolvem problemas parecidos, mas em escalas diferentes. Function calling é uma feature de API — você define funções inline na chamada e o modelo decide quando chamá-las. MCP é uma infraestrutura — servidores independentes que qualquer cliente compatível pode usar.

A diferença prática: uma função definida para o GPT-4 não funciona com Claude sem reescrever. Um servidor MCP funciona com qualquer cliente MCP. Para times que querem construir uma vez e usar em múltiplos modelos e aplicações, o MCP é a escolha de longo prazo.

Conclusão

O MCP ainda é jovem — a especificação tem menos de um ano — mas a adoção está acelerando. A Anthropic, Microsoft (VS Code Copilot), Cursor, Zed e dezenas de outras ferramentas já implementaram suporte. O ritmo sugere que em 12 a 18 meses, servidores MCP vão ser tão comuns quanto endpoints REST.

Se você está construindo sistemas com IA hoje, vale a pena investir algumas horas para entender o protocolo. Construir seu servidor MCP para os sistemas internos da empresa é um dos projetos com melhor custo-benefício de 2026: esforço de uma sprint, impacto de meses de automatização manual.

Precisa desenhar a próxima fase com menos retrabalho?

Fazemos discovery técnico para mapear riscos, arquitetura-alvo e sequência de execução antes de investir pesado.

Solicitar Discovery

Newsletter

Receba artigos como este no seu e-mail

Conteúdo técnico sobre arquitetura de software, .NET, IA e gestão de produto. Sem spam.