Connected Apps Platform MCP server developer guide

Connected Apps help users access content and services across a broad range of journeys, within applicable Google products.

Connected Apps provide the following benefits.

• Control over which features and services to make available to the Connected Apps Platform: You maintain granular control over the integration scope.
• Brand attribution and discovery: When you select a Google surface to integrate with your app, your brand is front and center.
• Increased potential for engagement: Connected Apps help users access your service for actions when they need them, increasing the likelihood of higher user engagement and satisfaction.

Note: Your connected app can be explicitly triggered with @<connected appname> or mentioning the <connected app name> in the query and remains in context for relevant user prompts in the session.

Integrations options

An MCP server and AppFunctions are the two primary, complementary ways to integrate your app's capabilities across applicable Google products.

• MCP server (described in this developer guide):

  • This is our recommended default path for foundational, cross-platform capabilities.
  • The MCP server lets you scale across Android, iOS, and the Web. If you have existing Web APIs or a remote MCP server, you can leverage them using our MCP server specification. This is your path to maximum reach with minimal overhead.

• Android MCP (dev guide)

  • AppFunctions are designed for creating deeper, built-in Android experiences. AppFunctions can take advantage of on-device content to resolve intents through deep integration with the Android OS and system UI surfaces.
  • Actions that require context and tight integration with the current state of an app.
  • Support is available through a Jetpack library.

End-to-end process

This guide outlines the end-to-end process for building, testing, registering, and deploying a remote Model Context Protocol (MCP) server to integrate your services across applicable Google products.

Phase 1: Build — develop your remote MCP server

When you're developing a remote MCP server using the Model Context Protocol specification, we recommend establishing structured system instructions, explicit safety annotations, clear schema definitions, and UI metadata bindings.

• Explicit server instructions: When initializing your MCP server, define clear server instructions describing your domain and capabilities. Because AI models rely on these server instructions to recognize when to delegate tasks to your server, we strongly recommend providing clear server instructions to facilitate accurate model routing across applicable Google products.
• Safety & execution tool annotations: Declare explicit protocol annotations for every tool, such as marking read-only query operations with readOnlyHint=True or state-changing/destructive actions with destructiveHint=True. You can also mark operations that require confirmations in the Google Connected Console.
• Strongly typed schemas & semantic docstrings: Provide explicit argument types and detailed parameter docstrings. Document expected field values clearly (such as allowed category filters or location parameters) to optimize model tool-calling accuracy.
• UI resource metadata bindings (optional): Bind tool outputs directly to custom UI resources by defining metadata annotations (e.g., meta={"ui": {"resourceUri": "ui://..."}}). If provided, this instructs the client to render rich, branded, interactive UI widgets in secure sandboxed iframes directly within the conversational interface.

Phase 2: Validate — test locally with MCP Inspector

Before hosting your service remotely, validate your tool declarations and interface rendering in a local sandbox environment.

• Local server initialization: Run your remote MCP server locally on your development machine.
• Inspector tool validation: Connect to the local server using the MCP Inspector tool (npx @modelcontextprotocol/inspector).
• Execution & UI verification: Invoke individual tools, inspect raw JSON input/output payloads, and confirm that custom UI resources render as expected directly within your web browser.

Phase 3: Deploy and test with Gemini Developer mode

You need to deploy your MCP server to a public HTTPS endpoint to make it available remotely to test in Gemini Developer Mode. You can host it on any cloud provider or infrastructure you prefer.

• Public HTTPS hosting: Host your remote MCP server on a public HTTPS endpoint. For hosting on Google Cloud, deploy using Google Cloud Run, using gcloud run deploy <server-name>.

The next step is to validate your public endpoint in Gemini Developer Mode.

• Live Gemini verification: Test live tool execution using Gemini Developer Mode. Use the built-in debugging tabs—including Event Log, Tool Schemas, Environment simulation (date, time, location), and Authentication settings—to verify model responses before requesting final approval and publishing.

Phase 4: Register — configure using the Google Connected Console

After validating local execution, submit your access application and register your integration details in the Google Connected Console.

• Access request: Request access using the interest form.
• Console configuration & publishing: In the Google Connected Console, define your app details, configure authentication and endpoints, discover tools, manage preview environments and testers, and submit your application for review and publication. Read the guide.