At Google I/O 2026 on May 19, the Gemini app got the most ambitious agentic upgrade in its history. The headline was the Spark runtime — a 24/7 personal agent that can act, not just draft. The detail buried under it was the connector list, and that’s the part SaaS builders need to actually plan around.
The trade press has now broadcast a long roster of “summer 2026 MCP partners” — Adobe, Samsung, Spotify, CapCut, GitHub, Notion, Slack. The reality, when you go back to Google’s own blog post, is narrower than that. Three third-party MCP connectors actually shipped on launch day: Canva, OpenTable, Instacart. The rest are roadmap-language, not committed partnerships, and the Google announcement does not name them.
Which raises the next question every SaaS PM in this space is asking on Slack right now: should I ship a Spark connector? And the answer is more interesting than the news cycle suggests, because Spark does not yet have a public submission process. The 7 connectors that join in the summer will be private partnerships, just like Canva, OpenTable, and Instacart were. There is no marketplace to apply to — yet.
This is the builder’s map. The three connectors that actually exist on May 24, what Google has and hasn’t committed to for summer, the real decision tree for SaaS PMs (“ship a Spark connector” is the wrong unit of work — “ship a generic MCP server” is the right one), and the only published directory you can actually submit to today.
What’s Actually Live on Day One (May 19–20, 2026)
The Google blog post on the Spark launch is precise: “expanding our list of Gemini connected apps with new MCP connections to Canva, OpenTable and Instacart launching today.” No other third-party MCP partners are listed in the primary text. Independent I/O recaps from SiliconANGLE, Decrypt, and Yahoo Tech agree on the same three.
| Connector | What it unlocks | Spark user impact |
|---|---|---|
| Canva | Design generation + brand asset retrieval | “Make me three banner variations for our farmers-market post” runs inside Spark instead of a separate Canva session |
| OpenTable | Restaurant reservation + table-availability | “Book a table for 4 at a Thai place near Hayes Valley Saturday at 7” lands a confirmation, not a draft email |
| Instacart | Recipe-to-cart + scheduled delivery | “Order the groceries for this lasagna recipe for Sunday morning” — Spark builds the cart, you confirm checkout |
Each of these three is a partnership Google appears to have negotiated privately ahead of the keynote. The connectors are not generic MCP endpoints you can register today — they ship with privileged access inside the Gemini app’s Spark surface.
What Google Has and Hasn’t Committed To for Summer
The most-quoted secondary list — Adobe, Samsung, Spotify, CapCut, GitHub, Notion, Slack — is not in Google’s primary text. Their I/O blog and developer keynote use carefully hedged language: “a packed roadmap of partners,” “more partners are integrating now,” “in the coming weeks.”
The named summer partners come from analyst reactions (e.g., the ChatForest I/O reaction piece and Mashable’s longform feature). The most-confidently-named ones in secondary coverage are GitHub, Notion, and Slack — but that confidence rests on commentator inference, not a published Google roadmap slide. A separate Mashable piece references “over 30 third-party applications” including Dropbox, Lyft, Uber, and Zillow — a different list entirely.
For SaaS builder planning, treat this honestly:
- Confirmed live: Canva, OpenTable, Instacart.
- Reasonable to plan around for summer: GitHub, Notion, Slack — these are the three most consistently mentioned across multiple I/O analyses and they fit the productivity-tool category Google is most likely to invest in next.
- Treat as speculation until Google confirms: Adobe, Samsung, Spotify, CapCut, Dropbox, Lyft, Uber, Zillow — these appear in commentary but not in Google’s announcement.
If you’re at Adobe or Spotify reading this and wondering what your DevRel team has actually committed to — the answer is whatever your CEO told Sundar Pichai privately. The Spark partnership pipeline is not in any developer portal today.
“Should I Ship a Spark Connector?” Is the Wrong Question
This is the part the trade press is missing. As of May 24, 2026, Google has not published a Spark MCP server submission process. The Gemini Code Assist and Gemini CLI docs show developers how to wire arbitrary MCP servers to their own Gemini instances via JSON configuration — but that’s client-side use, not a directory listing or marketplace submission for the consumer Gemini app’s Spark surface.
That means there is no application form, no review queue, no policy page, no “submit your connector here” page for Spark today. If you want your SaaS to be Connector #4, the path is direct business development with Google’s partnerships team, not a developer-portal submission.
So the actual question to ask in your next sprint-planning meeting isn’t “should we build a Spark connector?” It’s:
Should we build a generic MCP server that works across Spark (when Google opens submissions), Claude (where there’s a public directory today), Cursor (where 5,000+ community servers already run), and any new agent runtime that adopts MCP next?
The answer is almost always yes, because the MCP spec is intentionally client-agnostic. One well-designed remote MCP server works for every major agent runtime that exists today and any that will exist in the next 18 months.
The Builder’s Decision Tree
Here’s the operational version of that calculus, in 6 questions.
1. Is your product in one of Spark’s day-one categories — creative tools, food, scheduling, productivity? If yes, this is your priority quarter. Ship the MCP server now so you’re ready when Google opens the next partnership window.
2. Is your product in a category that’s plausibly part of the summer batch (dev tools, comms, docs, media)? If yes, ship in the next 30 days. Once GitHub or Slack actually launches, the comparison search (“X vs Slack Spark connector”) becomes a real SEO surface.
3. Do you already ship a public REST or GraphQL API? If yes, wrapping it as an MCP server is 2–3 days of work using the Anthropic MCP SDK or the FastMCP / OpenMCP open-source frameworks. If no, build the API first.
4. Have you already shipped an Anthropic Custom Connector? If yes, 60% of the work is already done — your existing MCP server runs in Spark too, provided you’ve exposed the right tools. If no, start with Anthropic because they actually have a public submission process (more on this below).
5. Is your user base agent-curious — are users currently asking “can ChatGPT do this in my app”? If yes, priority bump. Those users will switch to whichever agent runtime they trust, and they want your product on that surface.
6. What’s the lock-in risk if Spark doesn’t take off? Mitigation is built into the question. Don’t ship a “Spark-specific connector” — ship a generic MCP server. Then if Spark plateaus the way Google Wave / Allo / Stadia did, your work continues to pay off in Claude, Cursor, VS Code, and Windsurf.
The Only Directory You Can Actually Submit To Today
While Google’s MCP submission story is still private partnerships, Anthropic has a public Connectors Directory with an actual submission form. The April 30, 2025 help article Pre-built connectors using remote MCP lists the current launch partners — Asana, Cloudflare, Zapier, GitHub, Slack, Google Drive, Postgres, and others — and the Connectors Directory FAQ documents the review process.
What you actually do:
- Build a compliant remote MCP server following the Anthropic Build Custom Connectors guide.
- Document your MCP endpoint, OAuth handshake, and tool surface in your developer docs.
- Submit the Connectors Directory review form — Anthropic evaluates against the MCP Directory Policy on security, safety, and compatibility.
- Wait for Anthropic’s response. They review for fit; compliance with the policy doesn’t guarantee inclusion, but does guarantee they read it.
When Spark opens an equivalent submission flow — which will happen, the same way every other Google AI surface has eventually grown a developer program — your existing Anthropic-grade MCP server is most of the work already done.
In the meantime, you also get:
- Claude users (Cowork, Custom Connectors in claude.ai) seeing your tool from day one.
- Cursor users can wire your server into their IDE via the same JSON config pattern Gemini Code Assist uses.
- VS Code / Windsurf / Cline users — anyone running a modern agent client — gets compatibility for free.
Three Things This Doesn’t Solve
Honest limits before you commit a sprint.
- OAuth is doing more work than you think. The Spark / Claude / Cursor connector experience depends on the user authenticating into your service from inside the agent. If your OAuth flow doesn’t tolerate being initiated from a non-web client, you have an integration problem that no amount of MCP code fixes.
- MCP tools have to be small, atomic, and self-describing. A connector that exposes one “do_everything” endpoint is worse than one that exposes 20 sharply-named tools. The agent reasons about which tool to call before it calls anything — fuzzy tool names mean fuzzy agent behavior.
- No agent surface saves a bad product. If your SaaS is the third-best in its category, shipping an MCP server first won’t make it the best. It will just make the comparison faster.
The Bottom Line
The actual news of May 19 is that MCP is now the de facto open standard for agent-to-SaaS communication, and the runtimes that were holdouts (Google’s Gemini) have committed. The Fahd Rafi LinkedIn read of the news — “Essentially where OpenAI was in December. This was inevitable” — is correct in the long run and also true today.
For SaaS PMs, the right unit of work in Q3 is “ship one well-designed remote MCP server, submit it to Anthropic’s directory, document the endpoint for users to add manually to Spark / Cursor / VS Code.” That work pays off across every agent runtime that exists. The wrong unit of work is “build a Spark connector specifically” — there’s nowhere to submit it today, and building Spark-specific code is exactly the kind of platform-lock-in that the open MCP standard is designed to prevent.
If you want a structured walk through the MCP server build — including the OAuth handshake, the tool-naming patterns, and the directory-submission flow — the MCP Tools for SaaS Builders course on FindSkill walks through it end-to-end. The first two lessons are free.
Sources
- The Gemini app becomes more agentic — blog.google (May 18, 2026)
- Google Launches Gemini Spark — Decrypt
- Google’s new Gemini Spark is an always-on AI agent — SiliconANGLE (May 19, 2026)
- Anthropic Pre-built Connectors using Remote MCP — Anthropic Support
- Connectors Directory FAQ — Anthropic Support
- Build Custom Connectors via Remote MCP Servers — Claude Support
- Use agentic chat as a pair programmer — Google Gemini Code Assist Docs
- Introducing the Model Context Protocol — Anthropic (Nov 18, 2024)
- Model Context Protocol — modelcontextprotocol.io
- Cursor MCP Servers 2026: What They Are & How to Use Them — NxCode (March 21, 2026)
