Model Context Protocol (MCP): dos primeiros princípios à produção
Arquitetura, ferramentas, recursos, segurança, integração empresarial e um MCP Server completo em Python
Guia técnico atualizado para a Especificação MCP 2026-07-28, com pesquisa verificada em 23 de agosto de 2026.
Por João Ricardo Dutra••Material completo
Nota de versão. Este guia foi escrito com base na Especificação MCP de 2026-07-28, a especificação vigente no momento da pesquisa. Tutoriais antigos frequentemente ensinam o handshake initialize/initialized, sessões de protocolo, Roots, Sampling, Logging e HTTP+SSE como se ainda fossem atuais. O núcleo de 2026-07-28 não mantém estado: o handshake e a sessão de protocolo foram descontinuados; Roots, Sampling e Logging foram preteridos; Tasks é uma extensão oficial; e Streamable HTTP é o transporte remoto moderno. O comportamento legado continua sendo discutido quando ajuda a compreender clientes e servidores existentes. [2][3]
1. Introdução: o problema de integração que o MCP resolve
Imagine uma empresa de médio porte com CRM, banco de dados relacional, diversas APIs REST internas, Google Drive, GitHub, sistema de tickets e aplicativo de gerenciamento de contatos. Agora imagine que a empresa queira utilizar diversas experiências de IA: um assistente de codificação, um agente de suporte, um assistente de vendas, um assistente de conhecimento interno e um agente de automação.
A ideia óbvia parece simples: deixar que cada IA chame os sistemas de que necessita. A realidade da engenharia é menos simples. Um produto de IA espera um plugin proprietário. Outro espera definições de função JSON incorporadas em cada solicitação de modelo. Um terceiro usa seu próprio conector SDK. Um quarto pode chamar REST diretamente, mas somente depois de construir uma ponte personalizada que traduza a intenção do modelo em solicitações HTTP, lide com a autenticação, transforme as respostas e explique as operações disponíveis para o modelo.
Você acabou de criar uma matriz de integração. Se cinco aplicações de IA precisarem de acesso a dez sistemas de negócios, a superfície conceitual poderá se aproximar de 5 x 10 = 50 relacionamentos de integração. Nem toda célula requer uma base de código distinta, mas cada combinação pode introduzir diferenças na descoberta, formato do esquema, autorização, ciclo de vida, tratamento de erros, empacotamento e configuração específica do produto.
O MCP foi criado para reduzir essa duplicação, padronizando a fronteira entre um aplicativo de IA e recursos externos. Em linguagem simples:
Model Context Protocol é um protocolo aberto por meio do qual aplicativos de IA podem descobrir e interagir com ferramentas, recursos e fluxos de trabalho reutilizáveis expostos por servidores externos.
É por isso que o MCP é frequentemente comparado ao USB-C para integrações de IA. A analogia é útil: um conector comum reduz o número de adaptadores personalizados. Mas está incompleto. USB-C especifica uma interface física e elétrica. O MCP é um protocolo de software, e a interoperabilidade real ainda depende da política de segurança, das versões de protocolo suportadas, das extensões opcionais, do comportamento do host, da qualidade da ferramenta e das escolhas de produtos específicas do fornecedor.
Uma pergunta melhor para realizar este guia é: e se um aplicativo de IA pudesse perguntar a um sistema quais recursos ele expõe, compreender seus esquemas, invocá-los por meio de um protocolo padrão e reutilizar a mesma integração em vários hosts compatíveis?
Esse é o espaço do problema que o MCP aborda.
2. O problema antes do MCP
Antes do MCP, a integração da IA ao sistema geralmente dependia de um ou mais dos seguintes padrões:
Integrações REST personalizadas. Seu aplicativo escreve um código personalizado que chama uma API e depois converte manualmente o resultado no contexto do modelo.
Chamada de função específica do modelo. Você descreve funções no esquema esperado por um provedor de modelo específico e implementa você mesmo o loop de execução.
Plug-ins e conectores proprietários. Um fornecedor define um manifesto, SDK, modelo de pacote ou contrato de mercado.
Integrações específicas do SDK. As estruturas fornecem adaptadores, mas o adaptador geralmente pertence a essa estrutura e não a um protocolo neutro.
Injeção manual de contexto. Um desenvolvedor recupera registros de banco de dados, arquivos ou respostas de API e os coloca diretamente no prompt.
Nenhuma dessas abordagens é inerentemente errada. Uma chamada direta de função pode ser a solução mais limpa para um aplicativo com três operações internas. O problema de dimensionamento aparece quando os recursos precisam ser reutilizados em muitos hosts de IA.
Considere cinco aplicações de IA e dez sistemas empresariais. Sem um protocolo compartilhado, cada consumidor pode precisar aprender como autenticar, descobrir, descrever e ligar para cada provedor. O MCP muda a unidade arquitetônica: em vez de pensar principalmente em termos de "IA A integra-se ao System X", você pode construir um servidor MCP para o System X e permitir que hosts compatíveis o consumam.
Conceitualmente:
Antes de um protocolo compartilhado
IA-1 ---- ponte personalizada ---- CRM
IA-1 ---- ponte personalizada ---- GitHub
IA-2 ---- outra ponte --- CRM
IA-2 ---- outra ponte --- GitHub
...
Com MCP
Hosts de IA ---- MCP ---- CRM Servidor MCP ---- CRM/API
\--- MCP ---- GitHub Servidor MCP - GitHub/API
A promessa é construída uma vez e integrada com vários clientes compatíveis com MCP. A formulação cuidadosa é importante. O MCP não garante que cada cliente ofereça suporte a todos os recursos opcionais, extensões, padrões de autenticação, recursos de UI ou permissões de produto. O protocolo reduz a duplicação de integração; não apaga as diferenças do produto.
3. História do MCP
A Anthropic anunciou o Model Context Protocol em 25 de novembro de 2024 como um padrão aberto para conectar assistentes de IA aos sistemas onde residem dados e ferramentas. A versão inicial incluía a especificação, SDKs, suporte de servidor local no Claude Desktop e exemplos de servidores para serviços como Google Drive, GitHub, Slack, Postgres, Git e automação de navegador. [1]
O momento era importante. A Function Calling já tornou normal que os modelos de linguagem solicitem operações externas, mas cada provedor e estrutura expôs essa ideia de forma diferente. Enquanto isso, as ferramentas para desenvolvedores demonstravam que os modelos de linguagem se tornavam muito mais úteis quando podiam inspecionar repositórios, bancos de dados, arquivos, terminais e contexto específico do projeto. A peça que faltava era um limite de integração reutilizável.
A arquitetura do MCP também evoca um precedente de sucesso nas ferramentas de desenvolvimento: o Language Server Protocol (LSP). O LSP reduziu a necessidade de cada editor implementar integrações personalizadas para cada linguagem de programação. O MCP aborda um domínio diferente, mas a lição arquitetônica é semelhante: um protocolo compartilhado pode separar hosts de provedores de capacidade e permitir que os ecossistemas cresçam de forma independente.
A adoção acelerou durante 2025, à medida que as ferramentas de codificação de IA e as plataformas de agentes adicionaram suporte ao MCP e surgiram milhares de servidores comunitários. O aumento de agentes de IA que utilizam ferramentas tornou a interoperabilidade mais urgente: um agente que consegue raciocinar, mas não consegue chegar de forma fiável aos sistemas empresariais, tem valor operacional limitado.
Um importante marco de governança chegou em 9 de dezembro de 2025, quando o MCP foi contribuído para a Agentic AI Foundation (AAIF) da Linux Foundation, juntamente com outros projetos de Agentic IA. O modelo de base neutra ampliou a participação da indústria enquanto a comunidade mantenedora do MCP deu continuidade à governança técnica. [14] [15]
A maior reformulação do protocolo até agora foi lançada em 28 de julho de 2026. A revisão 2026-07-28 tornou o núcleo sem estado, removeu o handshake de inicialização obrigatório e as sessões de protocolo, introduziu um RPC de servidor/descoberta opcional, adicionou cabeçalhos HTTP e dicas de cache amigáveis ao gateway, extensões formalizadas, moveu tarefas para uma extensão, autorização reforçada e raízes, amostragem, registro e HTTP + SSE legados obsoletos. [2]
A importante lição histórica é que o MCP não está congelado. Se você aprendeu MCP em um tutorial de 2024 ou 2025, parte de seu modelo mental agora é legado. As equipes de produção devem criar versões de suas suposições da mesma forma que fazem versões de um contrato de API.
4. O que o MCP realmente resolve
O MCP substitui adaptadores ponto a ponto repetidos por uma fronteira de protocolo reutilizável.
O MCP resolve principalmente um problema de padronização e interoperabilidade na fronteira entre hosts de IA e capacidades externas.
Isso ajuda na descoberta. Um cliente pode obter um catálogo de ferramentas, recursos e prompts em vez de codificar todos os recursos em um prompt de modelo. Ele ajuda na integração de ferramentas, fornecendo formatos de protocolo previsíveis às operações. Ajuda na integração de contexto, fornecendo aos aplicativos uma maneira padronizada de expor recursos endereçáveis. Ajuda na reutilização porque um servidor MCP pode ser consumido por vários hosts compatíveis. Isso ajuda na separação de preocupações porque o provedor do modelo não precisa conhecer a implementação interna de um CRM, banco de dados, sistema de tickets ou gateway de API.
Para os desenvolvedores, isso reduz o código cola. Para fornecedores de aplicações de IA, isso cria um limite de ecossistema. Para as empresas, permite a governança em torno de servidores e capacidades aprovados. Para equipes de API e plataforma, ele fornece uma fachada controlada para agentes de IA sem substituir as APIs e os serviços já executados por baixo. Para os usuários finais, pode tornar um assistente útil no ambiente onde o trabalho realmente acontece.
O protocolo não resolve a qualidade semântica por si só. Uma ferramenta do_everything mal nomeada ainda é ruim. O MCP não concede acesso automaticamente, decide a política de autorização, interrompe a injeção de prompt, torna seguras as operações destrutivas ou garante que cada modelo escolherá a ferramenta certa. Pense no MCP como uma infraestrutura para expor capacidades, não como um substituto para o design de aplicativos e a engenharia de segurança.
5. Arquitetura MCP: Host, Cliente e Servidor
O host controla a experiência de IA; cada conexão de cliente se comunica com um servidor MCP.
O MCP usa três termos que são fáceis de confundir: Host, Cliente e Servidor.
Um host MCP é o aplicativo de IA com o qual o usuário interage: um agente IDE, um assistente de desktop, um copiloto corporativo ou seu próprio aplicativo. O host possui a experiência do usuário, a orquestração do modelo, as permissões e a política.
Um cliente MCP é o componente de protocolo dentro do host que se comunica com um servidor MCP. Um host pode manter vários relacionamentos cliente-servidor. Na documentação do produto, o cliente pode ficar praticamente invisível porque é uma parte interna do host.
Um servidor MCP expõe recursos. Pode envolver um sistema de arquivos local, um banco de dados, uma API SaaS, uma ferramenta de linha de comando, um serviço interno ou lógica de negócios.
Usuário
|
v
Aplicativo IA / Host MCP
|
v
Cliente MCP
|
| Mensagens MCP (JSON-RPC 2.0)
v
Servidor MCP
|
v
Aplicativo/API/Banco de Dados
Um host pode se conectar a vários servidores:
Assistente / Anfitrião de IA
|
+-- Cliente MCP -> Servidor GitHub MCP
|
+-- Cliente MCP -> Servidor MCP de banco de dados
|
+-- Cliente MCP -> Servidor CRM MCP
|
+-- Cliente MCP -> Contatos Servidor MCP
Isto é importante porque um agente pode potencialmente combinar capacidades. Um usuário pode perguntar: "Encontre o incidente aberto, identifique o proprietário do serviço no diretório e elabore uma atualização". O host pode permitir que o modelo use um servidor de central de serviços, um servidor de diretório interno e um servidor de documentação em um loop de raciocínio.
A distinção host/cliente também é um limite de segurança. O host decide o que o modelo vê e o que pode executar. O servidor anuncia capacidades, mas nunca deve presumir que um cliente aplicará suas dicas corretamente. A validação sensível à segurança também pertence ao lado do servidor.
6. Fundamentos do Protocolo MCP
As mensagens MCP são baseadas em JSON-RPC 2.0, um formato leve de chamada de procedimento remoto. JSON-RPC define solicitações, respostas, notificações, identificadores e formas de erro. O MCP define os métodos e modelos de dados que trafegam dentro desse envelope.
Uma notificação é uma mensagem que não espera resposta. Os erros usam o objeto de erro JSON-RPC. A especificação do protocolo adiciona métodos específicos do MCP, como listar ou chamar ferramentas e ler recursos.
6.1 O núcleo sem estado
É aqui que o MCP atual difere bastante dos tutoriais mais antigos. As revisões anteriores do protocolo usavam uma solicitação de inicialização, uma notificação inicializada, recursos negociados durante um handshake e podiam associar o trabalho HTTP a um Mcp-Session-Id. O núcleo 2026-07-28 removeu aquele handshake obrigatório e sessão em nível de protocolo. Cada solicitação é autodescritiva e carrega metadados de protocolo/cliente; uma chamada opcional de servidor/descoberta permite que um cliente solicite recursos do servidor antes de realizar outro trabalho. [2]
Uma sequência conceitual moderna é, portanto:
O host está configurado com um servidor MCP
|
v
O cliente inicia/conecta-se ao servidor
|
+--> servidor/descoberta opcional
|
+--> ferramentas/lista, recursos/lista, prompts/lista
|
v
O modelo vê as definições de ferramentas selecionadas
|
v
O modelo solicita uma operação
|
v
ferramentas/chamada
|
v
Servidor executa capacidade de negócios
|
v
O resultado da ferramenta retorna ao host
|
v
O host incorpora o resultado no contexto do modelo
Para Streamable HTTP, a nova revisão pode conter cabeçalhos MCP-Protocol-Version, Mcp-Method e, para operações nomeadas, Mcp-Name. Os gateways podem rotear, medir ou aplicar políticas usando cabeçalhos em vez de analisar cada corpo JSON. As respostas de lista/leitura também podem anunciar dicas de cache, como ttlMs e cacheScope. [2]
6.2 O que aconteceu com a negociação de capacidades?
Os recursos ainda são importantes, mas não estão mais vinculados a um handshake de conexão necessário. A identidade e os recursos do cliente podem viajar em metadados de solicitação, enquanto o servidor/descoberta fornece descoberta inicial opcional do servidor. Isso torna o escalonamento horizontal comum muito mais fácil: uma solicitação pode chegar a qualquer instância compatível, em vez de exigir sessões de protocolo fixas.
6.3 Ciclo de vida legado que você ainda encontrará
Se você opera clientes ou servidores em revisões da era 2025, espere o ciclo de vida mais antigo:
Trate-o como um conhecimento de compatibilidade herdado, não como um design a ser copiado para uma nova implementação de 2026.
7. Primitivos MCP: Ferramentas, Recursos e Prompts
As primitivas do servidor expõem ações, contexto, fluxos reutilizáveis e operações demoradas.
O modelo mental mais útil para iniciantes é entender as três primitivas do servidor principal por quem as controla. A documentação atual do Python SDK resume bem a distinção: ferramentas são operações controladas por modelo; os recursos são contexto controlado por aplicativo; prompts são modelos reutilizáveis selecionados pelo usuário. [5][7] [8]
7.1 Ferramentas
Uma ferramenta representa uma operação que o modelo pode invocar. Os exemplos incluem:
• pesquisa_contatos
• criar_contato
• enviar_e-mail
• consulta_banco de dados
• criar_ticket
• get_weather
Uma definição útil de ferramenta informa três coisas ao modelo: como a operação é chamada, o que ela faz e quais argumentos ela espera. Em um SDK de alto nível, as dicas de tipo podem gerar o esquema JSON automaticamente.
Conceitualmente, uma ferramenta pode ser descrita assim:
A descrição não é cosmética. O LLM usa o nome, a descrição, o esquema de entrada, a solicitação do usuário, as instruções do sistema e as alternativas disponíveis para decidir se a ferramenta é relevante. O design da ferramenta é, portanto, em parte design de API e em parte design de interface de modelo.
7.2 Recursos
Um recurso expõe dados que um aplicativo pode ler e colocar no contexto. Os recursos usam URIs ou modelos de URI:
• contatos://todos
• contatos://123
• empresa://políticas/segurança
• banco de dados://esquema/clientes
A principal diferença é a intenção. Uma ferramenta diz: “realize uma operação”. Um recurso diz: “aqui estão informações endereçáveis que podem ser carregadas”. A leitura de contatos://123 não deve excluir, enviar, implantar ou cobrar nada.
Uma regra útil é:
Se o significado principal for ler esta informação, considere um Recurso. Se o significado principal for fazer esta operação, considere uma ferramenta.
Essa regra não é absoluta. Uma ferramenta get_contact ainda pode ser útil porque a pesquisa orientada por modelo pode ser mais simples do que a navegação de recursos em alguns hosts. O MCP oferece opções de modelagem; a resposta certa depende de como a capacidade será consumida.
7.3 Prompts
Um prompt MCP é um modelo de mensagem reutilizável geralmente selecionado pelo usuário por meio da IU do cliente. Está mais próximo de um fluxo de trabalho salvo ou de um comando de barra do que de uma operação do lado do servidor. [8]
Por exemplo, um servidor de Contatos pode expor prepare_follow_up(contact_id, Purpose). O prompt pode fornecer instruções que solicitam ao modelo que leia o contato selecionado, resumir notas anteriores e redigir uma mensagem de acompanhamento concisa. O prompt não envia a mensagem por si só. Contribui com instruções estruturadas para a conversa.
Ferramenta -> o modelo pode escolher uma ação
Recurso -> o aplicativo pode carregar o contexto
Prompt -> o usuário pode escolher um modelo reutilizável
8. Capacidades do lado do cliente e o redesenho do protocolo
Tutoriais de MCP mais antigos geralmente apresentam Roots, Sampling e log do lado do cliente como principais recursos de protocolo.
As raízes permitem que os clientes exponham as raízes do sistema de arquivos ou informações de escopo semelhantes.
A amostragem permite que os servidores solicitem a geração do modelo por meio do cliente.
O registro forneceu mensagens de registro em nível de protocolo.
A partir do MCP 2026-07-28, Roots, Sampling e Logging estão obsoletos. Eles permanecem para uma janela de migração, mas os mantenedores recomendam explicitamente que novas implementações não os adotem. A orientação é modelar o escopo do sistema de arquivos por meio de parâmetros/recursos de ferramentas/configuração de servidor comuns, chamar APIs de provedores de modelo diretamente para comportamento semelhante a amostragem e usar log operacional padrão, como stderr para stdio e observabilidade no estilo OpenTelemetry para serviços implantados. [2][3]
O redesenho do protocolo 2026 também muda a maneira como um servidor pode solicitar informações adicionais ao cliente. Em vez de assumir um canal bidirecional persistente, as solicitações de ida e volta múltiplas (MRTR) permitem que uma operação do servidor retorne um resultado input_required descrevendo o que é necessário. O cliente pode coletar a entrada e tentar novamente a operação original com as respostas anexadas. Isso é mais amigável para infraestrutura HTTP sem estado. [2]
A elicitação - solicitar informações adicionais ao usuário/cliente - portanto, pertence a esse modelo de ida e volta mais recente, em vez de ser considerada como "o servidor pode retornar arbitrariamente ao cliente a qualquer momento". O suporte ainda varia de acordo com o host. Um recurso de protocolo pode existir na especificação enquanto um produto o omite, restringe ou expõe apenas em determinados planos. Sempre distinga a capacidade do protocolo da capacidade do produto.
9. Tarefas e operações de longa duração
Alguns trabalhos não se enquadram confortavelmente em um curto ciclo de solicitação/resposta. Gerar um relatório sobre milhões de linhas, processar milhares de documentos, executar uma implantação ou realizar uma migração grande pode levar minutos ou horas.
O MCP fez experiências com tarefas no núcleo 2025/11/25. Na geração 2026/07/28, Tasks mudou para a extensão oficial io.modelcontextprotocol/tasks. Isto é importante: as tarefas são reais, mas não fazem parte do protocolo central mínimo. Ambos os lados devem apoiar a extensão. [2][4]
Uma tarefa pode ter estes estados: [4]
Significado do status
trabalhando A operação ainda está em execução.
input_required O servidor precisa de entrada adicional do cliente.
concluída A operação foi concluída com sucesso.
falha A execução terminou com um erro JSON-RPC.
O cancelamento foi solicitado/aceito; cancelamento
cancelado
nem sempre pode ser honrado instantaneamente.
A extensão atual usa um modelo de criação direcionado ao servidor. Uma chamada de ferramenta pode retornar um identificador de tarefa; o cliente pode pesquisar tarefas/get, fornecer informações solicitadas por meio de tarefas/atualização e solicitar cancelamento por meio de tarefas/cancelar. O antigo conceito de tarefas/lista foi removido porque é difícil definir o escopo de uma listagem ampla com segurança em uma arquitetura sem estado. [3][4]
A lição de design é mais ampla do que Tarefas: ações de IA de longa duração precisam de um ciclo de vida explícito. “O modelo chamado ferramenta” não é suficiente para representar o progresso, as novas tentativas, a entrada do usuário, o cancelamento ou a semântica do resultado final.
O protocolo define mensagens; o transporte determina como esses bytes se movem entre o cliente e o servidor.
As escolhas modernas são diretas:
Características de melhor ajuste de transporte
Host inicia um processo filho e
se comunica através
stdio Servidores MCP locais
stdin/stdout. Nenhum ouvinte de rede
é necessário.
Características de melhor ajuste de transporte
Endpoint HTTP real, funciona com
TLS, proxies, identidade, gateways,
Servidores MCP HTTP remotos/implantados transmitíveis
balanceadores de carga e horizontais
dimensionamento.
Oficialmente obsoleto; não
Somente compatibilidade com HTTP+SSE legado
escolha para novos sistemas.
O SDK oficial do Python reflete isso diretamente: o padrão mcp.run() é stdio, enquanto
mcp.run(transport="streamable-http", port=3001) expõe /mcp por HTTP. A documentação do SDK rotula explicitamente o SSE como legado e diz para não construir novos sistemas nele. [6]
10.1 Servidor MCP Local
Com stdio, um host como um IDE ou aplicativo de desktop inicia o próprio servidor:
As vantagens incluem baixa sobrecarga de configuração, nenhuma porta de rede exposta e acesso natural ao contexto de desenvolvimento local. Os riscos incluem a execução arbitrária de código local: a instalação de um servidor MCP aleatório é operacionalmente semelhante à instalação de qualquer outro pacote não confiável.
10.2 Servidor MCP Remoto
Um servidor remoto é executado por trás da infraestrutura HTTP:
Anfitrião de IA
|
HTTPS
v
Balanceador de carga/gateway
|
v
Instâncias do servidor MCP
|
v
APIs/dados de negócios
A implantação remota apresenta TLS, DNS, OAuth, política de rede, limites de taxa, multilocação, observabilidade e escalabilidade. O núcleo 2026 sem estado torna esse modelo operacional muito mais limpo porque as solicitações de protocolo não dependem mais de uma sessão MCP persistente.
11. MCP vs API REST: o MCP está substituindo as APIs?
Não. MCP e REST geralmente resolvem diferentes camadas do problema.
Uma API REST é uma interface de software para recursos e operações via HTTP. Muitas vezes é o limite durável de integração de negócios usado por aplicativos web, aplicativos móveis, parceiros, serviços e automação. MCP é um protocolo de interoperabilidade voltado para IA que pode expor recursos selecionados de uma forma que os hosts de IA possam descobrir e invocar.
Um servidor MCP pode chamar internamente uma API REST:
Isso significa que uma empresa não precisa substituir suas APIs para adotar o MCP. Na verdade, uma organização madura pode preservar o ciclo de vida da API, a segurança, a limitação de taxa, os contratos e a observabilidade existentes, ao mesmo tempo em que adiciona uma camada MCP que traduz ferramentas amigáveis ao agente em chamadas de API controladas.
REST continua útil para integração determinística de software para software. O MCP adiciona capacidade de descoberta e descrições de capacidade orientadas para IA. Os dois são complementares.
12. MCP vs Function Calling
A Function Calling geralmente é um recurso de uma API de modelo: você fornece esquemas de função/ferramenta ao modelo, ele retorna uma solicitação estruturada para chamar um, seu aplicativo o executa e você envia o resultado de volta.
O MCP padroniza como um host de IA se conecta a um provedor de capacidade externo que pode publicar ferramentas, recursos, prompts e extensões.
Função de dimensão chamando MCP
Geralmente definido por um
Propriedade Protocolo/ecossistema aberto
API de modelo/provedor
O aplicativo normalmente fornece esquemas no servidor expõe catálogos por meio de
Descoberta
cada método de protocolo de integração
stdio ou Streamable HTTP (mais
Solicitação/resposta da API do provedor de transporte
compatibilidade legada)
Muitas vezes vinculado a um Projetado para reutilização em
Reutilizar
hosts compatíveis com integração de aplicativo/provedor
Interoperabilidade host-servidor mais
Modelo de escopo escolhe chamadas estruturadas
primitivos/extensões
Esquema específico do provedor e padrão de protocolo, com
Dependência do fornecedor
comportamento específico do host do loop de execução ainda é possível
Eles podem coexistir. Um host pode usar internamente uma Function Calling nativa de um modelo para decidir que search_contacts deve ser executado, enquanto o recurso real é descoberto e executado por meio do MCP.
Uma separação mental clara é: A Function Calling ajuda um modelo a expressar uma chamada de ferramenta pretendida. O MCP ajuda um aplicativo a descobrir e executar recursos expostos por servidores externos.
13. MCP vs Plugins e Conectores Proprietários
Plugins e conectores proprietários geralmente são contratos específicos de produtos. Eles podem definir formatos de manifesto, fluxos de autenticação, mercados, regras de empacotamento ou SDKs que funcionam extremamente bem dentro do ecossistema de um fornecedor.
A vantagem de interoperabilidade do MCP é que a definição de capacidade do lado do servidor pertence a um protocolo aberto. O mesmo servidor MCP de contatos pode ser potencialmente consumido por um assistente de desktop, um agente IDE, um copiloto corporativo ou seu próprio host sem reescrever o adaptador de negócios para cada produto.
Isso não elimina camadas proprietárias. Um produto pode empacotar servidores MCP em seu próprio formato de extensão, impor um processo de aprovação de mercado, expor apenas um subconjunto de primitivos ou adicionar políticas específicas da organização. O MCP padroniza o modelo de fio e capacidade, não toda experiência de produto circundante.
14. Como uma IA escolhe uma ferramenta MCP
A descoberta é apenas metade da história. Depois que um cliente possui ferramentas, o host decide quais definições de ferramentas disponibilizar para o modelo. O modelo então escolhe entre eles com base em vários sinais:
1. Nome da ferramenta. search_contacts é mais fácil de corresponder a uma solicitação de pesquisa do que contact_op.
2. Descrição. Uma frase clara explica a intenção e os limites. 3. Esquema de entrada. Os nomes e as descrições dos parâmetros informam ao modelo quais informações são necessárias. 4. Solicitação do usuário. “Encontrar Maria” aponta para a pesquisa, enquanto “adicionar Maria” aponta para a criação. 5. Instruções do sistema/desenvolvedor. O host pode proibir gravações, exigir confirmação ou especificar fluxos de trabalho. 6. Alternativas disponíveis. A sobreposição de ferramentas aumenta a ambiguidade. 7. Raciocínio modelo. O modelo estima qual ação melhor avança a tarefa.
Para "Qual Maria da Contoso tem um número de celular que termina em 77?", search_contacts é semanticamente forte porque pode filtrar. Para "Abrir o registro completo do contato 41", get_contact é mais preciso. Para "Remover contato de teste 99", delete_contact é a operação perigosa com efeitos colaterais e deve estar sujeita a uma política mais rigorosa.
O design inadequado da ferramenta aumenta a probabilidade de erro. Uma ferramenta chamada manage_contact(action, payload) força o modelo a compreender um miniprotocolo adicional dentro de um esquema. Ferramentas explícitas reduzem a ambiguidade e fornecem aos hosts controles de permissão mais granulares.
15. Como projetar boas ferramentas MCP
Boas ferramentas MCP parecem boas APIs, mas com atenção extra em como os modelos de linguagem interpretam as descrições.
15.1 Use nomes explícitos e responsabilidades restritas
a menos que a operação genérica seja genuinamente a capacidade do domínio.
15.2 Escreva descrições como contratos comportamentais
Uma descrição útil indica o que a ferramenta faz, limites importantes e o que ela não faz quando há probabilidade de ambiguidade.
Ruim:
"Lida com contatos." Melhorar:
"Pesquise contatos por nome parcial, e-mail, telefone ou empresa. Somente leitura. Retorna no máximo 50 correspondências e não modifica registros de contato."
15.3 Torne os esquemas previsíveis
Use tipos fortes, enumerações limitadas, campos obrigatórios explícitos, comprimentos máximos razoáveis e identificadores específicos de domínio. Evite blobs gigantes de formato livre se campos estruturados estiverem disponíveis.
15.4 Retornar resultados estruturados
As máquinas consomem estrutura de forma mais confiável do que a prosa. Retorna objetos de contato com campos estáveis em vez de um parágrafo que o modelo deve analisar novamente.
15.5 Valide tudo do lado do servidor
Os argumentos gerados pelo modelo são entradas não confiáveis. Valide identificadores, comprimentos, valores enum, regras de negócios, autorização e propriedade de recursos exatamente como faria para uma API pública.
15.6 Projetar para idempotência sempre que possível
O comportamento de nova tentativa é mais fácil quando repetir uma operação é seguro. Uma leitura é naturalmente idempotente.
update_contact(id=7, phone="...") pode ser idempotente. create_contact geralmente não é, a menos que você use uma chave de idempotência ou uma regra de exclusividade natural.
15.7 Separar leituras de gravações
Isso oferece suporte a políticas granulares. Um host pode permitir search_contacts sem permitir delete_contact.
15.8 Trate as anotações como dicas, não como controles
O Python SDK pode expor anotações como read_only_hint, destructive_hint, idempotent_hint e open_world_hint. Estas podem ajudar clientes bem-comportados a decidir se a confirmação é apropriada, mas não são medidas de segurança. [7]
16. Projeto Prático: Aplicação de Gerenciamento de Contatos com Servidor MCP
Construiremos um sistema deliberadamente pequeno que tornará cada camada visível.
Cada contato possui:
• id
• name
• email
• phone
• company
• notes
SQLite fornece persistência local. Python é uma boa opção porque o MCP Python SDK v2 oficial oferece suporte à especificação 2026-07-28 e expõe uma API MCPServer de alto nível. No momento em que este artigo foi escrito, o SDK requer Python 3.10+ e pode ser instalado com uv add "mcp[cli]" ou pip install "mcp[cli]". [5]
Nosso objetivo de design é importante: o aplicativo de contato deve funcionar sem MCP. O MCP é um adaptador de recursos de negócios, não o local onde reside a lógica de negócios.
Disposição do projeto:
contacts-mcp/
├── pyproject.toml
├── contacts_service.py
├── server.py
└── contacts.db # created at runtime
17. Arquitetura de aplicativo de contato
O MCP permanece como um adaptador sobre lógica de negócio e persistência reutilizáveis.
Assistente / Anfitrião de IA
|
v
Cliente MCP
|
v
Contatos Servidor MCP <- adaptador de protocolo
|
v
ContactService <-- operações de negócios/dados
|
v
SQLite
IA Assistant/Host possui o modelo e a interação do usuário. O cliente MCP fala o protocolo. O Servidor MCP de Contatos mapeia ferramentas/recursos/prompts MCP para recursos do aplicativo. ContactService sabe como os contatos são armazenados e validados. SQLite persiste os registros.
Essa separação torna o serviço reutilizável. Posteriormente, você poderia expor o mesmo ContactService por meio de uma API REST, uma CLI, testes ou um trabalho em segundo plano sem importar o código MCP para a camada de domínio.
18. Crie o serviço de contato antes do MCP
Create contacts_service.py :
from __future__ import annotations
import sqlite3
from pathlib import Path
from typing import Any
class ContactService:
def __init__(self, db_path: str = "contacts.db") -> None:
self.db_path = Path(db_path)
self._initialize()
def _connect(self) -> sqlite3.Connection:
connection = sqlite3.connect(self.db_path)
connection.row_factory = sqlite3.Row
return connection
def _initialize(self) -> None:
with self._connect() as db:
db.execute(
"""
CREATE TABLE IF NOT EXISTS contacts (
id INTEGER PRIMARY KEY AUTOINCREMENT,
name TEXT NOT NULL,
email TEXT,
phone TEXT,
company TEXT,
notes TEXT
)
"""
)
@staticmethod
def _row_to_dict(row: sqlite3.Row | None) -> dict[str, Any] | None:
return dict(row) if row is not None else None
def create_contact(
self,
name: str,
email: str | None = None,
phone: str | None = None,
company: str | None = None,
notes: str | None = None,
) -> dict[str, Any]:
name = name.strip()
if not name:
raise ValueError("name must not be empty")
with self._connect() as db:
cursor = db.execute(
"""
INSERT INTO contacts(name, email, phone, company, notes)
VALUES (?, ?, ?, ?, ?)
""",
(name, email, phone, company, notes),
)
contact_id = int(cursor.lastrowid)
contact = self.get_contact(contact_id)
assert contact is not None
return contact
def get_contact(self, contact_id: int) -> dict[str, Any] | None:
with self._connect() as db:
row = db.execute(
"SELECT * FROM contacts WHERE id = ?", (contact_id,)
).fetchone()
return self._row_to_dict(row)
def list_contacts(self, limit: int = 50) -> list[dict[str, Any]]:
limit = max(1, min(limit, 200))
with self._connect() as db:
rows = db.execute(
"SELECT * FROM contacts ORDER BY name LIMIT ?", (limit,)
).fetchall()
return [dict(row) for row in rows]
Continue o mesmo arquivo:
def search_contacts(
self, query: str, limit: int = 20
) -> list[dict[str, Any]]:
query = query.strip()
if not query:
return []
limit = max(1, min(limit, 50))
pattern = f"%{query}%"
with self._connect() as db:
rows = db.execute(
"""
SELECT *
FROM contacts
WHERE name LIKE ?
OR email LIKE ?
OR phone LIKE ?
OR company LIKE ?
ORDER BY name
LIMIT ?
""",
(pattern, pattern, pattern, pattern, limit),
).fetchall()
return [dict(row) for row in rows]
def update_contact(
self,
contact_id: int,
name: str | None = None,
email: str | None = None,
phone: str | None = None,
company: str | None = None,
notes: str | None = None,
) -> dict[str, Any]:
current = self.get_contact(contact_id)
if current is None:
raise LookupError(f"contact {contact_id} not found")
values = {
"name": current["name"] if name is None else name.strip(),
"email": current["email"] if email is None else email,
"phone": current["phone"] if phone is None else phone,
"company": current["company"] if company is None else company,
"notes": current["notes"] if notes is None else notes,
}
if not values["name"]:
raise ValueError("name must not be empty")
with self._connect() as db:
db.execute(
"""
UPDATE contacts
SET name = ?, email = ?, phone = ?, company = ?, notes = ?
WHERE id = ?
""",
(*values.values(), contact_id),
)
updated = self.get_contact(contact_id)
assert updated is not None
return updated
def delete_contact(self, contact_id: int) -> bool:
with self._connect() as db:
cursor = db.execute(
"DELETE FROM contacts WHERE id = ?", (contact_id,)
)
return cursor.rowcount > 0
Observe o que está faltando: importações do MCP. Isso é intencional. Os testes de unidade para esta classe não precisam de um modelo, cliente de protocolo ou host de IA.
19. Crie o servidor MCP
Agora crie server.py. O Python SDK de alto nível gera esquemas a partir de dicas de tipo e descrições de docstrings. [5][7]
from __future__ import annotations
import json
from typing import Any
from mcp.server import MCPServer
from mcp.types import ToolAnnotations
from contacts_service import ContactService
service = ContactService("contacts.db")
mcp = MCPServer("Contacts")
@mcp.tool(
annotations=ToolAnnotations(
read_only_hint=True,
open_world_hint=False,
)
)
def list_contacts(limit: int = 50) -> list[dict[str, Any]]:
"""List contacts alphabetically. Read-only. Maximum 200 records."""
return service.list_contacts(limit)
@mcp.tool(
annotations=ToolAnnotations(
read_only_hint=True,
open_world_hint=False,
)
)
def search_contacts(query: str, limit: int = 20) -> list[dict[str, Any]]:
"""Search contacts by partial name, email, phone, or company. Read-only."""
return service.search_contacts(query, limit)
@mcp.tool(
annotations=ToolAnnotations(
read_only_hint=True,
open_world_hint=False,
)
)
def get_contact(contact_id: int) -> dict[str, Any]:
"""Get one contact by numeric ID. Read-only."""
contact = service.get_contact(contact_id)
if contact is None:
raise ValueError(f"contact {contact_id} not found")
return contact
Essas seis ferramentas expõem capacidades pequenas e explícitas. Seus contratos efetivos são:
Ferramenta Finalidade Entrada principal Saída Erros típicos
limites inválidos
list_contacts Procurar registros limita matriz de contatos
manuseado/fixado
Localizar por consulta parcialmente vazia ->
consulta search_contacts, limite de correspondências
campos vazios resultado
get_contact Buscar registro exato contact_id objeto de contato não encontrado
nome inválido /
create_contact Inserir registro campos de contato objeto criado
regra de domínio
Ferramenta Finalidade Entrada principal Saída Erros típicos
Modificar existente não encontrado/inválido
update_contact id + campos opcionais objeto atualizado
campo de registro
política/
delete_contact Remover registro contact_id status de exclusão autorização/não
encontrado
Em um servidor de produção, substitua ValueError genérico por erros deliberados de protocolo/aplicativo e mapeie falhas de domínio de forma consistente. Imponha também identidade e autorização dentro da operação, não apenas por meio de anotações.
20. Adicionar recursos MCP
Adicione dois recursos ao server.py:
@mcp.resource("contacts://all")
def contacts_resource() -> str:
"""A JSON snapshot of the first 200 contacts."""
return json.dumps(
service.list_contacts(200),
ensure_ascii=False,
indent=2,
)
@mcp.resource("contacts://{contact_id}")
def contact_resource(contact_id: int) -> str:
"""One contact as JSON, addressed by contact ID."""
contact = service.get_contact(contact_id)
if contact is None:
raise ValueError(f"contact {contact_id} not found")
return json.dumps(contact, ensure_ascii=False, indent=2)
Por que modelá-los como Recursos quando as ferramentas list_contacts e get_contact já existem? Ensinar a distinção semântica. Um host pode carregar contatos://42 como contexto porque o URI identifica informações. A versão da ferramenta é útil quando o modelo deve decidir ativamente procurar algo durante um ciclo de raciocínio.
Em um sistema maior, os Recursos tornam-se especialmente naturais para políticas, esquemas, configuração, documentação, arquivos ou outro material que o aplicativo possa anexar ao contexto.
21. Adicione um prompt MCP
Adicione um prompt selecionável pelo usuário:
@mcp.prompt()
def prepare_follow_up(contact_id: int, purpose: str = "general follow-up") -> str:
"""Prepare a concise follow-up plan for a contact."""
return f"""
Prepare a professional follow-up for contact ID {contact_id}.
Purpose: {purpose}.
First retrieve the contact. Use any notes as context. Do not invent missing facts.
Faça um rascunho da mensagem, mas não envie nada automaticamente.
""".tira()
Este prompt difere de uma ferramenta porque não executa a ação comercial. O usuário escolhe um fluxo de trabalho reutilizável que passa a fazer parte da conversa. O host/modelo pode então decidir se uma ferramenta de leitura é necessária.
Finish server.py :
if __name__ == "__main__":
mcp.run()
Neste ponto, o mesmo arquivo expõe ferramentas, recursos e um prompt por meio do stdio.
22. Execute e inspecione o servidor MCP localmente
Crie um projeto e instale o SDK oficial:
mkdir contacts-mcp
cd contacts-mcp
uv init
uv add "mcp[cli]"
Coloque contatos_service.py e server.py no diretório e inicie o inspetor de desenvolvimento:
uv run mcp dev server.py
O Python SDK oficial usa o MCP Inspector para desenvolvimento interativo. O comando imprime um URL. O Inspetor pode enumerar ferramentas, recursos e prompts e permite invocá-los sem primeiro integrar um host de produção. Requer npx /Node.js na máquina de desenvolvimento. [5]
Uma boa sequência de teste é:
1. Chame create_contact para "Maria Silva".
2. Chame search_contacts com query="Maria".
3. Leia contatos://todos.
4. Renderize o prompt prepare_follow_up.
5. Chame update_contact no novo ID.
6. Chame delete_contact e observe a anotação destrutiva nos metadados da ferramenta.
Para uma execução direta de stdio:
uv run mcp run server.py
Ou simplesmente execute o arquivo se o seu ambiente já estiver ativado:
python server.py
Importante: com stdio, não escreva texto de depuração em stdout porque stdout carrega mensagens de protocolo. Use stderr ou um coletor de registro real.
Para expor o mesmo servidor por HTTP, altere a linha final para:
if __name__ == "__main__":
mcp.run(transport="streamable-http", port=3001)
O SDK atende o endpoint MCP em http://127.0.0.1:3001/mcp por padrão. [6]
23. Conecte o servidor a clientes reais de IA
A configuração do produto muda mais rapidamente que o protocolo. Os exemplos abaixo foram verificados em relação à documentação do fornecedor disponível em 23 de agosto de 2026. Trate a disponibilidade do plano do produto e os rótulos da IU como sensíveis ao tempo.
23.1 Claude Desktop
O Python SDK pode instalar um servidor local na configuração do Claude Desktop:
uv run mcp install server.py
Em um nível inferior, a configuração local do MCP geralmente mapeia um nome de servidor para um comando e argumentos. Uma entrada conceitual se parece com:
O Claude Desktop atual também fornece extensões de desktop (.mcpb) como uma experiência de empacotamento/distribuição para servidores MCP locais. Geralmente, esse é um caminho de instalação melhor para o usuário final do que pedir a não desenvolvedores que editem o JSON manualmente. Os controles administrativos podem restringir extensões permitidas em espaços de trabalho gerenciados. [17]
23.2 Claude Code
Claude Code oferece suporte a servidores stdio locais e HTTP remotos. Um exemplo local:
claude mcp add --transport stdio contacts -- \
uv run --with "mcp[cli]" mcp run /absolute/path/to/server.py
Um exemplo remoto:
claude mcp add --transport http contacts https://contacts.example.com/mcp
A configuração do MCP no escopo do projeto também pode residir em.mcp.json. O comando claude mcp list ajuda a verificar o que está configurado. [18]
23.3 ChatGPT
A partir de 23 de agosto de 2026, a experiência MCP personalizada do ChatGPT está centrada em servidores MCP remotos por meio da funcionalidade de desenvolvedor/aplicativo personalizado, com disponibilidade dependendo do plano e dos controles do espaço de trabalho. Os documentos da OpenAI expandiram o suporte completo ao MCP em beta para espaços de trabalho Business e Enterprise/Edu, enquanto alguns recursos do modo de desenvolvedor para planos individuais são mais limitados. Os administradores podem controlar a publicação e as permissões. ChatGPT não trata um processo stdio local arbitrário em seu laptop como um conector remoto diretamente acessível; é necessário um endpoint acessível pela rede ou um mecanismo de desenvolvimento/túnel seguro suportado. [19]
Conceitualmente, o fluxo é:
ChatGPT
|
| aplicativo/conector MCP personalizado registrado
v
https://contacts.example.com/mcp
|
v
Servidor MCP de contatos
Para ferramentas de gravação, espere uma confirmação e uma política de espaço de trabalho mais fortes do que para ferramentas de pesquisa/busca somente leitura. As restrições do produto evoluem, portanto, verifique as configurações atuais da Central de Ajuda e do espaço de trabalho antes de projetar uma implementação.
23.4 OpenAI Responses API
A API OpenAI Responses pode expor servidores MCP remotos a um modelo como uma ferramenta MCP. Um exemplo mínimo é:
from openai import OpenAI
client = OpenAI()
response = client.responses.create(
model="gpt-5.4",
input="Find Maria Silva's phone number in my contacts.",
tools=[
{
"type": "mcp",
"server_label": "contacts",
"server_url": "https://contacts.example.com/mcp",
"allowed_tools": ["search_contacts", "get_contact"],
"require_approval": "never"
}
],
)
print(response.output_text)
O fluxo é:
Sua aplicação
|
API/modelo de respostas OpenAI
|
Ferramenta MCP Remota
|
Servidor MCP de contatos
|
SQLite ou back-end corporativo
Para um servidor com capacidade de gravação, não copie cegamente a política permissiva de aprovação somente leitura. Restrinja as ferramentas permitidas, exija a aprovação apropriada para efeitos colaterais e faça com que o servidor autorize cada operação de forma independente. Os dados do servidor MCP são tratados por esse endpoint de terceiros de acordo com suas próprias práticas de retenção e segurança. [20]
23.5 Visual Studio Code / GitHub Copilot
O código VS atual usa configuração no estilo mcp.json. Uma configuração de espaço de trabalho pode ser semelhante a:
Dependendo do escopo, isso pode estar em.vscode/mcp.json ou na configuração MCP no nível do usuário. O VS Code descobre ferramentas de servidor e as disponibiliza para experiências de agentes de acordo com a política do usuário/espaço de trabalho. Os ambientes gerenciados do GitHub Copilot podem aplicar políticas da organização. [21][22]
23.6 Microsoft Copilot Studio
O Microsoft Copilot Studio pode incorporar servidores MCP em agentes quando a orquestração generativa estiver habilitada. A documentação atual do produto expõe especificamente ferramentas e recursos do MCP; o suporte ao produto não deve ser considerado igual a cada primitiva ou extensão de protocolo. As alterações no servidor podem ser refletidas dinamicamente sem reconstruir um esquema de ação proprietário para cada ferramenta. [23]
23.7 Gemini CLI e outros hosts
Gemini CLI oferece suporte a entradas de servidor MCP em settings.json. Um exemplo local é conceitualmente:
Configurações HTTP remotas também são suportadas. Outros hosts MCP amplamente utilizados incluem o Cursor e diversas estruturas de agentes. A lição não é a lista de produtos; é que o mesmo modelo de capacidade do lado do servidor pode ser reutilizado em hosts com diferentes camadas de configuração e política. [24]
24. Teste o servidor de contatos por meio de linguagem natural
O protocolo se torna tangível quando você segue uma solicitação do usuário de ponta a ponta.
Exemplo A: "Encontre o número de telefone de John Smith."
Solicitação do usuário
-> O modelo decide que uma pesquisa é necessária
-> Ferramenta selecionada: search_contacts
-> Argumentos: {"query": "John Smith", "limit": 20}
-> Cliente MCP envia ferramentas/chamada
-> Contatos do servidor MCP chama ContactService
-> SQLite retorna linhas correspondentes
-> O resultado da ferramenta retorna dados de contato estruturados
-> O modelo responde com o número de telefone, citando ambiguidade se vários Johns corresponderem
Exemplo B: "Adicionar Maria Silva aos meus contatos. O e-mail dela é maria@example.com."
O modelo deve escolher create_contact com argumentos estruturados:
O host pode solicitar confirmação porque se trata de uma gravação. O servidor ainda valida a entrada e a autorização do chamador.
Exemplo C: "Quais contatos funcionam para a Contoso?"
Um modelo pode chamar:
{"query": "Contoso", "limit": 20}
O servidor retorna correspondências cuja empresa/nome/e-mail/telefone contém o termo. Um servidor de produção mais sofisticado pode expor search_contacts(company=...) para que a semântica seja explícita.
Exemplo D: "Alterar o número de telefone do John."
Esta solicitação estará incompleta se existir mais de um John. Um agente seguro deve pesquisar primeiro, desambiguar se necessário e depois chamar update_contact com o ID selecionado. A orquestração de ferramentas não envolve apenas invocação; trata-se de gerenciar a incerteza antes dos efeitos colaterais.
Exemplo E: "Exclua o contato de teste que criei anteriormente."
Isso combina a memória da conversa com uma ação destrutiva. O anfitrião deve identificar o registro pretendido e confirmar se a política exige isso. O servidor deverá rejeitar a exclusão se o chamador não estiver autorizado, mesmo que o modelo esteja confiante.
25. Implantando um servidor MCP remoto
Um servidor remoto é a mesma camada de capacidade colocada por trás da infraestrutura HTTP de produção. Você não precisa de uma arquitetura exótica.
Internet/Rede Corporativa
|
HTTPS
|
Proxy reverso/gateway API
|
+------+------+
| |
Instância MCP Instância MCP
| |
+------+------+
|
Contate o serviço/APIs
|
Banco de dados
Para o exemplo Python, você pode expor um aplicativo Starlette/ASGI do SDK e executá-lo na infraestrutura ASGI padrão ou usar o executor Streamable HTTP integrado do SDK. [6]
Uma lista de verificação de produção inclui:
Use um domínio real e um certificado TLS.
Coloque segredos em um gerenciador de segredos ou ambiente protegido, não no controle de origem.
Autentique clientes e autorize ações.
Use um proxy reverso/gateway de API quando melhorar a política, a limitação de taxa, o registro em log ou o roteamento.
Conteinerize se for adequado à sua plataforma; não conteinerize apenas porque o MCP é novo.
Escale horizontalmente onde a carga de trabalho exigir. O núcleo 2026 sem estado torna o roteamento round-robin natural.
Centralize logs, métricas, rastreamentos e eventos de auditoria.
Aplique tempos limite e tamanhos de resposta limitados.
O design deve permanecer enfadonho no melhor sentido: MCP é um protocolo de aplicação executado em práticas de infraestrutura que você já conhece.
26. Autenticação e Autorização MCP
O stdio local e o HTTP remoto têm modelos de ameaças diferentes. Um servidor local pode herdar permissões de identidade e sistema de arquivos do ambiente de processo. Um servidor remoto pode ser acessado através de uma rede e precisa de decisões explícitas de identidade, token, escopo e autorização.
O modelo de autorização HTTP do MCP se alinha às convenções modernas do OAuth. Em um fluxo típico de recursos protegidos:
Cliente MCP
|
| 1. solicitar endpoint MCP protegido
v
Servidor de recursos MCP
|
| 2. 401 + informações de descoberta
v
Metadados de recursos protegidos (RFC 9728)
|
| aponta para servidor(es) de autorização
v
Servidor de autorização
|
| 3. autorizações de usuário/cliente, código + fluxo PKCE
| 4. solicitação de token, validação do emissor, vinculação de recurso
v
Token de acesso
|
| 5. Autorização: Portador <token>
v
Servidor de recursos MCP
O servidor pode publicar metadados de recursos protegidos em um terminal conhecido. O SDK Python atual documenta uma rota como /.well-known/oauth-protected-resource/mcp, que identifica o recurso MCP protegido, servidores de autorização, escopos suportados e método de token de portador. [9]
26.1 Postura de segurança estilo OAuth 2.1
Use fluxos de código de autorização com PKCE para clientes interativos, tokens de acesso de curta duração, TLS, validação de redirecionamento exato e vinculação de escopo/recurso. O servidor deve tratar o token de acesso como prova de autoridade delegada, e não como uma permissão geral para fazer tudo.
26.2 Indicadores de recursos
Um token deve ser destinado ao recurso MCP ao qual é apresentado. Os indicadores de recursos reduzem a confusão de tokens ao vincular a autorização a um recurso protegido específico, em vez de criar um token Bearer para todos os fins.
26.3 Metadados de recursos protegidos
Em vez de exigir conhecimento fora de banda de cada terminal de autorização, o recurso MCP pode publicar metadados legíveis por máquina que informam ao cliente onde ocorre a autorização e quais escopos existem.
26.4 Validação do emissor
A revisão 2026-07-28 requer um tratamento mais rigoroso do emissor do servidor de autorização: os clientes validam o valor iss de acordo com RFC 9207 antes de resgatar um código de autorização. Isso atenua ataques de confusão entre servidores de autorização. [2]
26.5 CIMD substitui DCR como direção de deslocamento
O Registro Dinâmico de Cliente (DCR) foi amplamente utilizado em exemplos anteriores do MCP OAuth. A revisão 2026-07-28 descontinua o DCR em favor dos Documentos de Metadados de ID do Cliente (CIMD). Com o CIMD, um cliente publica metadados em uma URL HTTPS estável e pode usar essa URL como seu identificador de cliente quando o servidor de autorização oferece suporte ao mecanismo. O DCR continua sendo um caminho de compatibilidade com versões anteriores para servidores que não migraram. [2][10]
26.6 A autorização ainda é específica da aplicação
OAuth responde "quem/o que está chamando e quais escopos delegados foram concedidos?" Seu serviço comercial ainda deve responder a perguntas como:
Este funcionário pode ler o contato 123?
Esta conta de serviço pode excluir contatos?
Este inquilino tem permissão para ver o registro desta empresa?
Contacts:write inclui exclusão destrutiva ou apenas atualização?
O MCP não substitui a autorização de domínio.
27. Segurança MCP
A segurança em produção combina identidade, privilégio mínimo, validação, isolamento, aprovações e observabilidade.
Um servidor MCP faz parte dos limites de segurança do seu aplicativo porque pode expor dados confidenciais e ações poderosas. Trate-o como uma API mais uma camada semântica voltada para o agente.
27.1 Injeção de prompt e injeção indireta de prompt
Um modelo pode consumir texto não confiável de documentos, sites, e-mails, rastreadores de problemas ou recursos MCP. Esse texto pode conter instruções que tentam substituir a intenção do usuário ou causar chamadas de ferramenta. O ataque se torna indireto quando a instrução hostil reside dentro do conteúdo recuperado, e não no prompt do usuário.
As defesas incluem separar conteúdo não confiável de instruções privilegiadas, minimizar ferramentas de gravação disponíveis, exigir confirmação para ações confidenciais, restringir ferramentas permitidas por fluxo de trabalho e validar políticas do lado do servidor independentemente do raciocínio do modelo.
27.2 Servidores maliciosos e envenenamento de ferramentas
Um servidor controla as descrições de suas ferramentas e o conteúdo retornado. Um servidor malicioso pode anunciar descrições enganosas, retornar instruções direcionadas ao modelo ou tentar induzir chamadas para outros recursos. Instale ou conecte-se apenas a servidores de fontes confiáveis. Trate a instalação de servidores comunitários como uma instalação de software na cadeia de fornecimento, e não como adicionar um site aos favoritos.
27.3 Permissões excessivas
Não conceda permissão ao Servidor MCP de Contatos para todo o diretório corporativo se o caso de uso exigir apenas registros de uma equipe de vendas. Prefira o menor privilégio em todas as camadas: escopos OAuth, concessões de banco de dados, contas de serviço, listas de permissões de ferramentas, acesso ao sistema de arquivos e saída de rede.
27.4 Exfiltração de dados e vazamento de credenciais
Uma ferramenta que pode ler segredos e uma ferramenta que pode enviar solicitações HTTP arbitrárias é uma composição perigosa. Os segredos não devem ser devolvidos ao modelo. Proteja o acesso de saída à rede quando apropriado. Edite credenciais de logs e resultados de ferramentas. Nunca armazene tokens de acesso em descrições de ferramentas, prompts ou configurações controladas pela origem.
27.5 Chamadas destrutivas
search_contacts apresenta um risco relativamente baixo. delete_contact não é. Use controles em camadas:
marcar comportamento destrutivo em metadados para que os clientes possam apresentar uma UX mais segura;
exigem aprovação humana quando a política assim o exige;
autorizar exclusão no lado do servidor;
registre quem excluiu o quê e por quê;
use janelas de exclusão reversível ou recuperação quando o domínio as suportar;
operações destrutivas com limite de taxa.
27.6 Problema do agente confuso (confused deputy)
Um servidor pode se tornar um substituto confuso quando possui credenciais poderosas e executa uma ação para um chamador que não deveria ter essa autoridade. Vincule a identidade do chamador às verificações de autorização; não deixe que a conta de serviço ampla do próprio servidor se torne uma permissão implícita.
27.7 SSRF e ferramentas de mundo aberto
Ferramentas que buscam URLs arbitrários podem criar riscos de falsificação de solicitação no lado do servidor (SSRF). Restrinja esquemas, destinos, intervalos de endereços privados, redirecionamentos e comportamento de DNS. Se a ferramenta não precisar de Internet aberta, torne o acesso de saída fechado por padrão.
27.8 Validação de entrada e saída
As entradas de um modelo não são confiáveis. As saídas dos sistemas upstream também podem não ser confiáveis. Valide ambas as direções. Aplique limites de tamanho de saída para evitar que uma chamada MCP despeje centenas de megabytes em um contexto de modelo.
27.9 Pilha de controle prática
Uma linha de base de segurança do MCP de produção deve incluir:
autenticação e autorização explícita;
escopos de privilégio mínimo e identidades de serviço;
registro ou lista de permissões de servidores aprovados;
listas de permissões em nível de ferramenta;
confirmação para gravações de alto impacto;
sandbox para execução local/não confiável sempre que possível;
gestão secreta;
validação de solicitação e resposta;
limites de taxa, cotas e tempos limite;
registros de auditoria;
varredura de dependência e cadeia de suprimentos;
monitoramento de padrões anômalos de invocação de ferramentas.
28. MCP em ambientes empresariais
O MCP torna-se especialmente interessante quando uma organização possui muitos sistemas existentes e muitas experiências de IA.
Assistente de IA empresarial
|
Camada MCP
|
+------+------+------+------+
| | | | |
API CRM GW DB Documentos DevOps
MCP MCP MCP MCP MCP
Um servidor CRM pode expor a pesquisa de contas. Um servidor API Gateway pode expor o catálogo da API e os metadados operacionais. Um servidor de banco de dados pode expor consultas analíticas limitadas. Um servidor de documentação pode expor padrões internos. Um servidor DevOps pode expor operações de construção ou implantação com controles de aprovação rígidos.
As empresas devem evitar um ecossistema do oeste selvagem, onde cada funcionário executa servidores arbitrários com credenciais de produção. Padrões de governança úteis incluem:
registro central MCP de servidores aprovados;
editores verificados e fixação de versão;
integração do provedor de identidade;
controle de acesso baseado em funções (RBAC);
taxonomia de escopo OAuth padrão;
políticas de rede e controles de saída;
listas de permissões de ferramentas por pessoa/fluxo de trabalho;
retenção de auditoria;
propriedade de dependências e SLAs de patch;
testes de compatibilidade de versão de protocolo.
O MCP também introduziu uma extensão de autorização gerenciada pela empresa (EMA) em 2026. O EMA visa o acesso ao servidor provisionado centralmente e integrado à identidade, para que os usuários corporativos possam receber conexões MCP aprovadas sem repetir a configuração ad-hoc do OAuth para cada servidor. Trate-o como uma extensão que requer suporte compatível com o ecossistema, e não como parte do núcleo mínimo. [16]
29. Gateways MCP e API
As organizações com gerenciamento de API maduro não devem ignorá-lo apenas porque quem chama é um agente de IA.
Um padrão empresarial comum é:
Agente de IA
|
Cliente MCP
|
Servidor MCP Corporativo
|
Gateway de API
|
APIs internas
|
Microsserviços
A camada MCP traduz ferramentas voltadas para IA em operações de API existentes. O gateway de API continua a fornecer autenticação de API, autorização, limitação de taxa, roteamento, proteção contra ameaças, análises e aplicação de políticas.
O protocolo 2026-07-28 melhora esse ajuste para gateways. Solicitações Streamable HTTP podem expor informações de métodos/ferramentas por meio de cabeçalhos Mcp-Method e Mcp-Name, permitindo decisões de roteamento ou medição sem inspeção profunda dos corpos de solicitação JSON. [2]
Essa arquitetura é útil quando a organização deseja uma ponte governada entre os recursos do agente e seu patrimônio de API existente. Também evita que o servidor MCP se torne uma plataforma de integração paralela que duplica silenciosamente tudo o que o gateway já faz bem.
30. Observabilidade e Operações
Um servidor MCP de produção precisa de observabilidade de serviço comum, além de semântica em nível de ferramenta.
Capture métricas como:
contagem de solicitações e taxa de erros pelo método MCP;
contagem de invocação de ferramenta por nome de ferramenta;
latência da ferramenta p50/p95/p99;
latência de API/banco de dados upstream;
falhas de autorização;
eventos de limite de taxa;
taxas de cancelamento e falha de tarefas;
tamanhos de resposta e contribuição de contexto;
contagens de novas tentativas e taxas de tempo limite.
Para rastreamento, propague um identificador de correlação/rastreamento da solicitação HTTP por meio do servidor MCP para APIs downstream. Uma chamada de ferramenta que envolve CRM, faturamento e banco de dados deve ser rastreável como uma operação.
Os logs de auditoria para ações de gravação devem responder: quem iniciou a operação, por qual host/cliente, qual ferramenta foi executada, qual registro de destino foi alterado, qual política permitiu isso e qual foi o resultado.
Não registre tokens de acesso, senhas, cabeçalhos secretos completos ou registros confidenciais inteiros por padrão. O registro deve ser útil sem se tornar uma violação secundária de dados.
Para servidores stdio locais, lembre-se de que stdout pertence ao protocolo. Envie logs operacionais para stderr ou um coletor de arquivo/telemetria.
31. Erros comuns de desenvolvimento de MCP
31.1 Criando ferramentas excessivamente genéricas
manage_everything(action, payload) torna o comportamento do modelo mais difícil de prever e as permissões mais difíceis de definir o escopo. Divida as responsabilidades onde o domínio suportar.
31.2 Expondo muitas ferramentas
Mais ferramentas podem significar mais confusão, maior contexto e pior seleção de ferramentas. Exponha os recursos necessários para o fluxo de trabalho atual, não para toda a empresa.
31.3 Escrevendo descrições vagas
As descrições fazem parte da interface do modelo. Indique a finalidade, os limites, os efeitos colaterais e as pré-condições importantes.
31.4 Retornando contexto enorme
Não retorne uma tabela de banco de dados inteira porque o modelo fez uma pergunta. Paginar, filtrar, resumir deterministicamente e expor recursos com leituras limitadas.
31.5 Colocando segredos em arquivos de configuração
Use gerenciamento de segredos específico do ambiente. A configuração do desenvolvedor local deve fazer referência a segredos em vez de incorporar credenciais de produção de longa duração.
31.6 Conceder acesso de gravação quando a leitura for suficiente
Separe servidores/ferramentas somente leitura da capacidade de mutação quando for prático. O menor privilégio reduz os acidentes e o impacto da injeção.
31.7 Confiando em servidores comunitários arbitrários
Fonte de auditoria, origem do pacote, dependências, permissões e comportamento da rede. Um servidor MCP local é um código executável.
31.8 Combinando código de protocolo com lógica de negócios
Mantenha o MCP como um adaptador. Isso melhora os testes, a portabilidade e a revisão de segurança.
31.9 Ignorando erros de ferramenta
Retorne erros deliberados com semântica estável. O host/modelo precisa distinguir não encontrado, validação, autorização, conflito, falha transitória upstream e falha permanente.
31.10 Confiando em argumentos gerados por modelo
Nunca presuma que um esquema estruturado torna os dados seguros. Valide as regras de autorização e domínio após a análise.
32. Desempenho do MCP e gerenciamento de contexto
O design do servidor MCP é parcialmente um design de sistemas distribuídos e parcialmente um design de contexto LLM.
Cada descrição de ferramenta que o modelo vê consome tokens. Esquemas JSON grandes consomem mais. Grandes resultados de recursos consomem contexto. As chamadas de rede adicionam latência. As cadeias de ferramentas multiplicam as viagens de ida e volta.
Isso leva a vários princípios de engenharia:
Mantenha os catálogos de ferramentas relevantes para o usuário/fluxo de trabalho atual.
Prefira descrições concisas que permaneçam inequívocas.
Esquemas vinculados e tamanhos de resposta.
Paginar os resultados da pesquisa.
Retorne os campos estruturados que o modelo realmente precisa.
Armazene os resultados da descoberta/lista em cache de acordo com as dicas do servidor onde o host oferece suporte.
Evite colocar cargas textuais binárias ou enormes diretamente no contexto do modelo.
Meça a qualidade da seleção de ferramentas à medida que o catálogo cresce.
As dicas de cache do protocolo 2026 nas respostas de lista/leitura são projetadas em parte para reduzir o trabalho repetido de descoberta e estabilizar o cache de prompt upstream. [2]
Um antipadrão comum é expor 300 ferramentas quase sobrepostas em cada conversa. O protocolo pode tecnicamente transportá-los; isso não significa que o modelo raciocinará sobre eles de forma eficiente.
33. Quando o MCP faz sentido
O MCP é uma escolha forte quando a reutilização e a interoperabilidade são requisitos reais. Os exemplos incluem:
um assistente interno de IA que precisa de acesso a CRM, documentos, tickets e APIs;
uma ferramenta de desenvolvedor que deve funcionar em vários IDEs/agentes compatíveis com MCP;
um assistente de banco de dados cujas capacidades de consulta devem ser reutilizáveis entre hosts;
uma plataforma de agente empresarial com provedores de capacidade governados;
um produto SaaS que deseja expor recursos amigáveis para agentes a vários ecossistemas de IA;
uma ferramenta de desenvolvedor local que se beneficia do empacotamento stdio e da descoberta automática.
Uma questão de decisão útil é: esse recurso será consumido por mais de um host de IA ou desejo a opção de trocar de host sem reconstruir o contrato de integração? Se sim, o MCP merece séria consideração.
34. Quando o MCP pode ser desnecessário
O MCP não é uma camada obrigatória para toda integração de modelo.
Uma chamada REST direta pode ser mais simples quando seu aplicativo já sabe exatamente qual endpoint chamar e nenhuma seleção controlada por modelo é necessária. A Function Calling tradicional pode ser suficiente quando um aplicativo possui cinco funções privadas e nenhuma interoperabilidade é necessária. Um SDK de provedor pode ser ideal quando você precisa de recursos exclusivos desse provedor. Um pequeno adaptador interno pode ser mais barato do que operar um servidor MCP reutilizável.
Perguntar:
1. A descoberta é útil ou já conheço a única operação? 2. Vários hosts consumirão esse recurso? 3. Preciso de recursos ou prompts ou apenas de um esquema de função? 4. A execução de outro servidor/processo melhora a modularidade o suficiente para justificar a superfície operacional? 5. O host de destino é realmente compatível com os recursos do MCP de que preciso?
Use o MCP quando ele reduzir a complexidade no nível do sistema, não porque esteja na moda.
35. O Futuro do MCP
Os fatos atuais e a direção futura devem ser cuidadosamente separados.
Fatos atuais em 2026: MCP tem um núcleo sem estado, transportes Stdio e Streamable HTTP, ferramentas/recursos/prompts, uma estrutura de extensões, tarefas como uma extensão, aplicativos MCP como uma extensão para interface de usuário interativa fornecida pelo servidor e trabalho de autorização empresarial como EMA. Os principais fornecedores de IA e ferramentas de desenvolvedor participam do ecossistema. [2][14]
Direção do roteiro: o roteiro dos mantenedores do MCP de agosto de 2026 destaca o trabalho contínuo em primitivas de mensagens de agente, proteção de transporte nativo HTTP, identidade do agente e segurança corporativa, primitivas mais ricas e experiência de SDK/desenvolvedor. Um roteiro é uma intenção, não uma garantia de que um recurso já esteja padronizado ou enviado. [25]
Um efeito provável a longo prazo é organizacional: as aplicações podem publicar cada vez mais superfícies de capacidade voltadas para o agente juntamente com APIs tradicionais. As APIs continuam sendo o contrato de software; O MCP pode se tornar uma camada padronizada de consumo de agentes que descreve o que uma IA pode descobrir e fazer.
Os aplicativos MCP também apontam para interações mais ricas do que as chamadas de ferramentas invisíveis. Um servidor pode associar uma ferramenta à UI HTML em área restrita que hosts compatíveis podem renderizar. Isso estende o MCP de “funções de chamada” para “trazer capacidade interativa para o host”, enquanto mantém o suporte à UI opcional e dependente do host. [2]
A ideia maior não é que o MCP seja o único protocolo de agente para sempre. É que os ecossistemas de IA se tornam mais úteis quando as ferramentas não ficam presas ao formato de integração personalizado de um fornecedor.
36. Modelo Mental Final
Se você se lembra de apenas uma frase, use isto:
As APIs expõem capacidades ao software; O MCP expõe capacidades de forma padronizada para aplicações e agentes de IA.
É uma simplificação excessiva porque os servidores MCP geralmente chamam APIs subjacentes, porque a Function Calling ainda pode ser usada dentro de um host e porque os recursos/prompts/extensões vão além de uma simples fachada de API. Mas é um ponto de partida útil.
Então lembre-se das peças:
Host: o aplicativo de IA e a experiência do usuário.
Cliente: o componente de protocolo dentro do host que se comunica com um servidor.
Servidor: o provedor de capacidade.
Ferramentas: operações invocáveis por modelo.
Recursos: contexto endereçável que a aplicação pode ler.
Prompts: modelos de mensagens reutilizáveis selecionados pelo usuário.
Transportes: estúdio no local; Streamable HTTP remotamente.
Autorização: identidade e acesso delegado para servidores remotos protegidos; ainda apoiado por autorização de domínio.
Extensões: recursos opcionais, como tarefas, aplicativos MCP e autorização gerenciada pela empresa.
E para a geração atual de protocolos, lembre-se de mais uma coisa: o MCP moderno é essencialmente sem estado. Não construa uma nova arquitetura 2026 em torno do antigo ciclo de vida obrigatório de inicialização/sessão.
37. Conclusão
Começamos com uma empresa que tinha muitas aplicações de IA e muitos sistemas. Sem um limite de integração compartilhado, cada combinação pode se tornar um adaptador personalizado com seus próprios esquemas, autenticação, descoberta e ciclo de vida.
MCP altera a unidade de integração. Um CRM, banco de dados, plataforma de desenvolvedor, sistema de contato ou API interna pode expor um servidor MCP. Hosts compatíveis podem descobrir suas ferramentas, ler seus recursos, usar seus prompts e invocar recursos por meio de um protocolo padrão. Isso não elimina a configuração específica do produto ou a política de segurança, mas reduz a necessidade de reinventar o contrato básico de host para capacidade.
Você também viu que o MCP é mais do que “ferramentas de chamada de LLMs”. Sua arquitetura separa Host, Cliente e Servidor. JSON-RPC fornece o envelope da mensagem. As ferramentas representam operações, os recursos representam o contexto endereçável e os prompts representam fluxos de trabalho reutilizáveis do usuário. stdio se adapta a servidores locais; Streamable HTTP se adapta a sistemas implantados. A autorização orientada a OAuth protege servidores remotos. As extensões lidam com questões como tarefas de longa duração e interface de usuário mais rica. E implantações maduras ainda dependem de gateways de API, identidade, privilégio mínimo, observabilidade, validação e aprovação humana.
Mais importante ainda, o exemplo de Contatos demonstra por que as camadas existem. O serviço comercial não conhece o MCP. O servidor MCP não precisa ser proprietário do modelo de banco de dados. O host não precisa entender SQLite. O modelo vê apenas capacidades descritas no nível semântico correto.
O potencial do MCP é significativo precisamente porque não tenta substituir todas as camadas. É um limite padrão entre os aplicativos de IA e os recursos externos de que necessitam. Suas limitações são igualmente importantes: a interoperabilidade varia, a seleção da ferramenta do modelo pode falhar, os recursos do protocolo evoluem e a exposição de ações aos agentes expande a superfície de segurança.
O futuro mais interessante pode ser aquele em que as aplicações publiquem duas interfaces intencionais: APIs para integração de software determinística e capacidades padronizadas voltadas para agentes para sistemas de IA. Se esse futuro chegar de forma ampla, a questão não será mais apenas “Esta aplicação tem uma API?” Também será: “O que um agente autorizado de IA pode descobrir e fazer aqui com segurança?”
38. Referências e leituras adicionais
As fontes abaixo priorizam especificações oficiais, documentação do projeto, documentação do fornecedor e anúncios de fundação. As páginas específicas do produto mudam com frequência; verifique-os novamente antes da implantação da produção.
1. Anthropic. "Apresentando o Model Context Protocol." 25 de novembro de 2024. https://www.anthropic.com/news/model-context-protocol 2. Mantenedores do Model Context Protocol. "A especificação 2026-07-28." 28 de julho de 2026. https://blog.modelcontextprotocol.io/posts/2026-07-28/ 3. Mantenedores do Model Context Protocol. "Candidato ao lançamento da especificação MCP 2026-07-28." 21 de maio de 2026. https://blog.modelcontextprotocol.io/posts/2026-07-28-release-candidate/ 4. Extensão de tarefas MCP. "Visão geral" e extensão de tarefas SEP-2663. https://tasks.extensions.modelcontextprotocol.io/ 5. MCP Python SDK v2. Introdução/primeiros passos. https://py.sdk.modelcontextprotocol.io/ 6. MCP Python SDK v2. Executando seu servidor/transportes. https://py.sdk.modelcontextprotocol.io/run/ 7. MCP Python SDK v2. Ferramentas e anotações de ferramentas. https://py.sdk.modelcontextprotocol.io/servers/tools/ 8. MCP Python SDK v2. Recursos e solicitações. https://py.sdk.modelcontextprotocol.io/servers/resources/ e https://py.sdk.modelcontextprotocol.io/servers/prompts/ 9. MCP Python SDK v2. Autorização e metadados de recursos protegidos. https://py.sdk.modelcontextprotocol.io/run/authorization/ 10. MCP Python SDK v2. Clientes OAuth e documentos de metadados de ID do cliente. https://py.sdk.modelcontextprotocol.io/client/oauth-clients/ 11. Especificação do Model Context Protocol. Especificação atual e documentação de protocolo. https://modelcontextprotocol.io/ 12. MCP Python SDK. Documentação do servidor de baixo nível. https://py.sdk.modelcontextprotocol.io/v2/advanced/low-level-server/ 13. MCP TypeScript SDK v2. Migração/suporte para 28/07/2026. https://ts.sdk.modelcontextprotocol.io/v2/ 14. Fundação Linux. Anúncio da Agentic AI Foundation (AAIF), 9 de dezembro de 2025. https://www.linuxfoundation.org/press/linux-foundation-launches-the-agentic-ai-foundation 15. Anthropic. Anúncio de contribuição/governação do MCP para AAIF. Dezembro de 2025. https://www.anthropic.com/news/model-context-protocol-joins-aaif 16. Blog do Model Context Protocol. "Autorização gerenciada pela empresa: OAuth sem toque para MCP." 18 de junho de 2026. https://blog.modelcontextprotocol.io/ 17. Centro de Ajuda Anthropic. Servidores MCP locais e extensões de desktop para Claude Desktop. https://support.anthropic.com/ 18. Documentação do Claude Code. Conecte o Claude Code às ferramentas via MCP. https://docs.anthropic.com/en/docs/claude-code/mcp 19. Centro de Ajuda OpenAI. "Modo de desenvolvedor e aplicativos MCP no ChatGPT (Beta)." https://help.openai.com/en/articles/12584461-developer-mode-and-mcp-apps-in-chatgpt-beta 20. Documentação da API OpenAI. OpenAI Responses API e ferramentas MCP. https://developers.openai.com/api/reference/ e https://developers.openai.com/ 21. Visual Studio Code. Servidores MCP no VS Code. https://code.visualstudio.com/docs/copilot/chat/mcp-servers 22. Documentos GitHub. Estendendo o GitHub Copilot com MCP. https://docs.github.com/en/copilot/customizing-copilot/extending-copilot-chat-with-mcp 23. Microsoft Learn. Protocolo de contexto de modelo no Microsoft Copilot Studio. https://learn.microsoft.com/en-us/microsoft-copilot-studio/agent-extend-action-mcp 24. Documentação da CLI do Gemini. Configuração do servidor MCP. https://github.com/google-gemini/gemini-cli/blob/main/docs/tools/mcp-server.md 25. Blog do Model Context Protocol. Roteiro 2026, publicado em 22 de agosto de 2026. https://blog.modelcontextprotocol.io/
Apêndice A - Referência rápida atual versus herdada
Recomendação atual (2026-
Legado do tópico/nota de compatibilidade
07-28)
Revisões mais antigas usadas
Solicitação/resposta apátrida do estado principal
estado de inicialização/sessão
inicializar/inicializado comum em
Inicialização Não há handshake de inicialização obrigatório
Tutoriais de 2025
Negociação de capacidade mais antiga
Descoberta de servidor Servidor/descoberta opcional
aconteceu na inicialização
Recomendação atual (2026-
Legado do tópico/nota de compatibilidade
07-28)
Estúdio de transporte local Ainda atual
Transporte remoto Streamable HTTP HTTP+SSE obsoleto
io.modelcontextprotocol/tasks Tarefas principais experimentais existiam em
Tarefas
extensão 2025-11-25
Roots obsoletos permanecem durante a janela de migração
Prefira APIs diretas de provedor de modelo
Amostragem obsoleta
para novos designs
Log primitivo Obsoleto Prefere logs/telemetria padrão
CIMD é preferido onde
Direção obsoleta do DCR
suportado
O suporte do host da extensão oficial dos aplicativos MCP varia
Autorização gerenciada empresarial Extensão oficial O suporte do ecossistema varia
Apêndice B - Lista de verificação de prontidão para produção
Protocolo e compatibilidade
☐ Fixe e documente a revisão do protocolo MCP que você suporta.
☐ Teste em pelo menos dois hosts pretendidos quando a meta for a interoperabilidade.
☐ Separe os requisitos básicos das extensões opcionais.
☐ Não dependa de primitivas obsoletas para um novo design sem motivo de migração.
Projeto de ferramenta
☐ As ferramentas têm nomes explícitos e responsabilidades restritas.
☐ As descrições indicam efeitos colaterais e limites importantes.
☐ As entradas usam esquemas limitados e validação do lado do servidor.
☐ Os resultados são estruturados e limitados em tamanho.
☐ Os recursos de leitura e gravação são separáveis.
Segurança
☐ A autenticação e a autorização de domínio são aplicadas no lado do servidor.
☐ Os escopos OAuth seguem o menor privilégio.
☐ As operações destrutivas têm controlos mais rigorosos.
☐ Os segredos nunca inserem resultados visíveis do modelo ou logs comuns.
☐ O acesso à rede de saída é restrito quando o acesso aberto à Internet é desnecessário.
☐ Servidores MCP de terceiros são revisados como dependências de software executável.
Operações
☐ As chamadas de ferramentas possuem métricas de latência/erro.
☐ Gravações confidenciais produzem eventos de auditoria.
☐ Tempos limite, novas tentativas e limites de taxa são definidos.
☐ Os IDs de rastreamento se propagam para APIs downstream.
☐ Resultados grandes são paginados ou limitados.
☐ Os procedimentos de atualização abrangem revisões de SDK e protocolo.
