Vinte anos construindo integrações entre sistemas. Dois módulos de um mesmo ERP que não conversavam entre si. Um banco de dados legado que precisava alimentar um CRM de outro fabricante. Uma fila de mensageria ligando três aplicações diferentes que ninguém mais sabia ao certo como tinham chegado ali.
Cada integração era do zero. Cada uma tinha seu próprio formato, seus próprios contratos implícitos, sua própria lógica que existia só na cabeça de quem tinha escrito. Quando essa pessoa saía da empresa, ficava um conjunto de arquivos que ninguém tocava com medo de quebrar algo que estava funcionando por razões desconhecidas.
Quando li a especificação do MCP pela primeira vez, levei um tempo pra entender o que estava na minha frente. Não porque é difícil. Porque é simples demais. E solução simples pra problema antigo causa um tipo específico de incredulidade em quem viveu o problema por tempo suficiente.
O que é MCP, sem introdução
Model Context Protocol é um protocolo aberto que a Anthropic publicou no final de 2024. Ele define uma forma padrão de um agente de IA se conectar a ferramentas e sistemas externos. Banco de dados, APIs, sistemas de arquivo, calendários, repositórios de código, o que for.
Antes do MCP, se você queria dar ao seu agente acesso a um banco de dados, escrevia essa integração do zero. Formato proprietário, específico da sua implementação. Se queria adicionar acesso ao Slack e ao Google Drive também, mais duas integrações do zero, cada uma com sua própria arquitetura de como expor dados e ações pro modelo. Se amanhã o mesmo agente precisasse conectar a um CRM diferente, mais uma integração do zero.
A lógica era: cada agente, cada ferramenta, uma integração nova.
O MCP muda essa equação. Com um servidor MCP para o Google Drive, qualquer agente que implemente o protocolo passa a ter acesso ao Google Drive. Você constrói uma vez. Não pra um agente específico. Pra qualquer agente compatível.
Pense em HTTP. Antes de HTTP, transferir um documento de um computador para outro exigia negociar o protocolo com quem estava do outro lado. HTTP padronizou isso. MCP está fazendo o mesmo para a camada de ferramentas dos agentes.
Pode parecer exagero. Depois de um tempo usando na prática, não parece mais.
Como o protocolo funciona
O MCP define três tipos de coisa que um servidor pode expor pra um agente.
Recursos são dados que o agente pode ler. Um documento, um registro de banco de dados, o conteúdo de um arquivo, o histórico de pedidos de um cliente. O agente acessa, lê, usa a informação pra raciocinar.
Ferramentas são ações que o agente pode executar. Inserir um registro, enviar um e-mail, criar um evento no calendário, atualizar o status de um lead no CRM. Aqui tem consequência real no sistema.
Prompts são templates de instrução que o servidor sugere pro agente em situações específicas. Menos usados, mas úteis quando você quer padronizar como o agente aborda certos tipos de tarefa.
Essa separação entre leitura e ação é subestimada em quase toda discussão de MCP que vejo. Todo mundo fala sobre o que o protocolo permite. Pouca gente menciona que ele te obriga a pensar explicitamente no que o agente pode só ver e no que ele pode fazer de verdade. Em sistemas que construo, esse exercício sozinho já mudou algumas decisões de arquitetura.
Na prática, o que muda
Montei um servidor MCP pra um sistema de CRM interno há alguns meses. Ele expõe os dados de clientes como recursos e as ações de atualização de status e criação de atividades como ferramentas.
Esse mesmo servidor alimenta dois agentes diferentes. Um que responde perguntas do time de vendas no chat interno. Outro que roda em background, analisa o histórico de interações e sinaliza leads que estão esfriando antes que o vendedor perceba. Mesma fonte de dados. Mesma interface. Duas aplicações completamente diferentes.
Antes eu teria escrito duas integrações separadas com o CRM. Com MCP, escrevi uma. E se surgir um terceiro agente com necessidade diferente, o servidor já existe.
Aliás, isso me lembra um ponto que parece óbvio mas não é quando você está no meio do projeto. O MCP não é só sobre reutilização de código. É sobre reutilização de confiança. Quando você tem um servidor MCP auditado, com controles de permissão definidos, logs de cada ação executada, esse trabalho de segurança serve pra todos os agentes que conectam nele. Você não recomeça esse trabalho a cada nova aplicação.
O que não resolve e o que precisa de atenção
Tem uma discussão legítima sobre segurança que não deve ser ignorada.
MCP expõe capacidades do sistema pra agentes que são, no fundo, modelos de linguagem tomando decisões. O protocolo tem mecanismos: aprovação humana antes de executar certas ferramentas, controle granular de permissões, logs de tudo que foi feito. Não é infalível. Nenhuma arquitetura é.
O erro que já vi acontecer: implementar MCP sem pensar nas permissões. Dar ao agente acesso irrestrito a um servidor que inclui ferramentas destrutivas porque era mais rápido de configurar assim. Isso não é um problema do protocolo. É o mesmo erro que acontece com APIs REST com escopo aberto demais. A ferramenta não é o problema.
O cuidado que vale mesmo: começar conservador nas permissões e expandir conforme você entende como o agente usa cada ferramenta. É mais trabalho no início. É muito menos problema depois.
O ecossistema que está crescendo
O que mais importa no MCP não é técnico.
É o fato de ser um protocolo aberto com adoção crescendo rápido. Já tem servidor MCP para GitHub, Jira, Figma, PostgreSQL, SQLite, sistemas de arquivo, dezenas de APIs. Quando você constrói um servidor MCP, seu trabalho fica disponível pra qualquer agente que implemente o protocolo. Não fica preso na plataforma de ninguém.
Isso cria um incentivo que integração proprietária nunca criou. Faz sentido investir bem no servidor porque o retorno vai além do seu próprio uso.
Já assisti protocolos abertos transformarem indústrias inteiras. RSS simplificou distribuição de conteúdo. OAuth padronizou autorização. HTTP criou a web. Não estou comparando escala ainda. Mas o padrão de “protocolo simples, adoção rápida, ecossistema que cresce sozinho” é familiar.
A pergunta que mudou
Se você está construindo agentes ou avaliando como IA pode entrar nos sistemas da sua empresa, a pergunta certa deixou de ser “como faço esse agente conversar com meu sistema”.
A pergunta agora é: já existe um servidor MCP pra esse sistema, ou preciso construir um?
Na maioria dos casos comuns, já existe. E quando não existe, construir um servidor MCP é trabalho que você faz uma vez e que serve pra todos os agentes que virem depois. É diferente de tudo que você escreveu antes como integração. Vale pensar nisso antes de começar.
Desenvolvo sistemas com agentes de IA e implementações de MCP para empresas que precisam conectar IA aos sistemas que já existem no negócio delas. Se quiser conversar sobre o que faz sentido pro seu caso, entra em contato pelo gabriels.dev.br.