Docker MCP Gateway e alternativas: quando usar e quanto custa

Docker MCP Gateway e outras opções de gateway fazem sentido quando você precisa aplicar regras de acesso comuns a vários clientes de IA. Seis desenvolvedores usando quatro clientes com oito servidores MCP podem gerar 192 entradas de configuração entre clientes e servidores. O valor está em ter um único lugar para controlar o acesso e investigar chamadas de ferramentas, com alguém responsável pelos custos de operação.

O que um gateway MCP faz?

Um gateway MCP é um ponto de controle entre agentes e servidores MCP para autenticação, listas de ferramentas permitidas, logs e limites de chamadas. Model Context Protocol, ou MCP, é a interface comum pela qual uma aplicação de IA descobre ferramentas e solicita que elas executem ações. O gateway centraliza a gestão dessas conexões. Os controles disponíveis variam conforme a implementação. A explicação da Kong sobre gateways descreve esse papel de proxy e aplicação de políticas.

Imagine um assistente de operações que consulta os dados de um cliente e depois atualiza um chamado de suporte. Os servidores MCP disponibilizam essas ações. Cabe ao gateway identificar quem está fazendo a chamada, quais ações essa identidade pode executar e o que aconteceu durante a execução.

Para desenvolvedores que usam Claude, ChatGPT, Codex e Cursor, a vantagem é manter um acesso consistente às ferramentas nos clientes aprovados pela organização. Ainda é preciso verificar, em cada cliente, o plano contratado, o suporte à autenticação e os métodos de conexão.

Cada controle tem uma função:

• Autenticação: identificar a pessoa ou a carga de trabalho que faz a solicitação. A autorização define o que essa identidade pode fazer. Uma chave de API compartilhada pode impedir que se atribua cada ação a uma pessoa.
• Listas de ferramentas permitidas: disponibilizar e autorizar um conjunto definido de ações. Um assistente de suporte pode ter permissão para consultar um cliente e ser impedido de usar uma ferramenta de exclusão. A regra precisa valer tanto na listagem das ferramentas quanto na execução das chamadas.
• Logs: registrar quem agiu, qual servidor e ferramenta foram usados, a decisão da política e o resultado necessário para investigar uma ação. Defina quais argumentos podem ser registrados e como os valores sensíveis serão tratados.
• Limites de chamadas: limitar o uso por identidade, ferramenta ou serviço de destino, conforme o que precisa ser protegido. Um agente que repete chamadas deve esbarrar em um limite controlado antes de sobrecarregar um sistema de backend.

Esses são requisitos a verificar. A palavra gateway não garante que todos venham no produto. Um agregador local de ferramentas pode ser útil e ainda deixar a integração de identidades da organização ou os limites de chamadas por sua conta.

Qual é a diferença entre gateway MCP e servidor MCP?

Um servidor MCP fornece recursos; um gateway MCP controla o acesso a um ou mais servidores. O servidor pode disponibilizar uma consulta ao banco de dados ou uma ação de criação de chamado. O gateway apresenta aos clientes os recursos aprovados, encaminha as chamadas e aplica os controles configurados.

Na arquitetura do MCP, o cliente descobre ferramentas com tools/list e as aciona com tools/call. Um gateway pode atuar como servidor para o agente e como cliente dos servidores de destino. A aplicação por trás da integração continua decidindo quais registros quem faz a chamada pode ler ou alterar.

Por exemplo, permitir uma ferramenta de atualização de chamados não significa dar acesso à conta de todos os clientes. As permissões por registro e a separação entre tenants continuam sob responsabilidade da aplicação e de sua integração com o servidor.

O que muda em relação a um gateway de IA ou de LLM?

Um gateway de IA ou de LLM, sigla para modelo de linguagem de grande porte, controla solicitações a modelos. Um gateway MCP controla solicitações a ferramentas. Essa diferença define o problema que cada um pode resolver.

A documentação do Cloudflare AI Gateway descreve logs de solicitações a modelos, cache, limites de chamadas, novas tentativas e alternativas em caso de falha. Esses controles ajudam a gerenciar o custo de inferência e a confiabilidade dos provedores. Já a política de ferramentas de um gateway MCP pode decidir se um agente tem permissão para executar uma ação aprovada em um sistema de clientes.

Alguns produtos cobrem os dois fluxos. Avalie cada um separadamente: um orçamento para modelos não comprova uma permissão de ferramenta, e uma lista de ferramentas permitidas não limita todas as solicitações a modelos. Consulte a comparação de gateways de IA para agentes de programação quando o problema que justifica o investimento for roteamento de modelos, gastos com inferência ou falhas de provedores.

Um gateway de API convencional também pode autenticar e limitar solicitações HTTP. A governança que entende MCP acrescenta o significado do conteúdo dessas solicitações: descoberta de ferramentas, nomes das ferramentas e argumentos das chamadas. Várias ações podem compartilhar a mesma URL /mcp. Por isso, uma regra que apenas libera essa URL pode conceder um acesso muito mais amplo do que a política de ferramentas pretendida.

O que mudou em 24 de setembro de 2026?

A Cloudflare tornou o MCP Server Portals disponível para todos os clientes da Cloudflare em 24 de setembro de 2026. O anúncio oficial descreve um único endpoint para servidores aprovados e logs do Access para atividades de ferramentas, prompts e recursos.

O lançamento também inclui autenticação por token de serviço para agentes autônomos, roteamento pelo Gateway para logs HTTP mais detalhados e prevenção contra perda de dados, além de suporte ao Logpush para exportar atividades. A prevenção contra perda de dados, ou DLP, inspeciona o conteúdo segundo regras para informações sensíveis.

A mudança duradoura é ter uma opção gerenciada para centralizar o acesso remoto ao MCP sem operar o processo do gateway por conta própria. A disponibilidade ainda deixa duas decisões: verificar se seus servidores e clientes são compatíveis e se o plano inclui os recursos de auditoria necessários.

Gateways MCP já existiam como padrão de arquitetura. Esse lançamento muda a disponibilidade de uma opção gerenciada; ele não torna um gateway obrigatório para toda conexão MCP.

Quando uma equipe pequena precisa de um gateway MCP?

Você precisa de um gateway quando as decisões de acesso têm de continuar valendo mesmo com mudanças de cliente, funcionário ou responsável pelo servidor. Ter mais do que alguns servidores é um sinal de atenção, mas a fragmentação das políticas é o motivo mais forte para agir.

Considere a adoção quando o mesmo desenvolvedor usa vários clientes e todos precisam das mesmas ferramentas com acesso restrito. O mesmo vale quando a operação precisa revogar acessos, reconstituir uma ação ou aplicar uma política comum a ferramentas sensíveis ou capazes de alterar dados. Um ambiente pequeno com uma ação de escrita de alto impacto pode justificar esse trabalho antes de uma grande coleção de ferramentas de documentação pública.

Imagine um ambiente com seis desenvolvedores, quatro clientes de agentes e oito servidores MCP, em que cada desenvolvedor configura todos os servidores em todos os clientes:

• Configuração direta: 6 × 4 × 8 = 192 entradas entre clientes e servidores.
• Um gateway compartilhado: 6 × 4 = 24 entradas entre clientes e gateway, mais 8 definições de endpoints de destino.
• Total de referências a endpoints: 32.

Essa é uma conta de configuração feita para o exemplo, não uma implantação observada nem um resultado de desempenho. Talvez você já distribua as configurações de forma centralizada, e funções diferentes podem exigir gateways ou perfis diferentes. As concessões OAuth nos serviços de destino, ou seja, as autorizações que cada usuário dá a um serviço, também continuam separadas das definições de endpoints.

O ganho é poder mudar o endereço de um servidor aprovado ou uma política de ferramentas em um ponto central. Também é possível cometer um erro nesse ponto central. Versione a política e defina quem pode alterá-la.

Espere quando um responsável já consegue administrar um conjunto pequeno de ferramentas de baixo risco com os controles de identidade e a configuração compartilhada existentes. Um gateway acrescenta outro serviço, outra dependência e outra possibilidade de falha. Ele precisa resolver um problema operacional definido.

Nada muda para você se seus agentes não usam ferramentas MCP. Se a necessidade é apenas controlar solicitações a modelos, comece pela decisão sobre um gateway para LLMs. Se a aplicação já aplica a política de ferramentas e fornece a trilha de auditoria necessárias, acrescente um gateway apenas quando ele melhorar esse controle.

O que avaliar no desenvolvimento, na operação e na compra

Desenvolvimento: comece pelo transporte

Escolha um gateway capaz de alcançar os servidores que você opera. stdio significa que um cliente se comunica com um processo local pelos fluxos de entrada e saída. Streamable HTTP transporta o tráfego MCP até um endpoint remoto. A arquitetura do protocolo descreve os dois.

Um gateway remoto gerenciado não consegue iniciar automaticamente um processo stdio no seu notebook. Transformar esse processo em um serviço HTTP hospedado exige trabalho de implantação e gestão de credenciais. Confirme a compatibilidade de transporte antes de substituir as configurações dos clientes.

Operação: controle o caminho real das chamadas

Uma política comum só ajuda quando as chamadas relevantes passam por ela. Faça um inventário das credenciais e dos endpoints diretos junto com as conexões do gateway. Defina como os clientes aprovados chegam às ferramentas, onde os incidentes ficam registrados e quem cuida da recuperação se o gateway falhar.

Em um fluxo de suporte, a evidência útil é a identidade e a ação que alterou um chamado. Um log de conexão bem-sucedida, sozinho, não responde a essa pergunta. Verifique os registros produzidos pelo produto escolhido, sem presumir que todo recurso de logs fornece as mesmas evidências.

Compra: pague pelo controle de que você precisa

Inclua no orçamento o gateway, os servidores de destino e a pessoa responsável por ambos. Um plano Free pode atender ao número de usuários e não atender ao requisito de retenção. Um software de código aberto pode atender à implantação e ainda exigir integração adicional de identidades.

Se a necessidade passar a incluir descoberta de servidores não aprovados, inspeção detalhada durante a execução ou resposta a incidentes corporativos, a comparação de plataformas de segurança MCP cobre essa contratação mais ampla.

Três opções de gateway MCP, verificadas em 4 de outubro de 2026

Cloudflare atende ao controle gerenciado de acesso remoto; Docker, à operação de servidores em contêineres; Lasso, à orquestração baseada em plugins. A escolha depende do transporte, dos controles de acesso, dos logs e de quem opera o serviço.

Os preços e as licenças abaixo foram verificados nas páginas públicas e nos repositórios dos próprios fornecedores em 4 de outubro de 2026. Os cenários de custo apresentados adiante são cálculos com premissas explícitas.

Fontes: planos da Cloudflare, licença do Docker e licença da Lasso.

Cloudflare MCP Server Portals

Cloudflare MCP Server Portals é a opção gerenciada para servidores MCP remotos aprovados quando o Cloudflare One atende aos seus requisitos de identidade e operação. Ele reúne servidores em um único endpoint HTTP, usa o Cloudflare Access para autenticação e permite aos administradores escolher quais ferramentas e prompts ficam disponíveis no portal.

A tabela de planos vigente apresenta o Free por $0, com limite de 50 usuários, o Pay-as-you-go por $7 por usuário/mês e um plano Contract com preço anual personalizado por usuário. A retenção padrão dos logs é de até 24 horas no Free e de até 30 dias no Pay-as-you-go; o prazo depende do serviço utilizado.

Os limites estão na compatibilidade e no acesso aos recursos de auditoria. A documentação dos portais da Cloudflare oferece suporte a servidores MCP HTTP remotos, com até 80 servidores por portal. Um servidor que só usa stdio precisa primeiro ser hospedado atrás de um endpoint HTTP autenticado. Alguns servidores de destino rejeitam clientes que se conectam por proxy.

Os logs do portal e a exportação externa dos logs também são contratações diferentes: a integração Logpush da Cloudflare é exclusiva do Enterprise. Confira essa habilitação antes de prometer um arquivo externo à auditoria.

Escolha essa opção para ferramentas remotas compatíveis quando você quer um ponto de controle compartilhado sem administrar a infraestrutura de execução do gateway. Leia O Cloudflare MCP Portals é gratuito? para entender os custos separados de usuários, hospedagem e auditoria.

Docker MCP Gateway

Docker MCP Gateway é a opção de código aberto quando operar os servidores MCP faz parte do problema. Ele inicia servidores em contêineres isolados, gerencia seu ciclo de vida, cuida de credenciais e roteamento e agrupa os servidores disponíveis em perfis. Um perfil é um conjunto salvo de servidores disponibilizado a um cliente.

O código do gateway independente usa a licença MIT. O Docker documenta a instalação manual com Docker Engine, além do caminho pelo Docker Desktop. O host, as atualizações, as credenciais e o desenho da implantação continuam sob sua responsabilidade.

O Docker Desktop tem regras comerciais próprias. A página de licenciamento do Docker informa que, para uso comercial gratuito do Desktop, pequenas empresas elegíveis precisam ter menos de 250 funcionários e menos de $10 milhões de receita anual. Organizações maiores e órgãos públicos precisam de uma assinatura paga. O Docker Pro custa $11 por usuário/mês na cobrança mensal ou $9 por usuário/mês no plano anual. Esses valores são da assinatura do Desktop, não do código do gateway.

Também é preciso distinguir as ofertas: a documentação atual do Docker apresenta separadamente o MCP Gateway como parte do Docker AI Governance, disponível apenas por convite, por meio da equipe de vendas. O repositório público sob licença MIT continua sendo a opção de código independente. Não use o preço da licença do repositório para orçar a oferta comercial de governança.

Escolha Docker quando o isolamento por contêineres e a operação dos servidores forem importantes e houver alguém responsável por esse ambiente de execução. Um gateway em cada notebook pode reunir as ferramentas locais; a política compartilhada da organização e o acesso de clientes remotos ainda exigem um desenho de implantação específico.

Lasso MCP Gateway

Lasso MCP Gateway é um intermediário baseado em plugins para solicitações e respostas MCP. Ele lê as configurações dos servidores, gerencia os servidores configurados e disponibiliza seus recursos por uma interface unificada. O repositório inclui exemplos para Cursor e Claude Desktop.

O código do gateway usa a licença MIT. O plugin basic mascara tokens e segredos. O plugin opcional presidio mascara informações pessoais, e o xetrack acrescenta rastreamento com eventos armazenados em SQLite e exige uma instalação própria.

O limite mais importante é onde o plugin opera. O plugin lasso exige uma chave de API da Lasso e envia conteúdo pela API da Lasso para verificações. A licença MIT do gateway não define o preço nem os termos dessa API hospedada, e o README não informa seu preço. Trate-a como uma dependência de serviço separada ao montar o orçamento ou decidir por onde o conteúdo pode passar.

Escolha Lasso quando precisar ampliar o tratamento de solicitações e respostas e puder assumir a operação ao redor disso. O README não comprova a existência de um serviço pronto com identidade compartilhada, permissões de ferramentas por usuário e limites de chamadas. Exija esses controles explicitamente se eles forem o motivo para adotar um gateway.

Quanto custa operar um gateway MCP?

A licença do software é apenas uma linha do orçamento. Separe as taxas de software ou assinatura do gateway, a infraestrutura de execução e os logs, o tempo de operação e os modelos e aplicações de destino usados pelo fluxo.

Em um serviço gerenciado, inclua a cobrança por usuário ou uso e os adicionais de exportação ou segurança necessários. Na hospedagem própria, inclua a infraestrutura do gateway e dos servidores, a retenção de logs, as atualizações, a gestão de credenciais e o trabalho de recuperação. Um gateway gratuito pode dar acesso a uma conta SaaS paga e a um modelo pago.

Veja um exemplo de planejamento para uma equipe pequena. Considere um custo interno de trabalho de $100/hora, incluindo os custos indiretos associados ao tempo da equipe. Considere também $20/mês para a infraestrutura e os logs adicionais na hospedagem própria. Esses valores são premissas escolhidas para o orçamento, não cotações de fornecedores nem requisitos de hospedagem medidos.

Com essas premissas, a hospedagem própria economiza $180/mês em relação ao suporte da configuração direta usado como referência. Ela custa $220/mês, mesmo com uma licença de código do gateway de $0. Se a implantação consumir oito horas da equipe, acrescente $800. A estimativa para o primeiro ano é 12 × $220 + $800 = $3,440, contra $4,800 no cenário de suporte direto descrito.

Essa economia depende inteiramente de o gateway reduzir o trabalho de suporte conforme a premissa. Meça o tempo gasto hoje e substitua os valores do exemplo. Uma configuração direta mantida por uma configuração compartilhada simples pode custar muito menos.

Como aplicar os preços dos fornecedores ao seu ambiente

Para seis usuários ativos da Cloudflare, o Free pode significar $0 em cobranças do plano da Cloudflare, dentro do limite de 50 usuários. No cenário gerenciado compatível da tabela, o trabalho interno de gestão das políticas ainda seria de $50/mês. Servidores de destino hospedados, uso de modelos, assinaturas e adicionais ficam fora desse valor.

Para 60 licenças de usuário contratadas no Pay-as-you-go, a tarifa publicada de $7 resulta em 60 × $7 = $420/mês, ou $5,040/ano. Esse orçamento cobre as 60 licenças pagas. O limite de 50 usuários do Free pertence a outro plano; ele não representa um abatimento de 50 licenças nesse cálculo. A documentação de licenças de usuário da Cloudflare informa que as licenças disponíveis correspondem aos usuários contratados e que uma identidade ocupa uma licença, independentemente das aplicações acessadas.

Para seis novas assinaturas mensais do Docker Pro, caso sejam necessárias para a opção escolhida com Desktop, o cálculo é 6 × $11 = $66/mês, usando o preço do próprio Docker. Se já houver assinaturas adequadas, o gasto adicional com assinaturas pode ser de $0. Uma implantação baseada em Engine tem seu próprio orçamento de infraestrutura.

No caso da Lasso, comece pelo código do gateway sob licença MIT e acrescente o orçamento do host e dos logs. Se ativar o plugin que depende da API, obtenha separadamente os termos do serviço hospedado. Não é correto lançar como $0 uma dependência cujo preço não foi informado.

Conexões diretas, hospedagem própria ou serviço gerenciado?

Mantenha as conexões diretas enquanto os controles existentes atenderem ao fluxo. Essa é a escolha adequada para um conjunto pequeno e controlado de ferramentas, com um responsável definido e processos viáveis de revogação e auditoria. Reavalie a decisão quando outro cliente, função ou ação sensível fizer as políticas divergirem.

Escolha código aberto com hospedagem própria quando houver um responsável definido pelo ambiente de execução. Docker é o ponto de partida mais claro para servidores MCP em contêineres. Lasso é o exemplo mais relevante quando você precisa interceptar chamadas com plugins. Faça orçamentos separados para integração de identidades, hospedagem e logs e comprove os controles de que precisa.

Escolha um serviço gerenciado quando ferramentas remotas compatíveis precisarem de uma política compartilhada e você quiser delegar a operação do gateway. Cloudflare é uma primeira opção prática para avaliar em um ambiente pequeno de Cloudflare One. Verifique o transporte, a autorização nos serviços de destino, a política de ferramentas e o plano de auditoria necessário antes de ampliar a implantação.

Um único requisito pode mudar a escolha: se o serviço gerenciado não consegue alcançar seus servidores ou fornecer os controles necessários, defina um responsável pela hospedagem própria ou mantenha o acesso direto controlado. A quantidade de recursos de um fornecedor não resolve uma incompatibilidade com suas necessidades operacionais.

Onde o discurso sobre gateways MCP exagera?

Uma única URL não cria automaticamente um sistema confiável de permissões. O principal equívoco é achar que conectar um gateway resolve autorização, auditoria e segurança de uma vez.

O login no portal ainda pode ser seguido por uma autorização OAuth no serviço de destino. Tanto a política do gateway quanto as permissões de registros da aplicação de destino são relevantes. As orientações de segurança do MCP alertam explicitamente contra aceitar tokens destinados a outros recursos e encaminhá-los sem alteração.

Da mesma forma, permitir uma ferramenta é apenas parte do controle sobre seu uso. Uma ação permitida ainda pode receber argumentos inseguros ou afetar o tenant errado se a integração do servidor permitir. Mascarar respostas não substitui as permissões da aplicação nem a aprovação humana para ações de alto impacto.

A Cloudflare oferece um exemplo concreto de política. A documentação dos portais informa que MFA independente, justificativa de finalidade e autenticação temporária não são exigidos quando um servidor é autorizado por um portal, enquanto seletores como grupos e postura do dispositivo continuam valendo. MFA significa um fator adicional de autenticação. Leia essa limitação de política antes de tratar o portal como um fluxo de aprovação.

Por fim, um gateway não consegue registrar chamadas de ferramentas que passam por fora dele. Defina o caminho aprovado, preserve as permissões dos serviços de destino e mantenha a manutenção dos servidores no escopo. O produto acrescenta um ponto de controle útil; o responsável determina até onde essa proteção vai.

Por onde começar na segunda-feira

Teste um fluxo em um piloto e comprove o controle pelo qual você está pagando. Escolha uma ferramenta de baixo risco e uma de alto impacto desse fluxo, usando os clientes de agentes dos quais a equipe de operação já depende.

1. 1

   Mapeie as conexões atuais

   Registre cada cliente, endpoint de servidor, transporte, responsável pela credencial, ferramenta disponível e destino dos logs. Identifique a mudança de política repetida que você quer centralizar. Preserve a configuração atual dos clientes para poder voltar a ela.

2. 2

   Escolha o caminho de operação

   Use conexões diretas se os controles existentes forem suficientes. Faça um piloto com hospedagem própria apenas se houver um responsável pelo ambiente de execução. Para um piloto na Cloudflare, acesse Zero Trust > Access controls > MCP Portals, adicione servidores HTTP compatíveis, atribua políticas do Access ao servidor e ao portal e selecione as ferramentas e os prompts permitidos.

3. 3

   Verifique a descoberta e a execução

   Conecte cada cliente selecionado pelo método compatível com ele. Verifique se a ação de baixo risco está disponível e pode ser executada e se uma ação proibida é bloqueada mesmo quando solicitada explicitamente. Confira as permissões de dados nos serviços de destino, além da lista de ferramentas do gateway.

4. 4

   Revogue o acesso e acompanhe os registros

   Remova a permissão da identidade usada no piloto e confirme que a próxima tentativa de ação falha. Localize as solicitações permitidas e bloqueadas nos registros fornecidos pelo produto. Confirme que o destino dos logs e a retenção atendem ao seu requisito.

5. 5

   Calcule o custo e mantenha um responsável

   Registre os custos de assinatura, hospedagem dos serviços de destino, logs e tempo da equipe. Amplie o uso somente depois que a política e o caminho de recuperação funcionarem. Documente como voltar à configuração controlada anterior sem criar um desvio sem governança.

Perguntas frequentes

O que é um gateway MCP?

Um gateway MCP é um ponto de controle entre clientes de IA e servidores MCP. Ele pode centralizar autenticação, listas de ferramentas permitidas, logs, limites de chamadas e roteamento. Verifique cada controle na implementação escolhida, sem presumir que todo agregador o fornece.

Qual é a diferença entre gateway MCP e servidor MCP?

Um servidor MCP disponibiliza ferramentas, recursos e prompts. Um gateway controla o acesso a um ou mais servidores e pode apresentar os recursos aprovados por uma interface compartilhada. O servidor de destino e a aplicação continuam executando e autorizando o trabalho por trás de cada ação.

Minha equipe precisa de um gateway MCP?

Use um quando vários clientes ou funções precisarem de uma política comum de ferramentas, de um processo de revogação ou de uma trilha de auditoria. Conexões diretas podem continuar sendo adequadas quando um responsável já atende a esses requisitos. O protocolo não estabelece uma quantidade de servidores a partir da qual um gateway se torna obrigatório.

Qual é a diferença entre um proxy e um gateway MCP?

Um proxy básico encaminha tráfego. Um gateway que entende MCP pode interpretar a descoberta e a execução de ferramentas, reunir recursos e aplicar políticas específicas por ferramenta. Como as ações MCP podem compartilhar um endpoint HTTP, permissões apenas por URL talvez não expressem as restrições de ações de que você precisa.

MCP funciona como um gateway de API?

O MCP em si é um protocolo. Um gateway MCP tem um papel semelhante ao de um gateway de API, mas controla recursos e chamadas MCP. Um gateway de API ainda pode fazer parte da mesma arquitetura para autenticação HTTP, controles de rede ou limites de tráfego.

MCP e HTTP são a mesma coisa?

Não. O MCP define as mensagens e os recursos; HTTP é uma forma de transportar essas mensagens até servidores remotos. O MCP também oferece suporte a stdio para processos locais. Essa diferença de transporte explica por que um gateway HTTP gerenciado não consegue usar diretamente todo servidor que funciona apenas localmente.

Por que usar MCP em vez de REST?

O MCP oferece aos clientes de IA compatíveis uma forma comum de descobrir e acionar ferramentas. Um servidor pode encapsular uma API REST existente, mantendo REST por baixo da integração. Prefira a interface de que seus clientes realmente precisam; adicionar MCP não exige reescrever todas as APIs das aplicações.

MCP é baseado em JSON?

Sim. O MCP usa mensagens JSON-RPC 2.0 para solicitações, respostas e notificações. O protocolo define o significado dessas mensagens, incluindo a descoberta e a execução de ferramentas; ele vai além de um endpoint JSON genérico.

Qual é a diferença entre MCP e RAG?

MCP é um protocolo de integração para ferramentas e dados. RAG, ou geração aumentada por recuperação, busca informações para embasar a resposta de um modelo. Uma ferramenta de recuperação pode ser disponibilizada por MCP, então os dois podem trabalhar juntos. Adicionar um gateway, por si só, não melhora a qualidade da recuperação.

Para mais decisões práticas de infraestrutura e verificações de preços com data, assine a newsletter.