MCP (Model Context Protocol): o guia definitivo do protocolo que conecta IA a tudo

• Que problema o MCP resolve de verdade?
• Como funciona a arquitetura do MCP?
• Como escrever um servidor MCP na prática?
• Servidor local ou remoto: qual escolher?
• Quais são os riscos de segurança do MCP?
• Vale a pena adotar MCP em 2026?

MCP é um protocolo aberto que padroniza como aplicações de IA acessam ferramentas e dados externos. Em vez de escrever uma integração para cada par modelo-ferramenta, você expõe um servidor MCP e qualquer cliente compatível passa a enxergar suas capacidades automaticamente.

Que problema o MCP resolve de verdade?

O MCP existe para eliminar o custo N×M de integração. Com N aplicações de IA e M ferramentas, o mundo pré-protocolo exigia até N×M conectores dedicados — cada IDE, cada chat e cada agente reimplementando o acesso ao mesmo Jira, ao mesmo Postgres, ao mesmo Google Drive.

Com um padrão comum, a conta vira N+M: cada ferramenta publica um servidor e cada aplicação implementa um cliente. É exatamente a lógica que o LSP (Language Server Protocol) trouxe para editores de código em 2016 — e a analogia é deliberada: a Anthropic descreve o MCP como "a porta USB-C das aplicações de IA".

O ganho secundário é mais sutil e mais importante: descoberta em tempo de execução. Um servidor MCP se autodescreve. O modelo pergunta "o que você sabe fazer?" e recebe a lista de ferramentas com nomes, descrições e esquemas de parâmetros. Isso permite adicionar uma capacidade nova a um agente de IA sem tocar no código dele.

Exemplo prático: você mantém um sistema interno de pedidos. Sem MCP, integrá-lo ao assistente do time de suporte, à IDE dos desenvolvedores e ao bot do WhatsApp são três projetos. Com MCP, é um servidor consumido pelos três.

Como funciona a arquitetura do MCP?

O MCP é cliente-servidor sobre JSON-RPC 2.0, com três papéis bem definidos:

• Host — a aplicação que o usuário opera (Claude Desktop, uma IDE, um agente próprio). É quem decide a política de permissões.
• Cliente — o componente dentro do host que mantém uma conexão 1:1 com um servidor e traduz as capacidades para o formato do modelo.
• Servidor — o processo que expõe as capacidades: acessa o banco, chama a API, lê o arquivo.

Sobre essa base, o protocolo define três primitivas que o servidor pode oferecer:

A distinção entre tool e resource é a que mais confunde na primeira leitura. A regra: se a chamada muda alguma coisa ou executa lógica, é tool; se apenas entrega conteúdo para ser lido, é resource. Um SELECT pode ser qualquer um dos dois — publique como resource se o conjunto de consultas é fixo, como tool se o modelo precisa montar a query.

Exemplo prático: um servidor MCP de repositório Git expõe listar_commits e criar_branch como tools, o conteúdo de arquivos como resources e um prompt pronto de "escrever mensagem de commit no padrão do projeto".

Como escrever um servidor MCP na prática?

O caminho mais curto é o SDK de TypeScript ou Python. A estrutura mínima tem três partes: declarar o servidor, registrar ferramentas com esquema de entrada e escolher o transporte.

import { McpServer } from '@modelcontextprotocol/sdk/server/mcp.js';
import { StdioServerTransport } from '@modelcontextprotocol/sdk/server/stdio.js';
import { z } from 'zod';

const server = new McpServer({ name: 'pedidos', version: '1.0.0' });

server.tool(
  'buscar_pedido',
  'Busca um pedido pelo número e retorna status, itens e datas.',
  { numero: z.string().describe('Número do pedido, ex: PED-8842') },
  async ({ numero }) => {
    const pedido = await db.pedidos.findOne({ numero });
    if (!pedido) return { content: [{ type: 'text', text: `Pedido ${numero} não encontrado.` }] };
    return { content: [{ type: 'text', text: JSON.stringify(pedido, null, 2) }] };
  }
);

await server.connect(new StdioServerTransport());

Três decisões definem se o servidor será útil ou frustrante:

1. A descrição da ferramenta é o prompt. O modelo escolhe o que chamar lendo aquele texto. "Busca um pedido pelo número" funciona; "Endpoint de consulta" não. Diga o que faz, quando usar e o que retorna.
2. Valide a entrada com esquema. Zod no TypeScript, Pydantic no Python. O modelo vai inventar parâmetros eventualmente — o esquema transforma isso em erro claro em vez de comportamento estranho.
3. Devolva pouco e bem formatado. Retornar 5.000 linhas de JSON consome a janela de contexto e piora a decisão seguinte. Trunque, resuma, pagine.

Exemplo prático: um servidor que devolvia o dump completo de um pedido gastava 8.000 tokens por chamada. Reduzido a um resumo de 12 campos relevantes, caiu para 300 — e a taxa de acerto do agente subiu, porque o modelo parou de se perder no ruído.

Servidor local ou remoto: qual escolher?

A escolha do transporte define o modelo de segurança inteiro:

Servidores locais são simples porque não têm fronteira de confiança — e essa é justamente a armadilha: eles rodam com suas permissões. Um servidor MCP local malicioso tem o mesmo acesso que você. Instale de terceiros com o mesmo critério com que instala uma extensão de navegador ou um pacote npm.

Servidores remotos exigem o trabalho completo de uma API pública: autenticação, escopos por ferramenta, limite de taxa e auditoria. A especificação recomenda OAuth 2.1 para autorização, o que resolve identidade — mas não resolve autorização de granularidade fina, que continua sendo responsabilidade da sua aplicação.

Exemplo prático: um servidor MCP corporativo de banco de dados deve expor consultar_vendas com escopo por região, não executar_sql. A primeira forma limita o dano de uma decisão errada do modelo; a segunda transforma qualquer falha em incidente.

Quais são os riscos de segurança do MCP?

Três vetores merecem atenção explícita, e nenhum é hipotético:

1. Injeção de prompt via conteúdo devolvido. O servidor retorna dados que o modelo lê como contexto. Se esses dados contêm instruções — um comentário de issue escrito por um atacante, por exemplo — o modelo pode obedecê-las. Não existe correção completa; a mitigação é limitar o que as ferramentas conseguem fazer, não confiar em filtros de texto.
2. Excesso de permissão. Servidores prontos costumam pedir acesso amplo porque é mais fácil documentar. Revise os escopos antes de conectar, especialmente em servidores com escrita.
3. Confusão de agente entre servidores. Com vários servidores conectados, um deles pode influenciar chamadas destinadas a outro por meio de descrições enganosas de ferramentas. Conecte apenas o necessário para a tarefa em curso.

Vale a leitura complementar sobre segurança da informação aplicada a integrações: os princípios não mudaram, mudou apenas quem aperta o botão.

Exemplo prático: um time conectou um servidor MCP de e-mail com permissão de envio ao mesmo agente que lia páginas web. Uma página com instruções embutidas conseguiu induzir o envio de mensagens. A correção não foi um filtro — foi remover a permissão de envio e passar a exigir confirmação humana.

Vale a pena adotar MCP em 2026?

Sim, com uma ressalva de escopo. A adoção deixou de ser aposta: OpenAI, Google DeepMind e Microsoft anunciaram suporte ao longo de 2025, e o protocolo passou a ser o denominador comum entre IDEs com IA, assistentes de desktop e frameworks de agentes. Escrever integrações proprietárias hoje significa refazê-las depois.

A ressalva: MCP é infraestrutura de integração, não estratégia de produto. Ele não melhora a qualidade das decisões do modelo, não reduz alucinação e não substitui o trabalho de desenhar boas ferramentas. Se um agente vai usar exatamente três ferramentas internas e mais nada, registrar essas ferramentas direto no SDK do modelo é mais simples e igualmente eficaz.

O ponto de virada é a reutilização: a partir do momento em que a mesma capacidade precisa ser consumida por mais de um cliente, ou em que você quer aproveitar servidores de terceiros, o MCP passa a economizar mais do que custa.

Exemplo prático: uma empresa com um assistente interno, uma extensão de IDE e um bot de atendimento mantinha três integrações com o mesmo ERP. Consolidadas em um servidor MCP, viraram uma base de código só — e a quarta aplicação nasceu conectada no primeiro dia.

Conclusão

O Model Context Protocol resolve um problema pouco glamouroso e muito caro: a multiplicação de integrações entre modelos de IA e o mundo real. Sua arquitetura — cliente-servidor sobre JSON-RPC, com tools, resources e prompts — é deliberadamente simples, e essa simplicidade é o motivo de ter sido adotada tão rápido pelo ecossistema inteiro. Para quem constrói agentes, a recomendação prática é começar por um servidor local pequeno, com poucas ferramentas muito bem descritas e retorno enxuto, medindo se o modelo escolhe corretamente o que chamar. A partir daí, o caminho para servidores remotos é um problema conhecido de engenharia de APIs — autenticação, escopo, auditoria — com um agravante novo: o cliente do outro lado é um modelo que pode ser induzido a errar, e por isso o menor privilégio deixou de ser boa prática e virou requisito.