Visão geral do Protocolo de Contexto de Modelo (MCP) na Apigee

Esta página se aplica à Apigee e à Apigee híbrida.

Confira a documentação da Apigee Edge.

Nesta página, descrevemos como usar a Apigee para expor suas APIs como ferramentas de MCP para aplicativos de agentes. O MCP na Apigee está disponível para organizações de assinatura, pagamento por uso e avaliação, incluindo organizações com residência de dados ativada. A partir da versão 1.17.0 da Apigee híbrida, o MCP também está disponível para a Apigee híbrida. O plano de dados do ambiente de execução é executado no seu próprio cluster do Kubernetes, e não na infraestrutura gerenciada pelo Google. Consulte Ativar o MCP na Apigee híbrida para ver o fluxo de instalação e configuração específico da híbrida.

O que é o MCP?

O Protocolo de Contexto de Modelo (MCP, na sigla em inglês) é um protocolo de código aberto desenvolvido pela Anthropic que padroniza a maneira como os aplicativos de IA se conectam a fontes de dados, fluxos de trabalho e ferramentas.

Os aplicativos de IA podem usar o MCP para acessar os serviços da Google Cloud e da Apigee como ferramentas. Nesse contexto, é útil entender os seguintes termos do MCP:

  • Host do MCP: o aplicativo ou ambiente de IA que interage com o usuário. O host do MCP usa modelos de linguagem grandes (LLMs) para processar solicitações que podem exigir dados ou ferramentas externas.
  • Cliente MCP: um componente no host MCP que ajuda o LLM e o servidor MCP a se comunicarem entre si. Ele traduz as solicitações do LLM para o servidor MCP e converte as respostas do servidor MCP para o LLM. Ele também encontra e usa servidores MCP disponíveis.
  • Servidor MCP: o serviço externo que fornece contexto, dados ou recursos ao LLM, atuando como um proxy entre o LLM e o cliente MCP.

Como o MCP funciona na Apigee

Os endpoints MCP para o Google, Google Cloude a Apigee implementam a especificação do servidor MCP. Isso permite que os clientes compatíveis com o MCP os acessem para:

  • Descubra os endpoints disponíveis.
  • Lista as ferramentas disponíveis em um endpoint.
  • Autenticar em um endpoint.
  • Chamar ferramentas de acordo com as políticas de acesso definidas.

Qualquer cliente MCP que ofereça suporte a endpoints MCP remotos em HTTP/S pode acessar essas ferramentas. Como os endpoints são gerenciados, não é necessário instalar ou gerenciar servidores MCP locais, servidores MCP remotos ou infraestrutura adicional para permitir que aplicativos de agentes acessem seus serviços.

O MCP na Apigee oferece suporte a JSON-RPC para os métodos tools/list e tools/call, e para o método server/discover no protocolo MCP sem estado. É possível personalizar o endpoint do MCP com parâmetros de facilidade de descoberta, segurança, disponibilidade de rede e observabilidade. Para as versões do protocolo MCP compatíveis com a Apigee, consulte Versões do protocolo MCP compatíveis.

Modelos de implantação

O MCP está disponível em dois modelos de implantação da Apigee:

  • Apigee (SaaS): o plano de dados do MCP é hospedado na infraestrutura gerenciada pelo Google. Você implanta o proxy de descoberta do MCP, e o endpoint fica disponível imediatamente.
  • Apigee híbrida (auto-hospedada, a partir da Apigee híbrida 1.17.0): o plano de dados do MCP é executado no seu próprio cluster do Kubernetes. O plano de controle da Apigee gera a configuração da ferramenta MCP com base na sua especificação OpenAPI, e o cluster busca essa configuração de acordo com o próprio cronograma. O tráfego de solicitação do MCP nunca sai do cluster. Consulte Ativar o MCP na Apigee híbrida.

Arquitetura do plano de dados do MCP na Apigee híbrida

O diagrama a seguir mostra como os componentes do MCP são distribuídos entre o plano de controle da Apigee e o cluster da Apigee híbrida.

MCP na arquitetura híbrida da Apigee: os clientes do MCP chamam sua entrada atual da Apigee por HTTPS, que encaminha para o processador de mensagens e, em seguida, para o novo plano de dados do MCP no cluster. A configuração da ferramenta MCP é gerada pelo plano de controle da Apigee e extraída pelo cluster. O plano de controle da Apigee nunca chama o cluster.

Duas propriedades dessa arquitetura são importantes para o planejamento e a revisão de segurança:

  • O tráfego de solicitações do MCP permanece dentro do cluster. Os clientes do MCP acessam sua entrada atual da Apigee no mesmo URL que usariam para qualquer outro proxy da Apigee. Em seguida, o processador de mensagens encaminha a solicitação para o plano de dados do MCP no mesmo cluster. Nenhuma solicitação ou resposta do MCP cruza o limite para o Google Cloud no momento da solicitação.
  • A configuração é extraída, não enviada. A configuração da ferramenta MCP é gerada pelo plano de controle da Apigee e recuperada por um componente no seu cluster de acordo com uma programação. O plano de controle da Apigee nunca inicia uma conexão com o cluster. Consulte Requisitos de rede de saída para saber os endpoints exatos que a saída do cluster precisa permitir.

Versões compatíveis do protocolo MCP

O MCP na Apigee é compatível com o protocolo MCP sem estado, versão 2026-07-28, e as versões de protocolo MCP com estado 2025-11-25, 2025-06-18, 2025-03-26 e 2024-11-05. Um endpoint do MCP atende aos dois protocolos ao mesmo tempo. Assim, os clientes do MCP atuais continuam funcionando quando os clientes do MCP que usam o protocolo sem estado chamam o mesmo endpoint.

Nesta página, sem estado se refere ao modelo de metadados por solicitação introduzido na versão 2026-07-28 do MCP, que a especificação do MCP também chama de moderno. Com estado se refere ao modelo anterior que começa com uma solicitação initialize, que a especificação do MCP também chama de legado. Para ver um exemplo prático, consulte Listar ferramentas com o protocolo MCP sem estado no guia de início rápido.

Protocolo Versões Métodos aceitos
Sem estado 2026-07-28
  • server/discover
  • tools/list
  • tools/call
Com estado
  • 2025-11-25
  • 2025-06-18
  • 2025-03-26
  • 2024-11-05
  • initialize
  • notifications/initialized
  • tools/list
  • tools/call

Como a Apigee seleciona o protocolo

A Apigee seleciona o protocolo no corpo da solicitação, não no cabeçalho MCP-Protocol-Version. Uma solicitação em que o objeto params._meta contém io.modelcontextprotocol/protocolVersion com um valor de string JSON usa o protocolo sem estado. Uma solicitação sem essa chave ou com um valor que não é uma string usa o protocolo com estado.

  • Qualquer valor de string seleciona o protocolo sem estado. Se a string nomear uma versão que não é compatível com a Apigee, a solicitação ainda usará o protocolo sem estado e falhará com o erro JSON-RPC -32022 (Unsupported protocol version). Ela não voltará para o protocolo com estado.
  • Uma solicitação com um cabeçalho MCP-Protocol-Version de 2026-07-28, mas sem io.modelcontextprotocol/protocolVersion em params._meta, é uma solicitação com estado. A versão 2026-07-28 não é uma versão com estado. Portanto, a Apigee a rejeita com HTTP 400 e o erro JSON-RPC do protocolo com estado -32602 (Unsupported protocol version), não o erro sem estado -32022. Para usar a versão 2026-07-28, uma solicitação precisa usar o formato de solicitação sem estado.
  • Se uma solicitação initialize pedir a versão 2026-07-28 ou qualquer versão não compatível com a Apigee, ela negociará a versão 2025-11-25.
  • O método server/discover está disponível apenas no protocolo sem estado. Uma solicitação server/discover com estado segue o tratamento de erros do protocolo com estado: ela recebe HTTP 200 com o erro JSON-RPC -32601 (Method server/discover is not supported) no corpo da resposta. O status HTTP 404 em Erros de protocolo sem estado se aplica apenas a solicitações sem estado.

Solicitações de protocolo sem estado

Cada solicitação sem estado precisa conter a versão do protocolo no corpo e no cabeçalho. Se você estiver movendo um cliente MCP do protocolo com estado, estas são as principais diferenças:

  • O cliente MCP não chama initialize. A Apigee não cria sessões para o protocolo sem estado.
  • O cliente do MCP não envia um cabeçalho Mcp-Session-Id. Se uma solicitação sem estado incluir um, a Apigee vai ignorá-lo.
  • Cada solicitação carrega um objeto params._meta com a versão do protocolo e os recursos do cliente.
  • Cada solicitação carrega os cabeçalhos MCP-Protocol-Version e Mcp-Method, e uma solicitação tools/call também carrega o cabeçalho Mcp-Name.
  • As solicitações inválidas recebem HTTP 400 ou 404 com os códigos do erro em Erros de protocolo sem estado.

Uma solicitação sem estado precisa incluir os seguintes campos no corpo da solicitação:

  • params._meta["io.modelcontextprotocol/protocolVersion"]: precisa ser a string JSON "2026-07-28", não um número.
  • params._meta["io.modelcontextprotocol/clientCapabilities"]: precisa ser um objeto JSON. Se o cliente MCP não declarar recursos, envie um objeto vazio ({}).
  • Opcional: params._meta["io.modelcontextprotocol/clientInfo"], um objeto com o name e o version do cliente do MCP. A especificação do MCP recomenda que os clientes do MCP o enviem em todas as solicitações.

Uma solicitação sem estado precisa incluir os seguintes cabeçalhos HTTP:

Cabeçalho Necessário para Valor
MCP-Protocol-Version Todos os métodos 2026-07-28. Precisa corresponder à versão do protocolo em _meta.
Mcp-Method Todos os métodos O método JSON-RPC, por exemplo, tools/list. Precisa corresponder ao campo method no corpo da solicitação.
Mcp-Name Apenas o tools/call O nome da ferramenta. Precisa corresponder a params.name no corpo da solicitação. Envie o nome da ferramenta como um valor de cabeçalho ASCII simples. Se o nome da ferramenta tiver caracteres não ASCII ou de controle, espaços em branco à esquerda ou à direita ou corresponder ao padrão =?base64?...?=, ele precisará ser codificado como =?base64?ENCODED_NAME?=, em que ENCODED_NAME é a codificação base64 preenchida do nome da ferramenta UTF-8. Para mais detalhes, consulte Codificação de valor na especificação do MCP. Não envie Mcp-Name com tools/list ou server/discover.

Envie cada cabeçalho uma vez. A Apigee trata um cabeçalho MCP-Protocol-Version, Mcp-Method ou Mcp-Name repetido como uma incompatibilidade de cabeçalho.

Os resultados sem estado incluem "resultType": "complete". Os resultados de tools/list e server/discover também incluem "cacheScope": "public" e "ttlMs": 0. Um ttlMs de 0 significa que os resultados ficam desatualizados assim que chegam: a Apigee não oferece uma janela de cache para eles, então cacheScope não tem efeito prático. O resultado server/discover lista as versões de protocolo compatíveis em supportedVersions, os recursos do servidor em capabilities ("tools": {"listChanged": false}) e as informações do servidor em _meta["io.modelcontextprotocol/serverInfo"]. A ordem dos campos em um objeto JSON não é garantida, então os clientes do MCP precisam ler os campos pelo nome.

Se uma solicitação tools/call sem estado incluir as chaves do OpenTelemetry traceparent, tracestate ou baggage em params._meta, a Apigee encaminhará os valores delas para o back-end como cabeçalhos HTTP com o mesmo nome.

A Apigee não adiciona anotações x-mcp-header às definições de ferramentas que tools/list retorna. Portanto, os clientes do MCP não enviam cabeçalhos Mcp-Param-NAME para a Apigee.

Erros de protocolo sem estado

A Apigee rejeita uma solicitação sem estado que não atende aos requisitos em Solicitações de protocolo sem estado com um dos erros a seguir. Para corrigir um erro 400, verifique se a solicitação atende a esses requisitos. A Apigee não exige nenhum recurso do cliente, portanto, não retorna o erro JSON-RPC -32021 (MissingRequiredClientCapability).

Condição Status HTTP Código de erro JSON-RPC Mensagem de erro
O cabeçalho MCP-Protocol-Version, Mcp-Method ou Mcp-Name está ausente. 400 -32020 Missing HEADER header
Um cabeçalho não corresponde ao corpo da solicitação, está vazio ou aparece mais de uma vez. 400 -32020 Header mismatch: HEADER header does not match request body
A versão do protocolo não é compatível. O erro data contém a versão solicitada em requested e as versões compatíveis em supported. 400 -32022 Unsupported protocol version
io.modelcontextprotocol/clientCapabilities não está em _meta. 400 -32602 Missing io.modelcontextprotocol/clientCapabilities in _meta
io.modelcontextprotocol/clientCapabilities não é um objeto JSON. 400 -32602 io.modelcontextprotocol/clientCapabilities in _meta is not an object
O método não é compatível com o protocolo sem estado, por exemplo, initialize, notifications/initialized, ping, resources/list, resources/read, prompts/list ou subscriptions/listen. 404 -32601 Method METHOD is not supported

Principais recursos do MCP na Apigee

O MCP na Apigee oferece recursos para descoberta, segurança e governança de ferramentas. Esses recursos ajudam a gerenciar como os aplicativos de agentes interagem com seus serviços.

Descoberta simplificada de ferramentas com o hub de APIs

É possível descobrir endpoints do MCP disponíveis para serviços da Apigee usando um serviço de diretório acessível por uma interface REST. Cada endpoint do MCP também é compatível com o método tools/list do MCP, que permite que os clientes do MCP descubram as ferramentas disponíveis nesse endpoint.

Além disso, o MCP se integra ao hub de APIs da Apigee. Quando um proxy de descoberta do MCP é implantado, o hub de APIs ingere automaticamente a especificação OpenAPI, atribui a ele o estilo de API MCP e mapeia as operações da API para ferramentas individuais do MCP. Isso permite que os desenvolvedores filtrem facilmente as APIs compatíveis com MCP no hub de APIs e usem a pesquisa semântica com consultas em linguagem natural para encontrar ferramentas relevantes para os aplicativos de agentes.

Posicionamento do argumento da ferramenta na solicitação de back-end

Quando um cliente do MCP chama uma ferramenta, a Apigee cria uma solicitação para seu back-end com base nos argumentos fornecidos pelo cliente. O valor in que cada parâmetro declara na especificação OpenAPI determina onde esse argumento é colocado na solicitação de saída.

Valor de in da OpenAPI Onde o argumento é enviado na solicitação de back-end
header Como um cabeçalho da solicitação. O nome do parâmetro é usado como o nome do cabeçalho, exatamente como escrito na especificação.
cookie No cabeçalho da solicitação Cookie, como um par name=value. Se uma operação declarar vários parâmetros de cookie, eles serão enviados em um cabeçalho Cookie, separados por ;  (um ponto e vírgula e um espaço).
query Na string de consulta.
path Substituído no caminho do URL da solicitação.

Cada parâmetro aparece no inputSchema da ferramenta, independentemente do valor de in. Portanto, um cliente MCP fornece todos eles da mesma maneira. O valor de in muda apenas onde o valor é colocado na solicitação para o back-end.

Por exemplo, a operação a seguir declara um parâmetro em cada um dos três locais:

paths:
  /orders:
    get:
      operationId: listOrders
      parameters:
        - name: X-Session-Id
          in: header
          schema:
            type: string
        - name: tenantId
          in: cookie
          schema:
            type: string
        - name: limit
          in: query
          schema:
            type: integer

Uma solicitação tools/call que fornece os três argumentos produz uma solicitação de back-end com o seguinte formato:

GET /orders?limit=25
X-Session-Id: sess-abc-123
Cookie: tenantId=tenant-xyz-789

Observe o seguinte comportamento:

  • Um argumento vinculado a um cabeçalho ou cookie não é anexado à string de consulta nem incluído no corpo da solicitação.
  • Um argumento que o cliente não fornece é ignorado. Nenhum cabeçalho, cookie ou parâmetro de consulta vazio é enviado no lugar dele.
  • Um cabeçalho vinculado substitui qualquer cabeçalho com o mesmo nome que já esteja na solicitação de back-end. Outros cabeçalhos na solicitação de back-end são transmitidos sem alterações.
  • Os valores são codificados por porcentagem (RFC 3986) quando colocados na solicitação de back-end. Assim, um valor que contém um espaço ou um caractere reservado chega ao back-end na forma codificada. Decodifique-o lá se precisar do original.
  • Quando uma operação e o caminho dela declaram um parâmetro com o mesmo nome e o mesmo valor in, a declaração no nível da operação é aplicada, conforme exigido pela especificação da OpenAPI.
  • Dê nomes distintos aos parâmetros na mesma operação, mesmo quando eles declararem valores in diferentes. A OpenAPI identifica um parâmetro pelo par de nome e local, mas uma ferramenta MCP usa um único valor por nome de argumento. Se uma especificação declarar dois parâmetros com o mesmo nome e valores in diferentes, o cliente fornecerá um valor, que será enviado para ambos os locais declarados na solicitação de back-end: um sessionId declarado como in: cookie e in: query chega no cabeçalho Cookie e na string de consulta. Verifique isso se o back-end tiver uma lógica que dependa da origem de um valor.
  • Os nomes dos argumentos diferenciam maiúsculas de minúsculas. Portanto, UserID e userid são dois argumentos diferentes. Para parâmetros header, dê um passo adiante e faça com que os nomes sejam diferentes em mais do que maiúsculas e minúsculas: os nomes de cabeçalho HTTP não diferenciam maiúsculas de minúsculas. Portanto, dois parâmetros de cabeçalho com nomes que diferem apenas em maiúsculas e minúsculas são resolvidos para o mesmo cabeçalho na solicitação de back-end, e apenas um dos dois valores sobrevive.

Os cookies são o único caso em que a vinculação pode remover algo da solicitação, em vez de apenas adicionar. Ao contrário de outros cabeçalhos HTTP, que carregam pares de nome/valor independentes que podem ser definidos individualmente, todos os cookies compartilham um único cabeçalho Cookie. A Apigee não mescla os cookies que você vincula aos cookies que chegaram na solicitação do cliente do MCP: quando uma chamada fornece qualquer argumento de cookie, o cabeçalho Cookie é substituído como um todo apenas pelos cookies vinculados.

Portanto, se um cookie que chegou com a solicitação HTTP do cliente MCP chega ao seu back-end depende da chamada de ferramenta individual:

  • Se a operação não declarar parâmetros cookie, o cabeçalho Cookie será encaminhado ao back-end sem alterações.
  • Se a operação declarar parâmetros cookie, mas a chamada não fornecer nenhum deles, o cabeçalho Cookie será encaminhado novamente para o back-end sem alterações.
  • Assim que a chamada fornecer pelo menos um argumento de cookie, o cabeçalho Cookie será substituído apenas pelos cookies vinculados. Qualquer cookie que tenha chegado na solicitação do cliente e não tenha sido declarado como um parâmetro cookie será descartado.

Como o terceiro caso é orientado pelos argumentos que uma chamada específica fornece, uma operação com parâmetros de cookie opcionais pode transmitir cookies em uma chamada e descartá-los na próxima. Não há configuração que preserve um cookie não declarado. Se o back-end depender de um cookie, declare-o como um parâmetro cookie em todas as operações que precisarem dele. Assim, o valor será sempre fornecido pela chamada de ferramenta, em vez de ser herdado da solicitação do cliente.

Segurança

O MCP na Apigee inclui várias camadas de segurança para proteger seus serviços. É possível controlar o acesso usando autenticação, autorização, limites de rede e verificação de conteúdo.

Autenticação

Os endpoints do MCP hospedados na Apigee são compatíveis com o OAuth 2.1 e o OpenID Connect (OIDC) para autenticação. Isso garante que apenas agentes, clientes MCP e usuários finais com identidades estabelecidas possam acessar seus endpoints MCP e chamar ferramentas MCP. Os metadados de recursos protegidos permitem que os clientes descubram os servidores de autorização OAuth.

Políticas de autorização granulares

É possível restringir o acesso às ferramentas do MCP com base nas identidades do cliente OAuth. Por exemplo, é possível configurar uma política no proxy de descoberta do MCP para especificar que apenas agentes designados com identidades de cliente conhecidas podem acessar uma ferramenta do MCP para um serviço de pagamentos.

Responsabilidade do cliente pelas invocações de ferramentas

Os aplicativos cliente do MCP são responsáveis por garantir a supervisão humana das invocações de ferramentas, como solicitar ao usuário antes de executar operações de mutação de estado. Para mais informações, consulte a documentação do protocolo de contexto do modelo.

Observabilidade e análise

Para endpoints hospedados na Apigee, use o Apigee Analytics para conferir informações detalhadas de uso das suas ferramentas do MCP. Com o Analytics, é possível segmentar o tráfego específico do MCP do tráfego padrão da API e conferir métricas no nível da ferramenta individual, como o volume de solicitações de tools/list (descoberta) em comparação com tools/call (execução). As métricas de performance também ajudam a distinguir entre a sobrecarga do proxy e o tempo de resposta do destino, permitindo que você identifique gargalos com mais eficácia.

Confiabilidade e solução de problemas

Para melhorar a solução de problemas e fornecer mais visibilidade sobre o processo de implantação, a Apigee mostra erros específicos de infraestrutura e configuração na UI. Se uma implantação falhar devido a uma especificação OpenAPI inválida ou a um problema de infraestrutura regional, a UI vai fornecer feedback útil para ajudar você a resolver o problema sem precisar de intervenção do suporte.

Como usar o MCP com a Apigee

É possível expor suas APIs da Apigee como ferramentas do MCP e disponibilizá-las por endpoints do MCP. Esses endpoints podem ser configurados por host ou por grupo de ambiente. Por exemplo, se a organização do cymbal tiver oito nomes de host (por exemplo, api.cymbal.com, partners.cymbal.com), cada um associado a um grupo de ambiente diferente, você poderá hospedar um servidor MCP dedicado para cada nome de host.

Um endpoint de destino gerenciado (ORG_NAME.mcp.apigee.internal) é implantado usando um proxy de descoberta de MCP especializado na sua organização da Apigee, onde os servidores MCP são disponibilizados.

A tabela a seguir mostra um exemplo de como os clientes, incluindo a organização fictícia Cymbal, podem configurar vários endpoints de MCP usando a Apigee.

Cliente Nome do host e caminho base do MCP Endpoint de destino do servidor MCP Proxy de API Ambiente / Grupo de ambientes
címbalo api.cymbal.com/mcp cymbal.mcp.apigee.internal
(projeto de locatário da cymbal org)		 mcp-api-proxy1 prod / prod-env-group
api-internal.cymbal.com/mcp cymbal.mcp.apigee.internal
(projeto de locatário da cymbal org)		 mcp-api-proxy2 internal / internal-env-group
api-service.cymbal.com/mcp cymbal.mcp.apigee.internal
(projeto de locatário da cymbal org)		 mcp-api-proxy3 dev / dev-env-group

Limitações

As seguintes limitações se aplicam ao MCP na Apigee:

  • O número de ferramentas MCP em uma organização da Apigee é limitado a 1.000.
  • A implantação da infraestrutura do MCP pode estar sujeita a limitações de capacidade nas seguintes regiões:
    • europe-central2
    • europe-southwest1
    • europe-west9
    • me-central2

    Se você receber um erro de provisionamento ou se o status de provisionamento nunca mudar para Implantado, talvez seja devido a limites temporários de capacidade de infraestrutura na região selecionada. Tente implantar o proxy em um ambiente de outra região.

  • O MCP na Apigee é compatível com as seguintes versões da OpenAPI: 3.0.0, 3.0.1, 3.0.2, 3.0.3.
  • Os insights de API no hub de APIs da Apigee não estão disponíveis para APIs e ferramentas do MCP implantadas em organizações da Apigee com o VPC-SC ativado.
  • As chamadas GET em respostas de erro do MCP vão retornar um erro 405, já que o servidor MCP não é compatível com streams de eventos enviados pelo servidor (SSE).
  • Os insights da API do hub de APIs da Apigee não vão mostrar APIs no estilo MCP ou tráfego para recursos MCP até que a versão 1-17-0-apigee-6 da Apigee seja totalmente lançada em todas as regiões disponíveis.
  • Não é possível alterar o atributo de estilo da API para MCP em um recurso de API que já tenha operações de API.

Limitações específicas da Apigee híbrida

As seguintes limitações se aplicam ao MCP na Apigee híbrida:

  • Os argumentos de ferramenta declarados como in: header ou in: cookie são enviados na string de consulta. O roteamento por local descrito em Posicionamento do argumento da ferramenta na solicitação de back-end ainda não está disponível na Apigee híbrida. Até que isso aconteça, um parâmetro que declara um desses locais chega ao back-end como um parâmetro de consulta, que é o comportamento que precedeu esse recurso. As linhas in: query e in: path dessa tabela se aplicam à Apigee híbrida conforme escrito.
  • A contagem de ferramentas do MCP é limitada pelo tamanho, não por um número fixo. Ao contrário da Apigee, que impõe um número máximo fixo de ferramentas MCP por organização, a Apigee híbrida limita a capacidade das ferramentas por meio de quatro limites de tamanho: tamanho do arquivo de especificação OpenAPI, tamanho do pacote de proxy MCP, tamanho da resposta de tools/list por nome de host e número de nomes de host por grupo de ambiente. Para a maioria das especificações da OpenAPI, é comum que 10.000 ferramentas do MCP caibam por organização no limite de tamanho de resposta padrão. A capacidade real varia de acordo com o formato específico da sua especificação (dominada pelo número de parâmetros e propriedades do corpo da solicitação, além do tamanho da descrição). Os esquemas de resposta não são contabilizados no orçamento. Para estimar a capacidade das suas especificações OpenAPI e conferir os quatro limites rígidos e os modos de falha deles, consulte Estimar a capacidade da ferramenta MCP.
  • Ativar ou desativar o MCP aciona uma versão canário em etapas dos pods do processador de mensagens. O operador da Apigee atualiza a especificação do pod do processador de mensagens quando você ativa ou desativa o MCP, e o controlador ApigeeDeployment do processador de mensagens executa a alteração por meio de uma versão canário em etapas, em vez de uma reinicialização gradual do Kubernetes. A versão é acionada apenas nas transições de ativação e desativação, não na atividade de implantação do MCP em andamento ou no tráfego do MCP em estado estável. Programe a ativação inicial e as operações de desativação subsequentes durante uma janela de manutenção aprovada.
  • O dimensionamento de recursos do pod do MCP é gerenciado pelo cliente. Os pods do MCP são executados com as solicitações de recurso e os limites definidos pelos padrões integrados nos gráficos do Helm da Apigee híbrida. Se a carga de trabalho exigir mais capacidade, ajuste a CPU e a memória em overrides.yaml. Consulte a referência de campos do overrides.yaml para ver os campos disponíveis.
  • Um plano de dados do MCP por organização da Apigee, por cluster. Na versão 1.17.0, o operador da Apigee provisiona um plano de dados do MCP para cada organização da Apigee instalada no cluster. Um cluster que hospeda várias organizações da Apigee executa um plano de dados do MCP por organização. Os planos de dados são independentes e não compartilham a configuração.
  • É necessário que a ativação seja uniforme em todo o grupo de ambientes. Ative o MCP de maneira uniforme em todos os clusters que atendem ao mesmo grupo de ambientes da Apigee. Se o MCP estiver ativado em alguns clusters e não em outros dentro de um grupo, as solicitações do MCP que forem roteadas para um cluster sem o MCP ativado receberão uma resposta 503 Service Unavailable.
  • O protocolo MCP sem estado não é compatível. A Apigee híbrida é compatível apenas com as versões com estado do protocolo MCP 2025-11-25, 2025-06-18, 2025-03-26 e 2024-11-05. Consulte Versões compatíveis do protocolo MCP.
  • TLS unidirecional entre o processador de mensagens e o plano de dados do MCP. A versão 1.17.0 usa TLS unidirecional entre o processador de mensagens e o plano de dados do MCP.
  • O plano de dados do MCP depende do processador de mensagens para a identidade do autor da chamada. O plano de dados do MCP no cluster não autentica de forma independente os autores de chamada em 1.17.0. Ele confia que as solicitações que chegam até ele já foram autenticadas por um proxy da Apigee em execução no processador de mensagens. Cada solicitação de MCP que precisa ser autenticada deve chegar por um proxy de MCP da Apigee que aplica uma política de autenticação (consulte Gerenciar o acesso à ferramenta MCP). Os clientes Production precisam aplicar controles de entrada de cluster para que apenas os pods do processador de mensagens (rótulo do Kubernetes app=apigee-runtime no mesmo namespace do Kubernetes em que a Apigee híbrida está instalada) possam acessar o serviço MCP no TCP 443. Use qualquer Policy Engine compatível com sua plataforma (Kubernetes NetworkPolicy, Cilium, Calico, Istio AuthorizationPolicy) para aplicar essa restrição.

A seguir