This is a submission for the Google I/O 2026 Writing Challenge
Yesterday, Sundar Pichai stood on stage and described Gemini Spark — a 24/7 personal AI agent that runs in the cloud, works while you sleep, and integrates with third-party tools through MCP.
I watched that announcement from a beach chair, on my phone. And I smiled. Because I run one of those third-party MCP servers.
WebsitePublisher.ai exposes 55+ tools through the Model Context Protocol. Nine AI platforms already connect to it — Claude, ChatGPT, Cursor, GitHub Copilot, Windsurf, Gemini, Grok, Mistral, and others. When Google announced that Spark will use MCP for third-party integrations, it wasn't a surprise. It was confirmation.
MCP just went from "promising open standard" to "the protocol Google built its flagship agent on."
Here's what that means from the perspective of someone who's been building on MCP for the past year.
Three I/O Announcements That Matter for MCP
1. Gemini Spark Runs on MCP
Spark is Google's most ambitious agent product yet. It runs on dedicated cloud VMs, powered by Gemini 3.5 and the Antigravity framework. It handles long-horizon tasks in the background — tracking RSVPs, managing workflows, sending reminders — without you keeping a browser tab open.
The critical detail: Spark will connect to third-party tools through MCP. Not a proprietary Google protocol. Not a plugin marketplace with approval gates. MCP — the same open, JSON-RPC based standard that Anthropic published and that dozens of platforms already support.
For MCP server operators like us, this means our existing infrastructure just gained access to Google's most powerful agent. We don't need to build a new integration. We don't need to apply to a directory. When Spark's MCP support ships, our 55 tools are available to it immediately.
2. Antigravity 2.0 Goes Agent-First
Antigravity is Google's developer platform, and version 2.0 leans hard into agents. The new CLI supports subagent orchestration, terminal sandboxing, credential masking, and Git-aware policies.
What caught my attention: the architecture assumes agents will call external tools as a core workflow, not an afterthought. The sandboxing, the credential management, the ability to spin up specialized subagents — all of this assumes a world where AI agents routinely reach out to external services via standardized protocols.
That's the MCP model. Build once, connect everywhere.
3. AI Edge Gallery Gets MCP Support
This one flew under the radar, but it might be the most interesting for the open-source community. Google AI Edge Gallery now supports MCP, with Gemma 4 handling reasoning locally while only the API calls leave the device.
Think about what that means: an open-weight model, running on your phone or edge device, calling MCP tools on remote servers. The reasoning stays private. Only the structured tool calls travel over the network. That's a privacy-first agent architecture built entirely on open standards.
What "MCP Everywhere" Actually Looks Like in Production
When people hear "MCP support," they think about the protocol spec. I think about what happens at 2 AM when a model sends a malformed tool call.
Running an MCP server in production across 9 platforms has taught me things that don't show up in protocol documentation. Here's what Google's MCP bet actually means for the ecosystem:
Every platform implements MCP slightly differently. Claude sends tool calls one way. ChatGPT structures them another. Cursor batches things. Copilot has its own patterns. The protocol is standardized, but the behavior isn't. When Gemini Spark joins this ecosystem, it will bring its own quirks. MCP server builders need to be resilient to all of them.
Model size determines orchestration depth, not tool-call success. I wrote about this in detail in my Gemma 4 article — simple tool calls succeed regardless of model size. What varies is how many sequential, context-dependent calls a model can chain before losing coherence. With Spark running on Gemini 3.5 and persistent cloud VMs, Google is betting on deep orchestration. That changes what MCP servers need to support.
Authentication is the real battleground. MCP specifies OAuth 2.1 for auth, but every platform handles it differently. Some use session tokens. Some use project-scoped keys. Some do dynamic client registration. When we tested our server on MCP Playground last week, it connected and authenticated — but tool discovery failed because our server was too restrictive about token types. Multiply that by every new platform adopting MCP, and you see the challenge: the protocol is open, but making it work everywhere requires constant adaptation.
From Vibe Coding to Wave Coding
There's a bigger shift happening underneath these announcements, and Google I/O crystallized it for me.
The current hype is "vibe coding" — you prompt an AI, it generates code, you hope it works. It's fun for demos. It's terrifying for production.
What MCP enables is something we've started calling wave coding: instead of generating code from scratch, the AI assembles proven, production-tested software building blocks through structured tool calls. Each wave of assembly builds on the last. The AI doesn't write your payment integration from a prompt — it calls execute_integration with your Stripe credentials and configures a tested, deployed payment flow.
Google's I/O announcements accelerate this shift. When Spark can call MCP tools in the background, 24/7, on dedicated VMs — that's not vibe coding anymore. That's an agent riding waves of pre-built, battle-tested components to deliver real results while you sleep.
Our MCP server already supports 13 e-commerce integrations: product catalogs, shopping carts, checkout flows, payment processing, invoice generation, inventory tracking. An agent like Spark could orchestrate an entire webshop build through sequential MCP calls — not by generating code, but by assembling proven pieces.
That's the trajectory Google just endorsed.
What MCP Server Builders Should Do Right Now
If you're building or running an MCP server, here's what I'd prioritize based on the I/O announcements:
Support deep orchestration. Spark runs on dedicated VMs with Gemini 3.5. It will attempt longer tool-call chains than any current platform. Your server needs to handle 10-15+ sequential calls within a single session without state confusion.
Harden your auth. Accept multiple token types (session tokens, project-scoped keys, OAuth flows). Every new platform that adopts MCP will try to authenticate differently. Be permissive in what you accept, strict in what you authorize.
Make tool schemas discoverable. Your tools/list endpoint is your storefront. When Spark connects and asks what you can do, the response needs to be clear, well-structured, and complete. Poor schemas mean poor tool selection by the agent.
Test across platforms. We test against 9 platforms. When Spark launches its MCP support, it'll be 10. Each one surfaces different edge cases. What works perfectly with Claude might fail silently with Gemini.
The Bigger Picture
A year ago, MCP was a specification from Anthropic. Today, Google built its flagship consumer AI agent on it. Cursor, Copilot, Windsurf, Mistral, Grok — they all support it too.
We're watching MCP become the HTTP of AI agents: an open protocol that lets any model talk to any tool, regardless of who built either one.
Google I/O 2026 didn't invent this future. But it made it inevitable. When the company that runs Search, Gmail, Android, and Chrome tells the world "our AI agent uses MCP for third-party tools," the debate is over. MCP is the standard.
For those of us who've been building on it, that's not a surprise. It's a validation.
And for everyone else: the doors are open. The protocol is documented. The models are ready. The only question is what you'll build.
Written and published from a phone, during Google I/O, while running the MCP server that just got a whole lot more relevant.
Resources:
- MCP Specification — the protocol powering all of this
- WebsitePublisher.ai — our MCP server, free tier with 55+ tools
- Google I/O 2026 Keynote — Sundar Pichai's full recap
- My Gemma 4 x MCP article — testing Gemma 4 as an MCP agent from a phone