Extensions: connecting Gemini to apps

Extensions (now "Apps"): connecting Gemini to Google services

Ask Gemini "summarize the key points from this YouTube video" and paste a link, and it will actually read the transcript and answer, no copy-paste required. That single move (reaching out to a live Google service to get real data) is what the app's connectors do. They turn Gemini from something that talks about the world into something that can pull from it.

Naming note: Google has been retiring the "Extensions" label in the Gemini app and now calls these connectors Apps (sometimes "connected apps"). You will still see the older "Extensions" wording in some places and in older docs. The behavior is the same: a connector that lets Gemini reachreachThe number of unique people exposed to your message in a given period. Unlike impressions, reach counts each person once, no matter how often they see it.View full definition → a named Google service in real time. This lesson uses "Apps" for the current UI and notes where the old term still appears.

What these connectors actually are

An App (formerly Extension) is a connector that lets the Gemini app call a specific service on your behalf, in real time, inside a normal conversation. When a connector is on and your prompt clearly needs it, Gemini routes part of the request to that service, gets structured data back, and weaves it into the answer.

The Google-built connectors available in the Gemini app include:

• Google Workspace (Gmail, Drive, Docs): search and summarize your own content.
• YouTube: pull facts, summaries, and timestamps from a specific video.
• Google Maps: directions, places, travel time.
• Google Flights and Google Hotels: live travel options.

This is different from grounding with Google Search, which fetches public web results to reduce hallucinationhallucinationA hallucination is when an AI model generates output that is fluent and confident but factually wrong, fabricated, or unsupported by its source data.View full definition →. Apps reach into *named services* (often your private data, like your own Drive) and can return service-specific structure. Search grounding answers "what is true on the open web." Apps answer "what is in this video / my Drive / this route."

Note: connector names and availability shift over time and by account type. The current list lives in the Gemini Apps Help Center, which is the source of truth.

A concrete run: YouTube and Drive in one prompt

Say you saved a conference talk to "watch later" and also have a strategy doc in Drive. You want both reconciled.

Prompt:

Summarize the 5 main arguments in this talk: youtube.com/watch?v=EXAMPLE, then find my Drive doc named "2026 Roadmap" and tell me which arguments contradict our plan.

Here is what happens under the hood:

1. Gemini detects two intents: a YouTube lookup and a Drive lookup.
2. The @YouTube connector fetches the video's transcript and metadata.
3. The @Google Workspace connector searches *your* Drive for the file "2026 Roadmap."
4. Gemini fuses both sources and produces the comparison.

You can force a tool explicitly by typing @ in the Gemini app, which opens the picker. @YouTube summarize this: <link> is unambiguous and tends to be more reliable than hoping Gemini infers it.

One real constraint worth internalizing: the Workspace connector searches content *you already own and can access*. It is bounded by your Google account permissions. It will not surface a colleague's private file you cannot open. This is the security model, not a limitation to work around.

Turning them on

These connectors are managed per account, not per chat.

1. Open the Gemini app.
2. Go to Settings → Apps (older builds may still label this Extensions).
3. Toggle each one (YouTube, Workspace, Maps, Flights, Hotels) on or off.

When you enable the Workspace connector the first time, you grant Gemini permission to read your Gmail, Drive, and Docs content for the purpose of answering your prompts. You can revoke this at any time from the same panel or from your Google Account permissions page.

Two things that trip people up:

• An enabled connector is not always invoked. Gemini only calls it when your prompt needs it. Vague prompts get vague behavior. Be explicit.
• Workspace content connectors may be unavailable on some enterprise accounts depending on admin policy. If @Gmail returns nothing, check with your Workspace admin before assuming it is broken.

In the app vs. building your own

The Gemini *app* connectors above are pre-built, consumer-facing, and managed with toggles. But the real depth for a builder is that **the *same idea* (let the model call live tools) is something you implement yourself through the APIAPIApplication Programming Interface: a standardised interface that lets applications communicate and exchange data without knowing each other's internal workings.View full definition →.** Knowing where the line sits matters.

In the app: Gems can use these connectors too

A Gem (your saved custom assistant) operates inside the Gemini app, so it inherits the connectors you have enabled. A "Travel Planner" Gem can lean on Maps and Flights without you re-enabling anything per chat. **The Gem's instructions shape *how* it uses them; the account toggle controls *whether* they exist.**

In the API: you build the connection

When you move to Google AI Studio and the Gemini API, you do not get the app's pre-built YouTube or Drive connectors. Instead you wire up capabilities yourself. Two mechanisms matter:

1. Built-in tools. The API exposes first-party tools you switch on, most notably grounding with Google Search and code execution. This is config, not custom code:

from google import genai
from google.genai import types

client = genai.Client()

response = client.models.generate_content(
    model="gemini-2.5-flash",
    contents="What were Google's most recent AI announcements?",
    config=types.GenerateContentConfig(
        tools=[types.Tool(google_search=types.GoogleSearch())]
    ),
)

print(response.text)

That google_search tool is the API equivalent of the app's search grounding: the model decides when to query, fetches live results, and cites them. You read the model tier from the model string. Flash is the fast, cheaper tier for high-volume tool calls; Pro is the stronger reasoner for complex multi-step tool use.

1. Function calling (your own tools). This is how you connect Gemini to *any* app or API you control: your CRMCRMCustomer Relationship Management: software and strategy to manage and analyse customer interactions throughout their lifecycle.View full definition →, an internal inventory service, a payments system. You describe a function; the model decides when to call it and with what arguments; your code runs it and returns the result.

from google import genai
from google.genai import types

def get_order_status(order_id: str) -> dict:
    # Your real backend call goes here.
    return {"order_id": order_id, "status": "shipped", "eta": "2026-03-14"}

client = genai.Client()
chat = client.chats.create(
    model="gemini-2.5-flash",
    config=types.GenerateContentConfig(tools=[get_order_status]),
)

reply = chat.send_message("Where is order A-2291?")
print(reply.text)

The SDK reads your function's signature and docstring to build the tool schemaschemaA schema is the formal blueprint that defines how data is structured, named, typed, and related within a database, file, or message.View full definition → automatically, calls get_order_status("A-2291") when needed, and feeds the result back into the conversation. *This* is the building block behind every "Gemini that does things" you will ship. The app's Maps connector is just a polished, hosted version of the same pattern.

Scaling up: from a single tool to an agent platform

Function calling is one tool, one turn. Real systems need many tools, memory, and multi-step planning. Google's stack gives you escalating options.

Apps Script: automation inside Workspace itself

If your "app" *is* Google Workspace (a Sheet that should email a summary, a Doc that triggers a workflow), Apps Script lets you call the Gemini API from inside the Workspace environment with a UrlFetchApp request or the Vertex AI integration. This is the lowest-friction way to give a spreadsheet live AI behavior without standing up servers.

Agent development kit (ADK)

The Agent Development Kit is Google's open-source framework for building agents that orchestrate multiple tools, maintain state across steps, and can hand off to other agents. Where function calling is "model calls one function," ADK is "agent runs a plan that may call ten functions, retry, and delegate." If you are building the production version of a multi-tool assistant, ADK is the structured way to do it.

Vertex AI: the enterprise deployment surface

Vertex AI is where these agents go to live at scale: managed endpoints, governance, logging, IAM-based access control, and connectors to enterprise data. The mental model:

• AI Studio + Gemini API: prototype, experiment, single-developer speed.
• ADK: structure your multi-tool agent logic.
• Vertex AI: deploy with enterprise security, monitoring, and scale.

Gemini CLI and code assist

Two more "connectors in spirit" worth naming. Gemini CLI brings the model into your terminal so it can read your filesystem, run commands, and act on a local project. Gemini Code Assist embeds it in your IDE. Both are tool-using Gemini connected to a developer's working environment rather than to consumer apps, and both are useful when the "live data" you want Gemini to reach is your own codebase.

When to use which connection

A quick decision guide:

• You want Gemini to answer from your Drive, a video, or Maps, right now, no code: use the app connectors (toggle them on in Settings, use @).
• You want a reusable assistant that uses those services: build a Gem; it inherits enabled connectors.
• You want fresh public web facts in your own product: use the API's Google Search grounding tool.
• You want Gemini to call your own backend or API: use function calling.
• You want a multi-step agent across many tools, deployed for a team: ADK plus Vertex AI.

The through-line: every one of these is the same core capability (a model that can decide to call a tool and use the result), exposed at a different altitude. Learn it once at the app level, recognize it everywhere else.

Key Takeaways

• App connectors reach named services, grounding reaches the web. Use @YouTube, @Gmail, or @Maps explicitly when you need service-specific or private data; use search grounding for fresh public facts.
• Enable them per account in Settings → Apps (still labeled "Extensions" in some builds), and remember that an enabled connector is only *invoked* when your prompt clearly needs it. Be explicit, especially with the @ picker.
• Workspace connectors are bounded by your real permissions, so they will never expose data you cannot already access. Check enterprise admin policy if @Gmail or @Drive returns nothing.
• The API equivalent of an app connector is a tool: built-in tools (search, code execution) are config, and function calling connects Gemini to any app you control.
• Scale by altitude: prototype with the Gemini API in AI Studio, structure multi-tool agents with the ADK, and deploy with governance on Vertex AI.