Gemini Enterprise Agent Platform abre un remote MCP: Google Cloud quiere que Claude Code y Antigravity entren por IAM
TL;DR
Google Cloud publicó el 30 de junio de 2026 el remote MCP server de Gemini Enterprise Agent Platform. Para builders, el cambio útil es conectar agentes externos a Model Garden, prompts, notebooks y endpoints sin escribir integraciones a mano.

Por qué importa
Esta nota se enfoca en la decisión práctica para builders: qué cambia, qué riesgo agrega y cómo aplicarlo sin romper operación.
Google Cloud publicó el 30 de junio de 2026 una pieza que apunta directo a equipos que ya usan agentes fuera de Google Cloud: el remote MCP server de Gemini Enterprise Agent Platform. La promesa no es otro wrapper. Es una entrada estándar para que agentes externos, como Claude Code, Antigravity CLI o apps propias, interactúen con recursos de Agent Platform dentro de un proyecto de Google Cloud.
La nota oficial lo describe como un puente entre herramientas de desarrollo externas y arquitectura cloud. En concreto, el agente puede llamar modelos de Model Garden, traer prompt templates compartidos, administrar notebooks y usar toolsets de generación, predicción, endpoints, modelos, tuning, evaluación y prompts.

La noticia real es el límite operativo
MCP suele venderse como "conecta herramientas". En una empresa, la pregunta útil es otra: ¿quién puede llamar qué, con qué identidad y contra qué proyecto?
Ahí está el valor de este lanzamiento. La documentación de Google dice que el servidor usa OAuth 2.0 e IAM para autenticación y autorización. También separa roles mínimos: roles/mcp.toolUser para hacer tool calls y roles/aiplatform.user para administrar recursos de Agent Platform. Para prototipos acepta API keys en express mode o llaves vinculadas a service accounts, pero no llaves estándar sin principal IAM.
Ese detalle importa porque un remote MCP que administra modelos, endpoints y notebooks no puede tratarse como "plugin de productividad". Es superficie de control.
Qué toolsets valen la pena mirar primero
Google lista endpoints como /mcp/generate, /mcp/predict, /mcp/notebook, /mcp/endpoints, /mcp/models, /mcp/tuning, /mcp/evaluation y /mcp/prompts. Para builders de agentes, yo los separaría así:
- prompts y evaluación para equipos que quieren versionar comportamiento antes de tocar producción;
- notebooks para investigación asistida con contexto de datos;
- endpoints y modelos para operaciones de inferencia y despliegue;
- generate y predict para construir flujos simples antes de pasar a orquestación más compleja.
El error común sería habilitar todo porque "MCP ya funciona". Mejor empezar con toolsets de bajo riesgo, logs claros y una identidad por entorno.

Artículos relacionados
Sigue explorando MCP y otras lecturas para builders.

MCP con Python: conecta APIs y bases de datos a tu agente

MCP explicado: cómo conectar herramientas a tu agente sin reinventar la rueda

Atlassian Rovo MCP v2 reduce más de 50% el contexto expuesto con discover y execute
