How to submit an MCP to Gemini

To submit an app to Gemini, you register your remote MCP server as a Connected App in the Google Connected Console, test it with Gmail accounts, send it for review and then publish it yourself. This guide walks through each step, compares the process with ChatGPT and Claude, and shows where MCP Tower helps: testing your server before you submit, then measuring its traffic once it is live in the Gemini app and Search.

Google’s own guide is called Register, test, and publish, and its buttons say Send for review and Publish. I use those names for the buttons.

Key takeaways:

• The Connected Apps Platform is in preview. Sign up for access at developers.google.com/connected-apps; Google opens it in phases.
• Your server must use Streamable HTTP on one public HTTPS endpoint, and Google supports the MCP spec up to 2025-11-25.
• Category and connection type are permanent, and each published version locks its tools.
• Test before you submit. Broken OAuth and unclear tool descriptions slow a review down, and MCP Tower checks both.
• Google publishes no review time. After launch, the console reports traffic, latency and error rates for Google’s products only.

Step 1: get access to the Google Connected Console

During the preview, developers onboard through the Google Connected Console, and Google’s announcement says access opens in phases “over the coming months”. Once in, per the prerequisites, you need the “Create and manage Connected Apps” permission, and an owner or administrator must first accept the Connected Apps Terms of Service for the account.

Still deciding whether the channel is worth it? Read why Gemini Connected Apps can be a new growth channel.

Step 2: prepare to publish your MCP server to Gemini

Google’s requirements come from the prerequisites and the server optimization guide:

1. A public HTTPS endpoint using Streamable HTTP. Legacy HTTP+SSE is not supported.
2. One global endpoint per app. Country-specific domains are allowed only if you launch in that country alone.
3. Server instructions: a short description of what the server does, which Gemini adds to its system prompt.
4. Annotations on every tool: readOnlyHint for queries, destructiveHint for writes and openWorldHint for calls to outside systems. Without them, clients assume a tool is destructive.
5. JSON results serialized as text, because structuredContent is not supported yet.
6. Only model-facing tools. Servers with dozens of tools or deeply nested “mega-tool” schemas are flagged in review.

Pick the hostname you will keep and put MCP Tower in front of it now. You use it twice: before you submit, to check sign-in and tools, and after launch, to see who uses the app. MCP Tower answers on your own hostname through a CNAME, so the URL you register stays yours (if the server already runs there, move it to an origin hostname first). Google publishes IP ranges for origins that filter by source IP; behind MCP Tower, your origin sees MCP Tower instead and recognizes it by the origin secret.

Step 3: test OAuth and your tools before you submit

In my view, prompt injection is the reason Google reviews tool texts so strictly: a description goes straight into the model’s context, and the Connected Apps policy forbids descriptions that steer the model, reference other tools or return system instructions. The server optimization guide also bans any “SEO prompt that instructs the model to prefer your tool”.

When you add your server to MCP Tower, its Inspect module validates every tool and its description and gives recommendations. Fix them on your server, or change a tool’s title and description in Inspect with an override, without waiting for your developers. Do it before you sync tools in the console (Step 6): Google snapshots the tools of each version.

Authentication is the other common cause of delay. If a reviewer cannot link an account, they cannot test anything. Google’s OAuth 2.1 guide sets rules that trip up many servers:

• The authorization server metadata must include registration_endpoint, even if you support Client ID Metadata Documents, and response_types_supported must include code.
• Google uses the first discovery URL that answers at all. A 404 or 500 there stops discovery.
• PKCE uses S256.
• Do not rotate refresh tokens. Return the same one and extend its expiry (Persistent Linking).
• Allow Google’s redirect URIs on oauth-redirect.googleusercontent.com in your authorization server.

MCP Tower signs in to your server the way agents do and checks discovery, endpoints, PKCE, client registration, token exchange and refresh, then reports the first place where the flow breaks, with the fix. Three of the rules above are Google’s own, so check them by hand: a registration_endpoint even when you offer Client ID Metadata Documents, refresh tokens that do not rotate, and the allowed redirect URIs.

To try your example prompts before you register, connect your endpoint as a custom app in Gemini Apps Developer Mode, which shows each tool call in an event log.

Step 4: create the app and fill in App details

In the console, select Create app, then enter the name users will type after @. Choose a category and a connection type, MCP server. Neither can change later, and the vertical user journeys list what each category is expected to do.

Under App details you provide:

Field	Google’s rule
Icon	512 × 512 px, JPEG or PNG, up to 1 MB
Description	One sentence, under 30 words
Capabilities	At least three tasks, one per entry, no leading numbers
Example prompts	At least three; two start with the app name, one names it mid-sentence; no numbers
Links	Terms of Service and privacy policy URLs required, website optional

Write example prompts the way users talk: “Acme, show my unpaid invoices from October”, not “invoice search”.

Step 5: connect the endpoint and verify your domain

In MCP and tools setup, enter the full HTTPS URL of your endpoint, for example https://mcp.example.com/mcp. Select Download token and host the file at https://<your-domain>/.well-known/google-connected-apps. It must answer 200 directly, with no redirect and no .json suffix in the path. Then select Verify domain.

Behind MCP Tower, host the file on your origin. MCP Tower forwards every /.well-known/ request to your origin unchanged, so the file answers on your public hostname.

Step 6: set credentials and sync tools

Under “Does your server require authorization?”, choose No for a public server, machine-to-machine for OAuth client credentials, or user-delegated for the authorization code flow. For user-delegated access, Google recommends Client ID metadata or Dynamic client registration over a pre-registered client. You then sign in yourself so the console can fetch your tools.

Select Sync tools and resolve every “Must fix” error. Each version snapshots your tools, locked once you publish. Changing tools, arguments or server instructions on a live version can break the integration and get the app disabled, so ship such changes as a new version, ideally on a new versioned path such as /mcp/v2. Google’s troubleshooting page covers the common sync and OAuth errors.

Step 7: choose availability and tool settings

Set the countries or regions, languages and Google products the version is available in. For each tool, use Enable tool, and request extra context (locale or location) only when a tool needs it, since over-requesting can fail review. User confirmation required is preselected for tools annotated with destructiveHint: true.

Step 8: test with testers and prepare a test account

Once App details and MCP and tools setup are saved, the version is “Available to testers”. Add testers by email; only @gmail.com accounts are accepted, and changes can take up to 10 minutes to reach them. Testers find the app by typing @ and its name in the Gemini app, or under Settings & help, then Connected apps. Try every example prompt, both as an @ mention and as a plain question.

For user-delegated apps, give your Google representative a test account with realistic data and two-factor authentication off, plus instructions. Without them, Google may reject the app.

Step 9: submit the app for review and publish it

Select Send for review in the Releases card. The version under review is locked, and the console opens an editable draft so testers can keep previewing. Review ends in one of two states:

• Issues found: select View issues, fix them in the draft and send it again.
• Ready to publish: select Publish.

Approval does not publish the app for you. Once you select Publish, the Published card shows the version number and where it is available.

Gemini app review: how long does it take?

Google publishes no review time, and with the platform in preview I have no figure of my own yet. Each “Issues found” round adds to the wait. The policy also applies after launch: violations can lead to removal of the app or suspension of the developer account.

To update a published app, select Create new version. Your changes stay separate from the live version until that version passes review and you publish it. An MCP Tower override changes what every agent reads from your endpoint, the published Gemini version included, so use overrides freely before you sync tools and check Google’s versioning rules after you publish.

Gemini Connected Apps submission vs ChatGPT and Claude

Most teams list in more than one assistant. See my guides for ChatGPT, Claude, Muse and Perplexity.

	Gemini Connected Apps	ChatGPT plugin directory	Claude connectors directory
Where you submit	Google Connected Console (preview)	Zip upload at platform.openai.com/plugins	Developer portal form at claude.ai/directory/manage
What you write	Capabilities and example prompts	Positive and negative test cases	Use cases and example prompts
Testing	@gmail.com testers, Developer Mode	Add the server URL in ChatGPT	Custom connector in Claude
First approval	Not published	3+ months in my experience	3–4 months in my experience
Going live	You select Publish after review	You choose when to publish	You select Publish after approval
Tool changes	New version; live tools are snapshotted	Rescanned daily	Check the directory rules
Usage analytics	Traffic, latency, error rates	None	Health, tool calls, error rate, usage by tool

The biggest difference is versioning: ChatGPT picks up description changes on its next scan, while Gemini locks your tools per version, so every change goes through review.

What analytics you get after launch

After launch, Google’s announcement says, you can “track traffic, latency, and error rates” in the console. That tells you whether the app works in Google’s products. It does not show how Gemini compares with ChatGPT or Claude, which links users open from your results, or whether your server is up when nobody calls it.

That is MCP Tower’s second job, after the pre-submission checks. Every call passes through to your server while MCP Tower records which agent made it, which tool it called, how long it took and what failed. Google documents that Gemini sends User-Agent: Google on its MCP requests, and MCP Tower records the user agent and other agent signals of each call. It also tracks clicks on links your tools return, interactions inside widgets, and uptime. One dashboard covers Gemini and every other agent; for what that traffic is worth, see why Gemini Connected Apps can be a new growth channel.

Summary

1. Apply for the preview and get the permission to create Connected Apps.
2. Serve Streamable HTTP on one HTTPS endpoint, with annotations and server instructions.
3. Run MCP Tower’s tool validation and OAuth checks, and fix what they report.
4. Create the app, choosing a category and connection type you will keep.
5. Verify your domain, set credentials and sync tools.
6. Test with @gmail.com testers and hand Google a test account.
7. Select Send for review, then Publish when the app is ready.
8. Ship tool changes as new versions, and measure usage behind MCP Tower.

Test your server in MCP Tower before you send it to Gemini so the review does not stop on a sign-in bug, and keep it behind MCP Tower after launch to see how agents use it.

Open MCP Tower