Google Cloud published a plugin called google-cloud-developer that installs directly into whichever coding agent a developer already runs, according to a Google Cloud developer blog post by Jonathan Lee. The plugin bundles skills for authentication, project setup, IAM guardrails and gcloud CLI operations alongside a hosted Developer Knowledge MCP server that grounds the agent in Google’s official documentation.
The notable choice is what Google did not build: its own proprietary coding agent to compete for developer attention. Instead, the company is targeting the agent layer developers have already chosen. Google’s installation instructions cover three separate products by name: Antigravity CLI, Claude Code and Codex CLI. That is an explicit acknowledgment that the coding agent market has fragmented across at least three serious players, and that a cloud vendor now has to meet developers wherever they already work rather than pull them into a walled garden.
This follows a pattern Google names directly in the post: agent skills and remote MCP servers already exist as separate ways to extend a coding agent, but managing them individually got unwieldy once a workflow needed several skills and a live MCP connection working together. Google’s answer is to package the pieces developers were already assembling by hand into one installable unit, rather than adding a fourth standalone extension mechanism.
The plugin is built to the Agent Plugins specification, which Google calls open and vendor-neutral: a single manifest and directory layout that bundles MCP servers together with Agent Skills. Google frames this as protection against the alternative: every AI coding tool maintaining its own incompatible configuration format, forcing vendors like Google to ship and support a separate integration for each one. A shared packaging standard is the reason a single google-cloud-developer plugin can install cleanly into Claude Code, Codex CLI or Antigravity CLI without three different codebases behind it.
Google’s own worked example illustrates the pitch: a developer tells their agent they are new to the platform and need an account, a billed project, and a local machine authenticated to call APIs as a service identity rather than as a person. The agent, per Google’s description, checks the live environment for existing projects or CLI availability, flags IAM risks such as accidental key leaks before acting, and lays out a plan before touching any resource. None of that is independently verified; it is Google’s own account of how the plugin behaves, and the company has not published adoption numbers, benchmark comparisons against MCP-only setups, or usage data from any of the three supported agents.
Amazon and Microsoft have run comparable plays before, wrapping cloud-specific tooling for whatever assistant a developer already had open rather than forcing a switch. What makes this one worth tracking is the explicit standard underneath it: if the Agent Plugins specification holds, a plugin built once should keep working as new agents enter the market, without Google rewriting the integration each time. Teams standardizing on Google Cloud should treat the plugin’s guardrail behavior, not its installation convenience, as the thing to verify before trusting it with production IAM changes.
Reported by Google Cloud’s developer blog, in a post by Jonathan Lee announcing the google-cloud-developer plugin.
