O que é MCP e por que ele é necessário ao seu ChatGPT App

1. Por que precisamos de um protocolo separado

Neste módulo, vamos finalmente entender o que é o MCP (Model Context Protocol) e como ele se encaixa na pilha do ChatGPT App. Vamos começar fixando o lugar do MCP na arquitetura, compará‑lo com o “REST típico” e analisar as principais entidades do protocolo: tools, resources e prompts.

Imagine que você está desenvolvendo um serviço web comum. Pela boa e velha tradição, você sobe um API REST: você tem /api/gifts, /api/users, /api/orders, cada um com seu formato de entrada e saída, seus códigos de erro e autenticação. Isso é familiar, mas há um detalhe: para cada cliente você precisa explicar o que e como foi implementado. Documentação, OpenAPI, exemplos, SDK — tudo isso é necessário porque você inventou o formato do seu API.

Com o ChatGPT App, a situação fica mais complexa. Seu cliente não é apenas o frontend, mas também o próprio modelo. Ele precisa:

• saber quais operações estão disponíveis;
• entender quais argumentos cada operação precisa;
• chamar essas operações ao longo do diálogo, às vezes várias vezes, às vezes com parâmetros diferentes;
• interpretar a resposta estruturada e decidir o que mostrar ao usuário e o que usar apenas como contexto para a próxima interação.

Se cada desenvolvedor inventar seu próprio formato de API, o modelo vai cair no inferno da integração: para cada App será necessário um cliente customizado, um monte de boilerplate e lógica frágil. A ideia de um protocolo resolve o problema.

MCP (Model Context Protocol) é uma especificação aberta de uma forma padrão de como um cliente LLM (ChatGPT, plugin de IDE, agente etc.) conversa com o seu servidor de ferramentas e dados. Ele define uma linguagem comum na qual o servidor anuncia suas ferramentas, recursos e prompts, e o cliente os chama e obtém os resultados.

Intuitivamente, o MCP é a porta USB‑C para o mundo de IA: se você faz um “pendrive” (serviço, banco de dados, CRM, mecanismo de busca), basta implementar um conector padrão. Então qualquer “notebook” (ChatGPT, outro agente, IDE) pode se conectar a você sem um cabo personalizado.

2. Visão do alto: onde fica o MCP na arquitetura do ChatGPT App

Para fixarmos a imagem, vamos relembrar a arquitetura já conhecida, agora com a camada do MCP explicitada.

Você já viu a imagem mental atual: o usuário conversa com o ChatGPT, o widget (Apps SDK) é renderizado dentro do diálogo e, em algum lugar externo, vive o seu backend. Agora vamos adicionar o MCP e decompor tudo por camadas.

Aqui está um esquema simplificado:

Usuário
   ↓ (linguagem natural)
ChatGPT (modelo + UI)
   ↓ (tool calls via MCP)
Cliente MCP dentro do ChatGPT
   ↓ (JSON-RPC, MCP)
Seu servidor MCP (backend)
   ↓
Seu banco de dados / APIs externas / filas

Por “cliente MCP dentro do ChatGPT”, entende‑se aqui a parte interna da plataforma que conversa com o seu servidor MCP pelo protocolo: faz discovery, chama ferramentas e lê recursos.

Do ponto de vista do Apps SDK, um ChatGPT App mínimo é composto por três componentes. O primeiro — o servidor MCP, que anuncia ferramentas e entrega dados estruturados. O segundo — o bundle de UI (widget), que é renderizado dentro do ChatGPT e lê esses dados via window.openai. O terceiro — o próprio modelo, que decide quando chamar qual ferramenta e como responder ao usuário.

É importante notar o seguinte. Nos módulos anteriores, você trabalhou muito no nível do Apps SDK e do widget, ou seja, na parte superior do esquema. Agora descemos para o nível do servidor MCP — este é o seu “idioma oficial” de comunicação com o ChatGPT e com quaisquer outros clientes que decidirem usar seu App.

3. MCP versus “REST típico”: qual é a diferença

No esquema acima, fixamos onde o MCP fica na arquitetura do ChatGPT App. Agora é hora de comparar cuidadosamente as abordagens “seu próprio REST” e MCP, para entender por que, no contexto de ChatGPT Apps, a segunda opção quase sempre vence.

Na abordagem REST, você projeta endpoints, formatos de requisições e respostas da forma que for conveniente para você. Para o cliente trabalhar com você, ele precisa conhecer URLs, métodos, schemas e códigos de erro. Às vezes o OpenAPI ajuda, às vezes você só joga um exemplo de requisição no README. O modelo por si só não entende nada disso: é necessária uma camada de código que transforme “escolha um presente para minha mãe de 50 anos” em uma requisição HTTP específica e, na volta, o JSON em dados utilizáveis no diálogo.

No MCP é diferente. O protocolo por si define:

• como o cliente pode descobrir a lista das suas ferramentas;
• como descrever argumentos e resultados via JSON Schema;
• como descrever recursos e prompts;
• como é uma chamada de ferramenta e a resposta dela.

Graças a isso, o ChatGPT e outros clientes MCP podem automaticamente:

• executar discovery — descobrir quais tools/resources/prompts você tem;
• construir um schema interno de parâmetros para cada ferramenta;
• chamá‑las sem lógica cliente hardcoded e customizada;
• fazer cache de metadados e usá‑los na busca e ranqueamento de aplicativos.

Podemos resumir a diferença em uma pequena tabela.

Em termos mais emocionais: REST é “cada um por si”, o MCP é “um acordo entre todos na ecossistema sobre como conversar com o modelo e com os dados”.

4. Entidades principais do MCP: tools, resources, prompts

Agora vamos nomear os três protagonistas do MCP: ferramentas, recursos e prompts.

Tools: ações às quais você já está acostumado

Você já lidou com tools no Módulo 4: lá descrevemos uma ferramenta, demos a ela um nome, uma descrição e o JSON Schema dos argumentos, e então o modelo a chamou via callTool. No nível do MCP, uma ferramenta é uma operação de servidor com um contrato claro:

• nome e descrição (para o modelo e para UX/discovery);
• JSON Schema para os argumentos;
• JSON Schema ou descrição da estrutura do resultado;
• metainformações adicionais (por exemplo, vínculo a um componente específico de UI no Apps SDK).

O servidor MCP deve, pelo menos, ser capaz de responder a “pedido de lista de ferramentas” e processar “chamada de ferramenta”, retornando um resultado estruturado.

No nosso app de estudo de ajuda para presentes, já existe, por exemplo, a ferramenta suggest_gifts, que recebe idade, gênero, orçamento e algumas preferências, e retorna uma lista de presentes recomendados.

Um esboço hipotético em TypeScript dessa ferramenta no código do servidor MCP pode se parecer, por exemplo, com isto (pseudocódigo/placeholder):

// Pseudocódigo; não é a API final do SDK
const suggestGiftsTool = defineTool({
  name: "suggest_gifts",
  description: "Seleciona ideias de presentes com base nos parâmetros do destinatário",
  inputSchema: z.object({
    age: z.number(),
    relation: z.enum(["friend", "partner", "parent"]),
    budgetUsd: z.number(),
  }),
  handler: async (input) => {
    // TODO: sua lógica de negócio
    return { items: [] };
  },
});

Vamos analisar as assinaturas reais nas próximas aulas; aqui, a ideia é o que importa: uma ferramenta não é apenas um endpoint REST, é um elemento do protocolo com schema declarado.

Recursos (resources): dados que podem ser acessados por ID/URI

Recursos (resources) no MCP são uma forma de descrever os dados disponíveis: arquivos, diretórios, registros de banco de dados, páginas de wiki, até resultados de índices de busca. O cliente pode:

• obter a lista de recursos;
• ler um recurso específico por ID/URI;
• às vezes — executar busca sobre eles.

Ao contrário de tools, que “fazem algo”, resources geralmente “armazenam algo”. Por exemplo, no Gift‑App você pode representar o catálogo de produtos como o recurso gift_catalog, ao qual o modelo recorre para conhecer as categorias disponíveis, filtros, faixas de preço e assim por diante.

No código, conceitualmente, pode ficar assim:

const giftCatalogResource = defineResource({
  uri: "catalog://gifts",
  description: "Catálogo de presentes disponíveis para recomendação",
  read: async () => {
    // Retornamos a estrutura do catálogo
    return { categories: [], priceRanges: [] };
  },
});

Ainda não estamos entrando no formato das mensagens do MCP, mas tenha em mente: recursos são entidades endereçáveis às quais o servidor MCP pode se referir, e o cliente pode ler e usar como parte do contexto.

Prompts: instruções pré‑prontas

Prompts no contexto do MCP são templates de solicitações ou instruções que o servidor pode fornecer ao cliente. Por exemplo, você pode declarar o prompt gift_followup, que descreve como o modelo deve pedir ao usuário detalhes sobre o destinatário do presente antes de chamar a ferramenta.

Um exemplo típico no espírito do protocolo: o servidor fornece o nome do prompt, sua finalidade e, às vezes, parâmetros. O cliente pode solicitar a lista de prompts, escolher o necessário e inseri‑lo na solicitação ao modelo.

Por que isso é útil para o ChatGPT App? Em primeiro lugar, é uma forma unificada de reutilizar prompts complexos entre clientes. Em segundo, o MCP torna esses prompts explícitos e “contratuais”, e não escondidos em lugares aleatórios do código.

Capabilities: declaração do que você suporta

Por fim, há um quarto elemento — capabilities. É apenas uma declaração: o servidor diz quais entidades ele suporta (tools, resources, prompts, notificações etc.) e quais métodos exatamente ele implementa. Para o cliente, é uma maneira de não adivinhar o que pode ou não ser feito e adaptar seu comportamento às capacidades do servidor.

Na prática, ao se conectar ao seu servidor MCP, o ChatGPT primeiro realiza um “handshake”, obtém a lista de capabilities e só então pergunta: “Ok, mostre suas ferramentas e recursos”.

5. Como o MCP se encaixa no seu App atual

Tudo isso parece um pouco abstrato, mas na realidade você já esbarrou no MCP via Apps SDK. Vale começar entendendo como tudo isso se conecta ao que você já escreveu no Apps SDK. Vamos relacionar as entidades recém‑apresentadas com a forma como o seu template de App está organizado hoje.

Vamos relembrar a cadeia que você já implementou no template:

1. O widget, por meio de window.openai ou hooks prontos, chama callTool com o nome da ferramenta e os argumentos.
2. O Apps SDK dentro do ChatGPT transforma isso em uma chamada para a parte de servidor do App.
3. O servidor executa a ferramenta e retorna um ToolOutput, incluindo structuredContent, content e _meta.
4. O widget recebe o ToolOutput e desenha o UI.

O segredo é que os passos 2–3 são implementados como um diálogo via MCP. Seu template Next.js contém um endpoint (normalmente app/mcp/route.ts ou similar), que é justamente o servidor MCP. Ele:

• registra suas ferramentas;
• as descreve via JSON Schema;
• implementa os handlers;
• responde ao ChatGPT às requisições MCP list tools e call tool.

Ou seja, mesmo agora, usando o template, você já trabalha com MCP, só que “automaticamente”: boa parte da mágica do protocolo está embutida no SDK.

O Módulo 6 é para que você pare de tratar o MCP como uma “caixa‑preta mágica” e comece a projetá‑lo conscientemente:

• adicionar e versionar ferramentas;
• usar resources e prompts, não apenas tools;
• ler e entender os logs do MCP;
• se necessário, subir servidores MCP separados fora do template Next.js (por exemplo, um serviço em Python para trabalhar com um modelo de ML ou um serviço separado para acesso a um banco corporativo).

6. MCP pelos olhos de papéis diferentes: produto vs. desenvolvedor

É útil formular separadamente o que o MCP oferece a um product manager e a um engenheiro.

MCP para produto

Do ponto de vista de produto, o MCP é uma forma de tornar seu serviço um “módulo plugável” para toda uma variedade de clientes: ChatGPT, outros clientes LLM, plugins de IDE, seus próprios agentes. Uma vez descritas as capacidades do servidor como um conjunto de tools/resources/prompts, você permite a qualquer cliente:

• descobrir seu serviço automaticamente;
• entender quais problemas ele resolve;
• chamar as operações necessárias com segurança.

No caso de um ChatGPT App, isso também aumenta a probabilidade de o seu aplicativo ser escolhido: o modelo usa metadados sobre suas ferramentas para decidir quando sugerir seu App ao usuário e como apresentá‑lo corretamente.

Resumindo: o MCP torna seu serviço um “bloco” padrão da ecossistema, e não uma integração customizada para um ou dois clientes.

MCP para desenvolvedor

Do ponto de vista do engenheiro, o MCP é um contrato e um protocolo. Ele responde às perguntas:

• Em que formato devo anunciar uma ferramenta?
• Como descrever os argumentos e retornar o resultado?
• Como o cliente vai entender que eu suporte recursos e prompts?
• Que JSON trafega na rede?

Quando você tem um protocolo assim, fica mais fácil:

• escrever servidores em diferentes linguagens (existem SDKs oficiais para TypeScript e Python);
• depurar o app via MCP Inspector ou ferramentas semelhantes;
• dividir responsabilidades entre equipes: uma faz o servidor MCP com dados e ferramentas, outra — o widget no Apps SDK, uma terceira — pode construir seus agentes sobre o mesmo servidor MCP.

7. Uma pequena perspectiva prática: nosso primeiro servidor MCP

Nesta aula, intencionalmente não vamos aos detalhes do formato das mensagens e da implementação do servidor — esse é o material dos próximos tópicos. Mas, para você já entender aonde vamos, é útil ver a estrutura geral de um servidor MCP mínimo em TypeScript.

Na prática, a biblioteca oficial de TypeScript do MCP fornece primitivos para criar o servidor, registrar tools/resources/prompts e iniciar o transporte (geralmente HTTP ou SSE).

Um pseudo‑exemplo pode ficar assim:

// Este é um exemplo conceitual; vamos ver a API do SDK mais adiante
import { createServer } from "@modelcontextprotocol/sdk";

const server = createServer({
  name: "gift-genius",
  version: "1.0.0",
});

// Registramos a ferramenta
server.tool("suggest_gifts", {
  description: "Seleciona presentes de acordo com as preferências do destinatário",
  inputSchema: {/* ... */},
  handler: async (input) => {
    // sua lógica
    return { items: [] };
  },
});

// Iniciamos o transporte (por exemplo, HTTP)
server.listen(3001);

Ponto importante: em nenhum lugar aqui se menciona ChatGPT, Apps SDK ou seu frontend específico. O servidor MCP é autossuficiente. Ele simplesmente sabe responder a requisições MCP. O ChatGPT App é apenas um dos tipos de clientes que podem usar esse servidor.

No curso, vamos nos manter no template Next.js, onde o servidor MCP vive como parte do projeto, mas esse não é o único caminho possível.

8. MCP no ecossistema: Apps SDK, Agents SDK e ACP

Para não enxergar o MCP como “um recurso só do Apps SDK”, é útil vê‑lo em um contexto mais amplo.

Primeiro, o Apps SDK se apoia diretamente no MCP como a ponte padrão entre o ChatGPT e serviços externos. A documentação oficial destaca: o Apps SDK funciona com quaisquer servidores MCP. O próprio protocolo permite descrever ferramentas, retornar dados estruturados e indicar o componente de renderização no UI.

Em segundo lugar, o Agents SDK, que você verá em um módulo separado, também consegue se conectar a servidores MCP. Isso significa que um mesmo servidor MCP com lógica de negócio pode ser usado:

• dentro do ChatGPT como parte do seu App;
• dentro de um agente autônomo que roda, por exemplo, em background do seu produto ou em modo batch.

Em terceiro lugar, o ACP (Agentic Commerce Protocol), de que você vai precisar para compras e Instant Checkout, se baseia logicamente na abordagem do MCP: o modelo e os agentes chamam ferramentas de comércio, também descritas por contratos padronizados.

Assim, o MCP torna‑se o alicerce sobre o qual são construídos o UI (Apps SDK), os cenários de agentes (Agents SDK) e o comércio (ACP). Se você domina o MCP, todo o resto fica mais claro e previsível.

Observação: Formalmente, o ACP não depende do MCP como especificação, mas, na implementação real, as ferramentas do ACP provavelmente serão chamadas pelo modelo por meio de interfaces MCP. Uma abordagem encaixa muito bem na outra, então não deve demorar muito.

9. Pequenos exercícios “mentais” antes da prática

Antes de, na próxima aula, mergulharmos no formato das mensagens do MCP, vale a pena fazer alguns exercícios mentais. Isso ajuda a “mudar” a mentalidade de “REST típico” para “protocolo + contrato”.

Imagine que ao seu Gift‑App querem se conectar não só o ChatGPT, mas também um plugin de IDE para o VS Code e um assistente corporativo interno no Slack. Descreva, em uma frase, o que todos eles precisam saber sobre o seu serviço. Provavelmente a resposta será algo como: “Temos a ferramenta suggest_gifts com tais parâmetros, e um catálogo de presentes disponível por tal recurso”. É isso que o MCP formaliza.

Tente também formular em duas frases:

• o que é o MCP para o produto do seu App (dica: uma forma padrão de “empacotar” funcionalidade para clientes diferentes);
• o que é o MCP para o desenvolvedor (dica: protocolo JSON‑RPC com primitivos claros de tools/resources/prompts).

Se você consegue fazer isso sem hesitar — você já está no meio do caminho para trabalhar com MCP com segurança.

Se resumirmos tudo a um único ponto: o MCP não é “apenas mais uma camada de API”, mas um contrato básico entre sua lógica e os clientes LLM. Nas próximas aulas, vamos olhar dentro do próprio protocolo: analisar o formato das mensagens MCP, handshake/capabilities e aprender a observar o tráfego por meio de inspetores, para que todos esses princípios deixem de ser abstrações e virem ferramentas de trabalho.

10. Erros comuns e equívocos em torno do MCP

Erro nº 1: achar que o MCP é “só mais uma camada de API sobre o meu REST”.
Às vezes surge a tentação: “Já tenho REST, vou só colocar um adaptador fino que transforma chamadas do MCP em REST e vice‑versa, e pronto”. Formalmente dá para fazer, mas você começa a “puxar” peculiaridades do API antigo para dentro do MCP: tipos estranhos, respostas não estruturadas, ausência de schemas explícitos. Com o tempo, o adaptador cresce e o ganho do MCP diminui. É melhor encarar o MCP como o contrato principal e deixar o REST antigo como detalhe interno de implementação, se ele ainda for necessário.

Erro nº 2: pensar que o MCP é “apenas para ChatGPT Apps”.
O MCP é um protocolo aberto e geral para quaisquer clientes LLM: ChatGPT, plugins de IDE, agentes autônomos. Se você projeta um servidor MCP mirando apenas um App, você se limita no futuro. Muito melhor é pensar desde já: “outros clientes também poderão usar este servidor”, e projetar ferramentas e recursos um pouco mais universais.

Erro nº 3: ignorar o JSON Schema e descrever argumentos “em texto livre”.
Mesmo que o SDK permita em algum lugar enviar “qualquer JSON”, não deixe de descrever os schemas de argumentos e resultados. Disso depende diretamente a capacidade do modelo de chamar sua ferramenta corretamente, a qualidade do autocompletar e do discovery, além da facilidade de depuração via inspetores. Argumentos não descritos ou mal descritos levam diretamente a erros enigmáticos de tool‑call.

Erro nº 4: tratar o MCP como “transporte mágico” e não olhar os logs.
Enquanto tudo funciona, parece que o MCP é algo invisível, sobre o qual não é preciso pensar. O problema é que, quando algo quebra, sem entender a estrutura do MCP você vai perder tempo se perguntando: “é o Apps SDK? é o modelo? é meu backend?”. O hábito de olhar para as mensagens e logs do MCP cedo evita horas de tentativas inúteis.

Erro nº 5: tentar projetar um workflow complexo só via REST, ignorando os primitivos do MCP.
Quando aparecem cenários em múltiplas etapas (buscar presente → esclarecer preferências → escolher → finalizar pedido), dá vontade de “fazer um único endpoint REST grandão”. No contexto de ChatGPT Apps, isso frequentemente piora a governabilidade: o modelo entende pior as etapas intermediárias e o cliente MCP perde a possibilidade de reutilizar recursos e prompts. Muito melhor é dividir a funcionalidade em vários tools/resources bem descritos e conectar a lógica com prompts sistêmicos e descrições corretas.