Gemini Enterprise Agent Platform abre un remote MCP: Google Cloud quiere que Claude Code y Antigravity entren por IAM
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 Marco Lee · Reportar un error
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.

Lecturas relacionadas
Sigue explorando MCP y otras piezas para builders.

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

Salesforce Headless 360 llega como MCP beta: cuatro tools para descubrir, describir y ejecutar operaciones

Replit entra a Slackbot MCP: crear apps desde el chat cambia el handoff, no elimina la revisión
