---
term: 'MCP (Model Context Protocol)'
seoTitle: 'MCP (Model Context Protocol): Servidores, Tools e Segurança'
headline: 'O que é MCP (Model Context Protocol)?'
slug: mcp
category: ai-modern-stack
shortDefinition: '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.'
relatedTerms:
  - api
  - rest-api
  - webhooks
  - api-key-security
contrastsWith:
  - api
aboutTerms:
  - 'Servidor MCP'
  - 'Tools, Resources, Prompts'
  - 'Host, Client, Server'
faq:
  - question: 'O que é MCP em termos simples?'
    answer: 'Um padrão aberto que permite a aplicações de IA se conectarem a ferramentas e dados externos por um protocolo comum, em vez de uma integração sob medida por ferramenta. A analogia clássica é a de uma porta USB-C para IA: um conector, muitos dispositivos — com o modelo decidindo em tempo de execução qual ferramenta usar.'
  - question: 'Quem criou o MCP e quando?'
    answer: 'A Anthropic o apresentou em novembro de 2024. Ao longo de 2025, os grandes provedores de modelos de IA e fabricantes de ferramentas de desenvolvimento o adotaram, milhares de servidores da comunidade surgiram e a governança migrou para uma fundação open-source neutra no fim do ano — o arco que leva do protocolo de uma empresa a um padrão da indústria.'
  - question: 'MCP é uma API? Ele substitui as APIs?'
    answer: 'Não — o MCP é uma camada de protocolo que normalmente embrulha APIs existentes em vez de substituí-las. A maioria dos servidores MCP chama uma API REST ou GraphQL convencional por baixo; o MCP padroniza como um modelo de IA descobre, descreve e invoca essas capacidades, não o que as capacidades são. Uma API é voltada ao desenvolvedor; o MCP é voltado ao modelo, com descoberta em tempo de execução.'
  - question: 'Qual é a diferença entre MCP e function calling?'
    answer: 'Function calling é a capacidade do modelo — o LLM emite uma requisição estruturada para executar uma função nomeada. O MCP padroniza como essas funções são descobertas, descritas e executadas entre apps e provedores diferentes. O function calling é a intenção; o MCP é a camada portátil de execução. Eles se compõem; nenhum substitui o outro.'
  - question: 'O que é um servidor MCP?'
    answer: 'Um programa que expõe tools, resources e prompts a clientes de IA pelo protocolo — rodando localmente via stdio ou remotamente via HTTP. Um servidor MCP de banco de dados pode oferecer uma tool de consulta, um resource de schema e alguns templates de prompt. Atenção ao vocabulário: MCP é o protocolo; o artefato que você executa é um "servidor MCP".'
  - question: 'O que são tools, resources e prompts?'
    answer: 'Os três primitivos de um servidor. Tools são funções que o modelo pode invocar, executadas com aprovação do usuário. Resources são dados de contexto legíveis, no estilo de arquivos. Prompts são templates reutilizáveis de interação. Juntos, permitem que um servidor diga "eis o que sei fazer, o que sei e como me perguntar".'
  - question: 'O MCP é seguro?'
    answer: 'O protocolo é neutro; os riscos são reais: prompt injection pelas saídas das tools, tool poisoning (instruções maliciosas escondidas na descrição de uma tool), rug pulls (um servidor mudando suas definições depois de aprovado) e a cadeia de suprimentos de servidores da comunidade sem auditoria. As mitigações são escopos de privilégio mínimo, aprovação humana das chamadas de tools, fixar versão e manter allow-list de servidores, e autenticação nos servidores remotos.'
  - question: 'O MCP funciona com qualquer modelo de IA?'
    answer: 'Esse é o objetivo de padronizá-lo — um servidor escrito uma vez funciona com qualquer host que fale o protocolo, entre provedores. A mesma integração que um agente de código usa fica acessível a um assistente de chat ou a um agente customizado, que é exatamente a redução de N×M para N+M que o padrão existe para entregar.'
codeLanguages: [javascript, dart, swift, kotlin]
externalAuthorities:
  - name: 'Model Context Protocol — official documentation'
    url: 'https://modelcontextprotocol.io/docs/getting-started/intro'
  - name: 'MCP architecture — host, client, server'
    url: 'https://modelcontextprotocol.io/docs/learn/architecture'
  - name: 'Introducing the Model Context Protocol — Anthropic'
    url: 'https://www.anthropic.com/news/model-context-protocol'
  - name: 'MCP Tool Poisoning — OWASP'
    url: 'https://owasp.org/www-community/attacks/MCP_Tool_Poisoning'
  - name: 'Model Context Protocol — Wikipedia'
    url: 'https://en.wikipedia.org/wiki/Model_Context_Protocol'
cta:
  title: 'Seu backend, pronto para agentes'
  text: 'Um app do Back4app já expõe APIs REST e GraphQL — exatamente a superfície que um servidor MCP embrulha como tools, para que agentes alcancem seus dados pelas mesmas ACLs, chaves e rate limits que o seu app usa.'
  linkText: 'Comece grátis'
  linkUrl: 'https://www.back4app.com/signup'
author: 'Back4app Engineering'
publishedDate: '2026-08-21'
translationKey: model-context-protocol-mcp
---

**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

| Pergunta | Resposta |
| --- | --- |
| O que é | Um protocolo aberto (JSON-RPC) conectando apps de IA a ferramentas e dados |
| O problema que resolve | N clientes × M ferramentas em integrações sob medida → N + M com um padrão |
| As partes | Host (o app de IA) · client (uma conexão por servidor) · server (a capacidade) |
| Os primitivos | Tools (fazer) · resources (ler) · prompts (templates) |
| A ressalva honesta | Superfície real de segurança — tool poisoning, rug pulls, servidores sem auditoria |

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

**JavaScript:**

```javascript
// JavaScript / Node.js — an MCP server wrapping an existing backend API

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
// 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.
```

**Swift:**

```swift
// 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.
```

**Kotlin:**

```kotlin
// 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](/glossary/pt/listas-de-controle-de-acesso-acl/) 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

```mermaid
flowchart LR
  accTitle: Host, client e servidores MCP substituindo integrações sob medida
  accDescr: Uma aplicação host de IA cria um client MCP por conexão de servidor. Cada client fala o protocolo padrão com um servidor MCP, que expõe tools, resources e prompts apoiados por uma API ou banco de dados subjacente. Como todo client e todo servidor implementam o mesmo protocolo, as integrações escalam como N mais M em vez de N vezes M.
  H["Host<br/>(a aplicação de IA)"] --> C1["Client 1"] --> S1["Servidor MCP:<br/>banco de dados (tools + schema)"]
  H --> C2["Client 2"] --> S2["Servidor MCP:<br/>arquivos (resources)"]
  H --> C3["Client 3"] --> S3["Servidor MCP:<br/>sua API REST/GraphQL"]
  S1 -.-> API[("APIs e dados<br/>subjacentes")]
  S2 -.-> API
  S3 -.-> API
```

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](https://modelcontextprotocol.io/docs/learn/architecture) 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

| Primitivo | O modelo pode… | Analogia de backend |
| --- | --- | --- |
| **Tools** | *Fazer* — invocar uma função (com aprovação do usuário) | Um [endpoint de API](/glossary/pt/api-rest/) ou uma [Cloud Function](/glossary/pt/cloud-code-funcoes-serverless/) |
| **Resources** | *Ler* — puxar contexto no estilo de arquivo | Uma rota GET / um repositório de documentos |
| **Prompts** | *Reutilizar* — aplicar um template de interação | Uma consulta salva ou um snippet |

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

| | [API](/glossary/pt/api/) pura | Function calling | MCP |
| --- | --- | --- | --- |
| Voltado a | Desenvolvedores | O modelo, por app | O modelo, de forma portátil |
| Quem escolhe a chamada | Seu código | O modelo, por app | O modelo, em qualquer host |
| Descoberta | Docs, em tempo de build | Fixada por app | Em runtime, padronizada |
| Portabilidade | n/a | Presa a uma integração | Escreva uma vez, qualquer host/provedor |
| Adiciona | A capacidade | A *intenção* de chamar | A *execução* padronizada |

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](https://owasp.org/www-community/attacks/MCP_Tool_Poisoning). **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](/glossary/pt/seguranca-de-chaves-de-api/) 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](/glossary/pt/api-rest/) 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

| Situação | Tendência |
| --- | --- |
| Muitos clientes de IA precisam de muitas ferramentas | MCP — o ganho de N+M é o ponto |
| Expor seu backend a agentes | Servidor MCP embrulhando a [API](/glossary/pt/api/) que você já tem |
| Um app, uma ferramenta, um provedor | Function calling direto — menos maquinário |
| Fluxo determinístico no servidor, sem modelo escolhendo | Uma [chamada de API](/glossary/pt/api-rest/) pura |
| Instalar servidores de terceiros | Auditar, fixar versão e privilégio mínimo — ou não instalar |
| Portabilidade entre provedores de modelo importa | MCP — escreva o servidor uma vez |

## 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](/glossary/pt/listas-de-controle-de-acesso-acl/) 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](/glossary/pt/seguranca-de-chaves-de-api/) com escopo, nunca a master key; deixe as [ACLs e permissões em nível de classe](/glossary/pt/listas-de-controle-de-acesso-acl/) 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](/glossary/pt/cloud-code-funcoes-serverless/) 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.