MCP: conectar o agente a sistemas e dados

Nesta aula

O agente só é útil de verdade quando enxerga os sistemas do negócio. O MCP é a tomada padrão que faz isso sem gambiarra.

Até aqui os seus agentes enxergam o que você anexa ou a pasta onde estão. Mas o dia a dia do negócio vive em sistemas: agenda, planilha na nuvem, sistema de gestão, e-mail, banco de dados. Conectar um agente a cada um deles era, até pouco tempo, trabalho de programador, feito de um jeito diferente para cada plataforma. O MCP resolve isso com um padrão. Nesta aula eu explico o conceito sem jargão, mostro o que existe pronto e, principalmente, como decidir o que o agente pode ler e escrever em cada sistema. A prática é um mapa, não uma instalação: a decisão vem antes da conexão.

• Ao final, você vai saber explicar o que é MCP, o que é servidor e cliente, e por que o padrão importa.
• Vai entender como escolher conectores prontos com segurança e como dar permissões mínimas.
• Vai sair com um entregável: o mapa de três sistemas do negócio com o que o agente poderia ler e escrever em cada um.

O problema que o MCP resolve

Pense numa imobiliária pequena. Os imóveis estão num sistema de gestão. As visitas, numa agenda compartilhada. Os interessados, numa planilha na nuvem. Os contratos, numa pasta. Um agente útil para essa imobiliária precisaria consultar os quatro. Antes do MCP, cada conexão era um pequeno programa feito sob medida, para uma plataforma de IA específica. Trocou de plataforma? Refaz tudo. Trocou de sistema? Refaz de novo.

O MCP, Model Context Protocol, é um protocolo aberto que define como um agente conversa com uma ferramenta ou uma fonte de dados. Foi criado pela Anthropic e liberado como padrão aberto, e hoje é adotado por várias plataformas e ferramentas. A analogia que eu uso é a tomada elétrica: antes do padrão, cada aparelho tinha o seu plugue; com o padrão, qualquer aparelho entra em qualquer tomada. No MCP, qualquer conector compatível funciona em qualquer agente compatível.

Dois papéis: servidor e cliente

O que o servidor oferece se chama, no protocolo, ferramenta (uma ação que o agente pode executar) e recurso (um dado que o agente pode ler). Volte à anatomia da aula 2: MCP é o jeito padronizado de dar ferramentas ao agente. A ficha do agente não mudou; o que mudou é que agora as ferramentas vêm de fora, prontas.

O que existe pronto e de onde vem

No momento em que escrevo (setembro de 2026), existem servidores MCP prontos para categorias inteiras de sistema: arquivos locais, repositórios de código, bancos de dados, ferramentas de escritório e documentos na nuvem, serviços de mensagem, agendas. Há três origens, e a origem é a primeira coisa que você confere:

1. Oficial do fornecedor do sistema. A empresa que faz o sistema publica o servidor. É a origem preferida: quem conhece o sistema garante o conector e o mantém.
2. De referência, mantido pela comunidade do protocolo. Servidores exemplares para sistemas comuns, publicados abertamente. Boa origem, com a ressalva de conferir se está mantido.
3. De terceiros. Qualquer pessoa pode publicar um servidor. Alguns são excelentes; outros são abandonados; alguns podem ser maliciosos. Só use com revisão de alguém técnico da sua confiança.

A conexão em si varia por plataforma. No Claude Code, servidores são adicionados por um comando de configuração; no aplicativo do Claude para computador, por um arquivo de configuração ou pelo menu de conectores; nas plataformas web, por um catálogo de integrações. A documentação oficial de cada uma mostra o caminho atual. Se você tem alguém técnico na equipe ou um fornecedor de TI, essa é a parte que eu pediria para essa pessoa fazer a primeira vez, com você do lado decidindo permissões.

Permissões: o que o agente lê e o que ele escreve

Esta é a decisão que importa, e ela é sua, não do técnico. Para cada sistema, você responde duas perguntas: o que o agente precisa LER para a tarefa? O que ele precisa ESCREVER? A resposta padrão para escrita, na primeira versão, é "nada". Leitura já resolve a maior parte do valor, com uma fração do risco.

Vou usar uma clínica odontológica com quatro sistemas como exemplo:

Repare no cadastro de pacientes: leitura zero. O agente que informa horários e convênios não precisa saber quem são os pacientes. Isso é permissão mínima na prática: não é "dar o mínimo que dá para dar", é "dar só o que a tarefa exige".

Três regras de permissão

• Conta própria para o agente. Nunca a conta da dona, nunca a de administrador. Um usuário chamado "agente-atendimento", com o perfil mais restrito que o sistema permitir. Assim o registro do sistema mostra o que foi o agente e o que foi uma pessoa.
• Só leitura até provar que acerta. Escrita entra na versão 2, uma ação por vez, e sempre reversível (criar como rascunho, marcar como pendente) antes de irreversível.
• Escopo por dado, não por sistema. "Ler a agenda" é largo; "ler horários livres e ocupados, sem nome de paciente" é escopo. Nem todo sistema permite esse recorte; quando não permite, a pergunta é se o agente deve mesmo acessar aquele sistema.

Quando o MCP vale a pena e quando não vale

Nem tudo pede conector. Se a informação muda pouco (tabela de serviços, políticas), um arquivo no projeto resolve, como na aula 4. Se muda todo dia e o agente precisa do dado atual (agenda, estoque, status de pedido), um conector vale a pena. Se o sistema não tem servidor MCP e ninguém técnico pode construir ou revisar um, a alternativa honesta é uma exportação periódica (uma planilha gerada toda manhã) que o agente lê como arquivo. É menos elegante e funciona.

E uma regra que serve para tudo neste curso: a conexão é a parte técnica; a decisão sobre o que o agente pode ver e fazer é a parte de negócio. Não delegue a segunda para quem faz a primeira. O mapa da prática é o documento que você entrega ao técnico, e ele conecta o que está no mapa, não mais.