O que é MCP (Model Context Protocol)?

MCP é um padrão aberto que permite a aplicações de IA se conectarem a ferramentas e dados externos por um único protocolo, sem integrações sob medida. Apresentado pela Anthropic em novembro de 2024 e padrão da indústria em menos de um ano, ele faz pelos agentes de IA mais ou menos o que uma porta comum fez pelos periféricos — a frase “USB-C da IA” que todo explicador acaba usando. O enquadramento mais afiado para quem desenvolve backend: um servidor MCP é um adaptador de API. Seu backend já sabe responder requisições; o MCP é a forma de torná-lo descobrível e chamável por um modelo de IA, em vez de por código de cliente escrito à mão.

Principais pontos

Um servidor MCP embrulhando um backend que você já tem

// JavaScript / Node.js — an MCP server wrapping an existing backend API
import { McpServer } from '@modelcontextprotocol/sdk/server/mcp.js';

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

// A tool is a described, discoverable wrapper over the API you already have
server.tool('query_tasks', { status: z.string() }, async ({ status }) => {
  const res = await fetch(`${BASE}/classes/Task?where=${q({ status })}`, {
    headers: { 'X-Parse-Application-Id': APP_ID, 'X-Parse-REST-API-Key': KEY },
  });
  return { content: [{ type: 'text', text: await res.text() }] };
});
// The agent discovers this tool at runtime and decides when to call it —
// same backend, same ACLs and rate limits; just a new kind of client.

// Flutter / Dart — Back4app Flutter SDK
// One backend, two kinds of consumers: your app via the SDK…
final tasks =
    await QueryBuilder<ParseObject>(ParseObject('Task')).query();
// …and AI agents via an MCP server wrapping the SAME REST/GraphQL API,
// exposing "query_tasks" and "run_function" as tools the model can call.
// Same data, same ACLs, same rate limits — a new client type, not a new backend.

// iOS / Swift — Back4app Swift SDK
// One backend, two kinds of consumers: your app via the SDK…
let tasks = try await Task_.query().find()
// …and AI agents via an MCP server wrapping the SAME REST/GraphQL API,
// exposing "query_tasks" and "run_function" as tools the model can call.
// Same data, same ACLs, same rate limits — a new client type, not a new backend.

// Android / Kotlin — Back4app Android SDK
// One backend, two kinds of consumers: your app via the SDK…
val tasks = ParseQuery.getQuery<ParseObject>("Task").find()
// …and AI agents via an MCP server wrapping the SAME REST/GraphQL API,
// exposing "query_tasks" and "run_function" as tools the model can call.
// Same data, same ACLs, same rate limits — a new client type, not a new backend.

A aba de JavaScript é a ideia inteira em quinze linhas: uma tool query_tasks é um wrapper descrito e descobrível sobre uma chamada REST que o backend já serve. O agente lê a descrição em tempo de execução, decide quando a tool se aplica e a chama — batendo nos mesmos endpoints, ACLs e rate limits que o seu app. Um novo tipo de cliente, não um novo backend.

Como o MCP resolve o problema de integração N×M

Antes do MCP, ligar N clientes de IA a M ferramentas significava até N × M integrações sob medida. Um protocolo compartilhado colapsa isso para N + M: cada client e cada servidor implementa MCP uma vez. A arquitetura oficial nomeia três papéis — o host é a aplicação de IA; ele cria um client por conexão; cada server fornece capacidade — sobre JSON-RPC, com stdio para servidores locais na mesma máquina e Streamable HTTP para os remotos (o transporte original HTTP+SSE está deprecado).

Os três primitivos

Um único servidor de banco de dados tipicamente expõe os três: uma tool query, um resource schema e um prompt few-shot para os pedidos comuns — “eis o que sei fazer, o que sei e como me perguntar”.

MCP vs. API vs. function calling

As duas comparações se resolvem de forma limpa. Contra uma API: o MCP não a substitui — ele a embrulha, adicionando descoberta em runtime para que o modelo escolha a chamada em vez do código da sua aplicação. Contra function calling: function calling é o modelo emitindo uma requisição estruturada; o MCP padroniza como essa requisição é descoberta e executada entre apps e provedores. O MCP adiciona padronização e portabilidade, não capacidade — tudo que o MCP faz, o function calling sob medida faria para uma integração; o MCP faz funcionar em qualquer lugar sem reescrever.

A superfície de segurança, com honestidade

A seção que as páginas neutras pulam e os vendedores de segurança exageram. O protocolo não é a ameaça; o modelo de confiança é. Prompt injection entra pelas saídas das tools — um documento devolvido por uma tool pode conter instruções que o modelo então segue. Tool poisoning esconde instruções maliciosas na descrição de uma tool, que o modelo lê antes de qualquer humano ver — já catalogado pela OWASP. Rug pulls: um servidor aprovado uma vez pode mudar suas definições de tools depois. E o risco silencioso: a cadeia de suprimentos dos servidores da comunidade — existem milhares, e instalar um lhe concede um ponto de apoio no contexto do seu agente. As mitigações são disciplina comum de segurança aplicada a uma superfície nova: escopos de privilégio mínimo por servidor, aprovação humana para chamadas de tools que agem, fixar versão e manter allow-list dos servidores confiáveis, autenticação de verdade nos servidores remotos e nunca entregar a um servidor MCP credenciais mais amplas do que a tarefa exige.

A especificação hoje

O MCP evolui rápido, e a maioria dos explicadores congelou em meados de 2025 — uma nota de atualidade que vale manter em dia. O transporte se consolidou no Streamable HTTP (HTTP+SSE deprecado); servidores remotos padronizaram autenticação no estilo OAuth; revisões recentes da especificação caminharam para um protocolo stateless, com metadados por requisição e descoberta de capacidades do lado do servidor, e deprecaram um par de recursos iniciais de client. A governança é o sinal maior: no fim de 2025 o protocolo foi doado a uma fundação open-source neutra — o marcador estrutural de um padrão de verdade, e não da convenção de um único fornecedor. A lição prática para quem constrói: fixe uma versão da spec, leia o changelog antes de atualizar e trate “MCP” como um alvo em movimento com um núcleo estável.

Casos de uso comuns

• Agentes de código — assistentes de IDE alcançando seu repositório, banco de dados e issue tracker por servidores, em vez de plugins sob medida.
• Chat sobre dados corporativos — um assistente consultando sistemas internos, cada um embrulhado como um servidor MCP com permissões.
• Exposição do backend — transformar uma API REST/GraphQL existente em tools chamáveis por agentes, sem reconstruí-la.
• Automação de desktop e de fluxos de trabalho — servidores stdio locais fazendo a ponte entre o modelo e os arquivos e aplicativos de uma máquina.
• Portabilidade entre provedores — um servidor atendendo qualquer host que fale MCP, para que a integração sobreviva a qualquer escolha de modelo.

Você deveria usar MCP? Matriz de decisão

Limitações e trade-offs

• É um padrão em movimento. A evolução rápida da spec exige fixar versões e vigiar o changelog; “suporta MCP” é uma afirmação com data de validade.
• O modelo de confiança é novo. Descrições e saídas de tools são superfície de ataque; agentes agindo sobre servidores sem auditoria são o curl \| bash da era atual.
• Overhead abaixo do ponto de virada. Para uma única integração, o MCP adiciona um protocolo e um processo de servidor onde uma chamada de função bastaria.
• A descoberta transfere controle ao modelo. Seleção de tools em runtime é poderosa e menos previsível que chamadas fixas — auditoria e aprovação importam mais, não menos.
• Ele embrulha, não conserta. Um servidor MCP sobre uma API mal protegida só expõe essa API a agentes mais rápido; as permissões subjacentes continuam fazendo o trabalho de verdade.

MCP no Back4app

O Back4app é uma plataforma open-source de Backend as a Service (BaaS) que combina banco de dados gerenciado, APIs REST e GraphQL geradas automaticamente, autenticação, armazenamento de arquivos e funções serverless com Cloud Code. O enquadramento do adaptador de API cai naturalmente aqui: um app do Back4app já expõe a superfície que um servidor MCP embrulha — REST e GraphQL sobre cada classe, mais funções de Cloud Code — então torná-lo acessível a agentes é questão de mapear find objects, run function e read schema para definições de tools, como as abas de código esboçam. A seção de segurança vira orientação concreta: dê ao servidor MCP uma chave com escopo, nunca a master key; deixe as ACLs e permissões em nível de classe da plataforma restringirem o que as chamadas de um agente podem tocar, exatamente como restringem as do seu app; e coloque ações irreversíveis atrás de Cloud Functions com verificações próprias, em vez de acesso cru às tabelas. O agente vira mais um cliente de um backend que já sabe dizer não.