Google Opens Its Connected Apps Platform to Every Developer

Google opened a preview of its Connected Apps Platform on Wednesday, and buried inside the announcement is the most consequential sentence of the week for anyone who builds software: developers integrate with a cloud-hosted MCP server or Android MCP using the AppFunctions APIs, then register, test, and submit their app through the Google Connected Console. One build, two surfaces - Search and the Gemini app.

For two years the question about AI agents was which models were good enough. That is settled enough to be boring. The live question is distribution: when a user asks an assistant to book a table or file an expense, whose software actually gets called? Google just turned MCP from internal plumbing into a public on-ramp - and built the gate around it.

What Google Actually Shipped

The platform, announced in a post on Google's blog, gives developers a single place to build and manage apps for Search and Gemini. The mechanics matter more than the marketing:

• Integration: connect either a cloud-hosted MCP server or an on-device Android MCP built on the AppFunctions APIs.
• Registration: the Google Connected Console handles registration, testing, and submission, with an automated review before anything goes live.
• Scope choice: before review you pick whether the app lands in Search, the Gemini app, or both.
• Telemetry: after launch you can track traffic, latency, and error rates.
• Identity: you keep control of verified logos and authenticated accounts.

Access is phased. The preview is beta for US developers on a waitlist, documented at developers.google.com/connected-apps, and Google says it will add more developers, markets, and products over the coming months.

The consumer side is already large: Google says more than 50 Connected Apps shipped across Search and Gemini, including Adobe, Experian, Localiza, and Peloton, with those Gemini integrations moving into Search over the coming weeks. Calm is the newest partner.

The Android path is the more demanding one, and its developer documentation is unusually explicit: your Play app must exist in the same developer account, each Play app can only be linked to a single Android MCP connected app, the category is fixed at creation and cannot be changed, and the app bundle must ship implemented AppFunctions. Your Play listing's languages and country targeting then determine where the connected app is even available.

MCP Won the Plug. Google Wants the Socket.

The strategic read is less about Google than about where the value moved.

A year ago "connected apps" were vendor-specific: ChatGPT had its own version, Meta was building Muse, everyone shipped a different shape. Now Google's instruction is to implement an MCP server - the protocol layer is converging while the surface layer stays contested. That is the pattern that produced the modern web: TCP/IP and HTTP stopped being differentiators, and the browser, the search index, and the app store became the tollbooths.

TechCrunch's framing is the right one - this is one of the first steps toward visibility on the agentic web, the way SEO once was for the crawler web. The difference is what "optimizing" means. In SEO you optimized a page and hoped. Here you ship a tool schema, and the surface tracks your latency and error rate in a dashboard it owns.

That has a corollary developers should not miss: the same protocol that makes you portable makes you interchangeable. If two grocery apps expose equivalent MCP tools, the assistant chooses on speed, reliability, and whatever ranking logic Google does not publish. Your differentiation moves from the landing page to the tool contract.

The Gatekeeping Nobody Has Rules For Yet

The Verge's coverage is a one-line brief, but the substance is a gap: there is no published equivalent of a ranking algorithm, no quality score you can inspect, and no ad product to buy your way in - yet.

Three unresolved questions will define this market:

Discovery. In search, being indexed was the floor and ranking was the game. Here, being listed is only the floor. Which connected app surfaces when a request is ambiguous - "get me dinner" - is a product decision inside one company, with no documented rules.

Accountability. "Verified logos and authenticated accounts" is the beginning of an answer to impersonation inside agent flows, but it is silent on liability. When the assistant places the order in the user's name, who owns the wrong one?

Sovereignty. A US-only beta with phased onboarding reproduces the access asymmetry of every platform launch. For teams outside the US, the near-term move is a cloud MCP server that can be submitted the day the waitlist opens locally, not an Android build.

Note what this competes with inside Google: the same week it began selling TPUs through Oracle to loosen Nvidia's compute grip, as we reported. Compute and distribution are being attacked in parallel - and the platform layer is where the lock-in forms.

What Builders Should Do Now

Four concrete moves for teams shipping agent-facing software:

1. Treat your MCP server as a public product, not glue. Tool names, descriptions, JSON schemas, and return shapes are your new product surface. A tool that returns a wall of unstructured text is the equivalent of a page with no title tag.

2. Instrument what the platform measures. Google tracks traffic, latency, and error rates because those are the inputs to a quality decision. Track p95 tool-call latency, failure rate by tool, and auth failures before submission, not after.

3. Design idempotent, confirmable actions. Agents retry. A "create order" tool with no idempotency key becomes a duplicate-order incident. Anything that spends money or sends a message needs an explicit confirmation step in the flow.

4. Separate the two build targets. A cloud MCP server ships today and serves Gemini and Search; AppFunctions on Android is a Play-release cycle with immutable category metadata. Ship the cloud server first.

For automation teams specifically - the ones already wiring n8n workflows into LLM front ends - the repackaging is small and the payoff is asymmetric: an internal workflow exposed as a scoped MCP server with three well-described tools can be submitted to this console the moment it opens. The work you already did for your own agent harness is the same work Google is now asking for.

What to Watch

• Published quality guidelines. If they appear, they become the closest thing this ecosystem has to a ranking document, and reading them will be a competitive advantage.
• Market expansion. Which countries follow the US, and whether the waitlist gates the cloud path too.
• Monetization. Google has not described how revenue flows; apps that complete transactions will push for affiliate or checkout economics.
• The dedup problem. Once submitting is self-service, the real fight becomes several apps declaring the same tools - and whoever writes the arbitration rule controls the agentic web.

Google did not build a feature this week. It built a registry, a review process, a telemetry system, and a brand-verification layer - the four parts of an app store. The developers who read it as "another integration partner list" will be submitting into someone else's ranking; the ones who read it as distribution will be writing their own tool contracts this quarter.