O que é MCP (Model Context Protocol) e para que serve

Você pede ao assistente para achar o contrato na pasta do cliente. Ele não vê a pasta. Você cola o arquivo. No dia seguinte, pede a planilha. Cola de novo. Na semana, tenta ligar o mesmo assistente ao Slack e à agenda. Cada ferramenta pede um plugin, uma chave, um jeito diferente. Você reensina o assistente a cada app.

O problema não é o modelo. É que cada programa fala com arquivos, mensagens e calendários por um caminho próprio. Sem contrato comum, cada conexão vira caso especial.

MCP é a sigla de Model Context Protocol: protocolo de contexto para modelos. É um padrão aberto para um assistente de inteligência artificial (IA) usar ferramentas e dados por “servidores” padronizados, em vez de um plugin por aplicativo.

O que é MCP

MCP é um contrato, não uma tela e não um produto com logotipo. As regras dizem: o assistente pode pedir uma lista de arquivos, ler um trecho, chamar uma função, e o outro lado responde num formato combinado.

Quem pede é o aplicativo em que você conversa (o cliente). Quem expõe pasta, planilha, banco ou API da empresa é o servidor MCP. O modelo não precisa saber se o dado veio do disco ou de um sistema interno. Precisa só cumprir o contrato.

Na prática, isso reduz retrabalho. Em vez de ensinar o Claude, o Cursor e uma terceira ferramenta a ler a mesma pasta, você sobe um servidor que fala MCP. Qualquer cliente compatível pode usá-lo, se você autorizar.

A analogia que o próprio padrão usa é o USB-C: um encaixe comum, em vez de um cabo por fabricante. Daqui para frente, o texto trata MCP como protocolo entre cliente e servidor.

O que MCP não é

MCP não é um modelo. Não substitui ChatGPT, Claude, Gemini nem o modelo que o Cursor usa. O modelo continua sendo o motor que lê texto e decide o próximo passo. MCP é o jeito de esse motor chegar a arquivo e sistema sem um arranjo novo a cada vez.

MCP não é um chatbot. Não abre conversa e não “responde e-mail sozinho”. Se o assistente manda mensagem no Slack, quem mandou foi o cliente chamando uma ferramenta que um servidor expôs. O protocolo só padronizou o pedido e a resposta.

MCP não é a API de uma empresa. Não é “a API da Anthropic” nem “a API da OpenAI”. API (interface de programação de aplicações) é o contrato que um sistema publica para outro sistema usar. MCP muitas vezes embrulha APIs já existentes atrás de um padrão único. Os dois se complementam; não são o mesmo objeto.

Um quadro concreto de trabalho

Um analista na segunda precisa cruzar a pasta do cliente, a planilha de horas e o status de um pedido no sistema da empresa.

Sem padrão, o caminho vira colar arquivo, exportar planilha, copiar tela. Cada cola é risco (nome, valor, anexo que não deveria sair) e retrabalho. Na terça o contexto some.

Com um servidor MCP de sistema de arquivos, o cliente pode pedir: liste os PDFs; leia o contrato mais recente; extraia a cláusula de prazo. Com um servidor da planilha, pede as linhas da semana. Com um servidor que chama a API interna, consulta o pedido 8841, o mesmo tipo de GET que um site faria, sem o assistente conhecer o endpoint.

Nada disso acontece por mágica. Alguém ligou o servidor, disse qual pasta ou qual API, e o cliente pediu permissão. O assistente passa a usar o que o servidor expõe, não a “ver a empresa inteira”. O julgamento continua seu.

Servidor e cliente, em linguagem comum

O cliente é o aplicativo em que você conversa: Claude Desktop, Cursor e outros que adotaram o padrão. É ele que mostra o chat, manda o texto ao modelo e, quando o modelo pede uma ferramenta, consulta o servidor.

O servidor é o programa que expõe um pedaço do mundo real: uma pasta, documentos, um calendário, uma API da empresa. Ele declara o que sabe fazer (“listar arquivos”, “ler trecho”, “consultar pedido”) e espera o pedido no formato MCP.

A conversa, simplificada:

1. Você escreve no cliente: “qual o prazo do contrato da Oficina Norte?”
2. O modelo, dentro do cliente, decide que precisa ler um arquivo.
3. O cliente pede ao servidor de arquivos a lista ou o conteúdo autorizado.
4. O servidor devolve o trecho. O modelo redige a resposta. Você lê e confere.

Se o servidor não tiver aquela pasta, ou se você não tiver dado permissão, o passo 3 falha. O assistente não inventa o contrato. Ele ainda pode inventar o prazo, isso é limite do modelo, não do protocolo. MCP não torna a resposta verdadeira.

Um cliente pode falar com vários servidores ao mesmo tempo. Cada servidor é uma caixa com borda. A borda importa na segurança.

O que um iniciante consegue fazer hoje

Não precisa escrever um servidor. O começo honesto é conectar uma fonte que você já controla, num aplicativo que já fala MCP.

Dois exemplos comuns de cliente compatível: Claude Desktop e Cursor. A lista de apps muda; o gesto é o mesmo. Você abre as configurações de MCP, aponta um servidor de arquivos ou de documentos e autoriza o acesso.

Um caminho realista para quem não programa:

1. Escolha uma pasta que já poderia ir para um colega: propostas genéricas, modelos de ata, material sem dado de cliente. Não escolha a pasta do jurídico nem o backup do financeiro.
2. No app compatível, adicione o servidor de sistema de arquivos (ou o equivalente de documentos) e aponte só essa pasta.
3. Peça algo verificável: “liste os PDFs”; “abra o arquivo X e extraia o índice”. Confira no Finder, no Explorer ou no editor se a lista está certa.
4. Só então peça um resumo. O protocolo entrega o arquivo. O modelo ainda pode resumir mal. A conferência no original não some.

Isso não é um assistente que “entende a empresa”. É um assistente que pode ler o que o servidor expôs, com a permissão que você deu. Se a pasta tiver contrato e planilha de salário, você ampliou o raio do vazamento.

Não instale servidor aleatório baixado de fórum. Servidor MCP é programa que fala com o seu disco ou com a sua conta. Trate como instala aplicativo, não como atalho de chat.

MCP e API: o mesmo problema, outra camada

Se API ainda é um termo opaco, leia O que é uma API? Entenda como funciona com exemplos antes de ligar qualquer servidor a um sistema interno.

A relação é direta. Uma API publica endpoints, métodos, autenticação e códigos de status. MCP não substitui isso. Muitos servidores MCP chamam APIs por baixo: o assistente pede “status do pedido 8841”; o servidor traduz para GET `/pedidos/8841` com o token que o servidor guarda e devolve o resultado ao cliente.

A vantagem: um jeito só de pedir ferramenta, em vez de aprender a documentação de cada fornecedor. A responsabilidade não some. Alguém ainda precisa:

• guardar o token no servidor, não no prompt
• limitar o que o servidor pode chamar (só leitura de pedido, não exclusão de cliente)
• tratar 401, 403 e 429 como trata numa integração normal
• decidir se aquele dado pode sair da empresa rumo ao modelo

Se a empresa já tem API privada, o passo maduro não é colar a chave no chat. É um servidor MCP, configurado por quem cuida do sistema, expondo umas operações, com registro de quem pediu o quê. A API continua sendo o contrato de verdade com o estoque, o CRM, o financeiro.

Quando a planilha ainda basta, MCP não é obrigatório. Quarenta linhas que mudam duas vezes por semana pedem o arquivo certo, não um servidor.

Limites: permissão, visão, segredo, suporte

Protocolo comum não é acesso irrestrito.

Permissão. O cliente pede; o servidor (e, em apps sérios, a tela de autorização) decide. Se você não aprovou a pasta, o assistente não lê. Se aprovou a pasta errada, o protocolo obedece ao erro humano.

O que o servidor pode ver. A borda é a configuração. Servidor de arquivos na pasta de modelos não deveria enxergar a pasta de clientes. Servidor da API de pedidos não deveria ter a chave do RH. Antes de ligar: se esse servidor for comprometido, o que vaza?

Segredo. Token, senha e chave de API não entram no chat “para o assistente configurar”. Também não deveriam ficar em arquivo que o servidor de arquivos vai listar. O servidor autentica com o outro sistema; o modelo recebe o resultado, não a chave. Se a chave vazar, revogue. Chave é porta, não nome.

Nem todo app fala MCP. O chat no navegador, o Copilot da empresa ou o Gemini no celular podem não ter cliente MCP. Não force. Se a ferramenta de trabalho não suporta, a ponte continua sendo API, exportação controlada ou colar só o trecho limpo.

Ainda evolui. O padrão é aberto e o ecossistema muda. Este texto não aposta em data. O que permanece: contrato comum; permissão na borda; não tratar servidor como mágica.

MCP também não resolve alucinação. O modelo pode ler o contrato certo e inventar um prazo. Continua valendo conferir no original.

O que fazer agora

Hoje: escreva em uma frase a tarefa repetitiva de acesso a ferramenta. Exemplos: “achar o último PDF na pasta X”; “ler a planilha de horas”; “consultar status de pedido no sistema Y”. Se a frase não sai, você ainda não tem caso de MCP. Curiosidade não justifica ligar servidor na pasta do cliente.

Nesta semana: se a frase saiu e o dado pode ser visto por um colega de confiança, teste um servidor conhecido, num cliente que você já usa (Claude Desktop, Cursor ou o equivalente da empresa), apontando uma pasta estreita. Peça uma listagem. Confira. Só então peça um resumo.

Não faça: instalar servidores de origem duvidosa; apontar o disco inteiro; colar token no chat; tratar a resposta como ata.

MCP serve para parar de reensinar o assistente a cada app, se você escolher a borda. O protocolo padroniza o encaixe. Quem decide o que entra continua sendo você.