O que é MCP? Entenda o Model Context Protocol na prática

Uma conversa com IA só consegue usar as informações que chegam até ela. Quando você quer consultar dados atuais ou executar uma operação em outro sistema, precisa de uma integração que leve o pedido até esse sistema e traga o resultado de volta.

O MCP, Model Context Protocol, padroniza parte dessa comunicação. É um protocolo aberto para aplicações de IA trocar contexto e chamar capacidades oferecidas por outros programas. Ele define como os componentes conversam; o modelo continua responsável por interpretar as informações que recebe.

Para acompanhar uma integração dessas, vale entender quem coordena a chamada, quem executa a operação e onde o acesso é conferido. O protocolo não substitui as permissões nem as regras de negócio do sistema conectado.

Como funciona a arquitetura do MCP

Há três participantes principais:

• Host: a aplicação de IA aberta pela pessoa. Ela coordena o modelo, as conexões MCP, a interface e as políticas da aplicação.
• Cliente MCP: componente criado pelo host para manter a conexão com um servidor específico e trocar mensagens no protocolo.
• Servidor MCP: programa que oferece capacidades ao cliente. Ele pode rodar na própria máquina ou em outro ambiente acessível pela rede.

Com essas responsabilidades separadas, considere uma consulta de logística: “Qual é a situação do envio BR123?”. O host recebe a pergunta e disponibiliza ao modelo a capacidade de consultar status. O modelo pode propor uma chamada com o código BR123. O host decide, conforme sua política, se encaminha a solicitação pelo cliente MCP. O servidor recebe a chamada, consulta o sistema de logística e devolve um resultado; o host o entrega ao modelo para formular a resposta.

Portanto, dizer que “a IA acessa a API” resume várias responsabilidades. O modelo pode selecionar uma ferramenta, mas não abre sozinho a conexão MCP nem deve ser tratado como autoridade de acesso. O host faz a mediação; o servidor executa a operação e precisa aplicar as regras do sistema que protege.

O protocolo organiza mensagens e capacidades. A especificação atual descreve uma camada de dados baseada em JSON-RPC e uma camada de transporte, que cuida do canal de comunicação e de aspectos como autenticação. Detalhes de implantação variam conforme transporte, SDK e versão adotados.

Ferramentas, recursos e prompts têm papéis diferentes

Um servidor MCP pode expor ferramentas (tools), recursos (resources) e modelos de prompt (prompts). Eles não são nomes diferentes para a mesma coisa.

Capacidade	Papel no protocolo	Exemplo no atendimento sobre o envio
Ferramenta	Oferece uma operação que pode ser chamada, com nome, descrição e esquema de entrada.	consultar_status(codigo) busca o estado atual do envio.
Recurso	Expõe dados identificados por URI para o host incorporar ao contexto conforme sua aplicação.	Uma página de referência explica o significado dos estados “em trânsito” e “em rota de entrega”.
Prompt	Fornece uma mensagem ou modelo que a pessoa pode selecionar e preencher.	“Explique o status do envio ao cliente com linguagem simples.”

O host e sua interface controlam como essas capacidades aparecem. A especificação descreve ferramentas como controladas pelo modelo, recursos como orientados pela aplicação e prompts como controlados pela pessoa; ela também deixa espaço para implementações usarem outras interfaces.

Para a consulta ao BR123, uma chamada de ferramenta é apropriada porque pede uma informação atual por código. A lista de estados pode ser um recurso de referência. Um prompt pode ajudar a explicar o resultado. O modelo ainda precisa distinguir o conteúdo da referência da informação atual devolvida pela consulta.

O protocolo não concede acesso nem aprova ações por você

Conectar um servidor não significa que toda operação esteja autorizada. A disponibilidade de uma ferramenta, a credencial apresentada, os escopos concedidos e as regras do serviço são decisões que precisam ser configuradas e verificadas. A especificação MCP inclui mecanismos de autorização para cenários de transporte HTTP, mas isso não equivale a uma permissão universal sobre os dados ou sistemas conectados.

O modelo também não executa uma chamada diretamente no sistema de logística: ele pode solicitar ao host que use uma ferramenta. O host controla o fluxo de invocação e a aplicação escolhe como apresentar as chamadas. A especificação recomenda que exista uma pessoa capaz de negar invocações, sobretudo por segurança; ela não impõe uma confirmação idêntica em todas as aplicações.

Mesmo sendo somente leitura, consultar_status pode expor informação de uma encomenda. A aplicação deve limitar quem pode consultar determinado código, evitar registrar dados sensíveis sem necessidade e deixar claro qual servidor está conectado. Se o serviço oferecer operações de escrita, como cancelar um envio, os controles precisam levar em conta o efeito da ação e a política do produto.

Trate respostas de servidores como dados externos

Uma resposta MCP não se torna confiável apenas porque veio de um servidor conectado. No caso do BR123, o status retornado pode estar desatualizado, incompleto ou conter texto inesperado. A aplicação deve validar o formato e a origem, e o modelo deve tratar o conteúdo como informação a interpretar, não como instrução que substitui as regras do host.

Esse cuidado fica ainda mais importante quando um fluxo passa o resultado de um servidor para outro. Uma descrição de status poderia conter texto malicioso tentando orientar o modelo a revelar dados ou acionar outra ferramenta. O resultado deve ser tratado como entrada não confiável, com validação e controles na fronteira entre sistemas. Cortar ou resumir uma resposta, por si só, não garante segurança.

Como pensar em uma integração MCP

Antes de escolher um SDK ou transporte, defina a operação do exemplo: consultar o estado atual de um envio a partir do código informado. Depois, responda a estas perguntas:

1. Qual capacidade será exposta? Uma ferramenta com entrada validada para código de rastreio e resposta estruturada com status e data da atualização.
2. Qual sistema é a fonte dos dados? O servidor deve consultar a API de logística autorizada e respeitar seus limites de acesso e disponibilidade.
3. O que o host precisa controlar? Quais servidores são conectados, quais ferramentas são apresentadas ao modelo, como credenciais são protegidas e quando uma pessoa precisa confirmar ou negar uma chamada.
4. Como verificar o resultado? Teste códigos inexistentes, indisponibilidade, credencial sem acesso e respostas fora do formato esperado, além de uma consulta válida.

Esse desenho evita confundir a padronização da conversa com a implementação do negócio. MCP não fornece automaticamente uma API de logística, não garante que a resposta esteja correta e não define sozinho a experiência de aprovação. O sistema integrado continua responsável pelos dados e suas regras; o host continua responsável por decidir como a integração é oferecida.

Para entender como a aplicação coordena as próximas ações, continue em modelo, harness e agente. Se a dúvida é como reutilizar um procedimento de trabalho, o artigo sobre Agent Skills explica o papel das instruções, que é diferente do papel das ferramentas.

Fontes oficiais

• Visão geral da arquitetura do MCP
• Especificação de ferramentas, recursos e prompts
• Boas práticas para clientes MCP e segurança

As referências foram consultadas em 27/10/2026. Para implementar, confira a versão da especificação e do SDK compatíveis com o seu projeto.