+170 XP

Real workflows with connectors

Connectors get powerful when you chain them: Claude reads your calendar, sees you have three meetings tomorrow, then pulls the relevant Drive docs and recent emails to brief you on each one. That is one request, multiple tools, one clean answer. This lesson is about making that orchestration reliable instead of accidental.

You already know what a connector is at the concept level. Here we go deep on **how Claude *decides* which connector to use, how to phrase requests so it reaches for the right ones**, and how to build a repeatable "prepare me for tomorrow" workflow.

How Claude picks a tool

When you enable connectors on Claude.ai (Settings, then Connectors), each one registers a set of tools with descriptions. A Google Calendar connector exposes things like "list events" and "get event details". A Drive connector exposes "search files" and "read file". Under the hood this is the same Model Context Protocol wiring you met earlier: each connector is an MCP server, and the tool descriptions are what Claude reads to decide what to call.

That last point matters more than people expect. Claude is not psychic about your intent. It matches your words against tool descriptions. If your request is vague, it guesses. If your request names the work clearly, it routes correctly.

Two requests, same goal, very different reliability:

  • Weak: "What's going on tomorrow?"
  • Strong: "Look at my calendar for tomorrow, then for each meeting search my Drive and recent emails for related documents."

The second version tells Claude the sequence (calendar first, then search per meeting) and the sources (Drive, email). You are not writing code, but you are giving an execution plan in plain English.

Connect what you actually need

Before the workflow runs, make sure the right connectors are enabled and authorized. For the calendar prep workflow you typically want:

  • A calendar connector (Google Calendar via the Google Workspace connector)
  • A documents connector (Google Drive)
  • Optionally an email connector (Gmail) for thread context

You enable these from the connector directory on Claude.ai. Anthropic maintains a growing set of official and partner connectors, and you can browse them in the Claude connectors directory. Each one runs through its own OAuth consent, so you grant access per connector, and you can revoke any of them later without touching the others.

The "prepare me for tomorrow" workflow

Here is the full request, written the way it actually performs well. Notice it is structured but conversational.

Pull all my Google Calendar events for tomorrow. For each meeting, give me: the time, who's attending, and a one-paragraph prep brief. To build each brief, search my Google Drive for documents related to the meeting topic or attendees, and check my recent Gmail threads with those attendees. Flag any meeting where you couldn't find supporting material so I know to prep it manually.

What Claude does, in order:

  1. Calls the calendar tool, scoped to tomorrow.
  2. Reads back the event list (titles, times, attendees).
  3. For each event, issues a Drive search using the title and attendee names as query terms.
  4. Optionally checks Gmail for recent threads with those people.
  5. Synthesizes a brief per meeting, and explicitly flags gaps.

The "flag any meeting where you couldn't find supporting material" line is doing real work. Without it, Claude tends to fill silence with confident guesses. With it, you get an honest map of what is covered and what is not.

Why ordering instructions matters

Connectors run as a loop, not a single shot. Claude calls a tool, reads the result, then decides the next call based on what came back. That is why "calendar first, then search per meeting" works: the calendar result becomes the input that shapes every Drive query.

If you flip the order ("search my Drive, then check my calendar"), Claude has nothing to search *for* yet, so it either asks you to clarify or produces a generic dump. Sequence your request the way the data actually flows.

Tightening the brief with projects and styles

Run this workflow once and it works. Run it every morning and you will want it consistent. Two features you already met earlier make it repeatable.

Projects let you save the workflow context. Create a Project called "Daily Prep", drop in standing context (your role, your team's names, recurring clients, what a good brief looks like for you), and the connectors stay available inside it. Now your morning prompt can be short: "Run my standard tomorrow prep." The Project carries the rest.

Styles control the *shape* of the output. If you define a Style that says "use tight bullet points, lead with the decision I need to make, keep each brief under 80 words," every brief comes back in that format without you restating it. Style governs voice and structure; the Project governs context and connectors. They stack.

A practical setup:

text
Project: Daily Prep
  Custom instructions:
    - I'm a product lead at Acme. My recurring stakeholders are Dana (design),
      Raj (eng), and the Northwind client account.
    - For each meeting, lead with "Decision needed:" or "FYI only:".
    - When you find a Drive doc, cite its title so I can open it.
  Connectors enabled: Google Calendar, Google Drive, Gmail
  Style applied: "Exec Brief" (terse bullets, decision-first)

That is not code. It is the configuration you set once in the Claude.ai UI so the daily prompt stays one line.

Connect Claude to Your Apps with Connectors

Watch on YouTube

When you want this to run without you

So far you are still typing the morning prompt. The natural next question: can this just *happen* at 7am? Today, connectors on Claude.ai are interactive, meaning they run inside a conversation you start. There is no built-in "fire this at 7am every day" scheduler in the chat app itself.

That is the boundary where you graduate from the Claude app to the Claude Agent SDK: Anthropic's toolkit for building agents that run your own loops, call the same kind of tools (including MCP servers), and operate on a schedule or trigger you control. You met the SDK concept earlier; the relevant point here is that the *exact same connector logic* you prototyped in the chat moves over cleanly, because both speak MCP.

A minimal sketch of the same calendar prep as a scheduled agent, using the Messages API with MCP servers attached:

python
import anthropic

client = anthropic.Anthropic()

response = client.beta.messages.create(
    model="claude-sonnet-4-5",
    max_tokens=2048,
    mcp_servers=[
        {"type": "url", "name": "gcal", "url": "https://mcp.example.com/calendar"},
        {"type": "url", "name": "gdrive", "url": "https://mcp.example.com/drive"},
    ],
    messages=[{
        "role": "user",
        "content": (
            "Pull my calendar events for tomorrow. For each meeting, search "
            "Drive for related docs and write a one-paragraph prep brief. "
            "Flag any meeting with no supporting material."
        ),
    }],
    betas=["mcp-client-2025-04-04"],
)

print(response.content)

Notice the prompt is nearly identical to the chat version. The skill you built by phrasing a good interactive request transfers directly to the API. Check the current model names and the exact MCP beta header in the Messages API docs before you ship, since those evolve.

Knowledge check

1. According to the lesson, how does Claude actually decide which connector tool to use for a request?

2. Why is the request 'Look at my calendar for tomorrow, then for each meeting search my Drive and recent emails for related documents' considered stronger than 'What's going on tomorrow?'

3. What is the underlying technical relationship between a Claude connector and the Model Context Protocol (MCP)?

MULTIPLE CHOICE

4. Select ALL statements that correctly describe how connector authorization works on Claude.ai.

Select all the correct answers.

MULTIPLE CHOICE

5. For the 'prepare me for tomorrow' workflow, select ALL connectors the lesson recommends enabling.

Select all the correct answers.

Debugging a chain that misbehaves

Multi-connector workflows fail in predictable ways. Here is how to read the symptoms.

Claude only used one connector. Usually the request did not name the second source, or the first result looked "complete enough" to stop. Fix it by being explicit: "For *each* event, also search Drive," with the word "each" and the second source named.

Claude searched Drive with bad query terms. It used the literal meeting title ("Sync") and found nothing useful. Give it better hooks: "Use the attendee names and the project name in the description as search terms, not just the meeting title."

Claude invented a doc that does not exist. This is the dangerous one. It means a search returned nothing and the model filled the gap. Your "flag meetings with no supporting material" instruction is the guardrail. Keep it in every prep prompt.

A connector returned an auth error. OAuth tokens expire. Reauthorize from Settings, then Connectors. Claude will usually tell you which connector failed; if it does not, ask "which connector calls failed and why?" and it will report the tool errors directly.

Scope your permissions like an adult

Each connector you enable is a standing grant of access. The calendar prep workflow only needs read access to calendar, Drive, and email. It never needs to create or delete anything. When a connector offers granular scopes during OAuth, take the read-only path. You can always widen later. A connector that can only read cannot accidentally send an email to the wrong client while it is "helping."

Pushing the pattern further

Once "prepare me for tomorrow" is solid, the same chaining pattern extends naturally:

  • Pre-read packets: "For my 2pm with Northwind, pull the last three Drive docs they touched and the most recent email thread, and summarize where we left off."
  • Follow-up drafting: after a meeting, "Find today's notes doc in Drive, then draft follow-up emails to each attendee with their action items." (Note this one needs *write* scope on email, so enable it deliberately.)
  • Cross-source reconciliation: "Compare the dates in the project plan doc against the milestones on my calendar and tell me what's out of sync."

Each of these is the same loop: one connector produces the anchor data, another connector enriches it, Claude synthesizes. The only thing that changes is which sources you name and in what order.

Key Takeaways

  • Name the sequence and the sources. "Read my calendar, then for each meeting search Drive and email" routes far more reliably than "what's tomorrow look like?" Connectors are chosen by matching your words to tool descriptions.
  • Always include a gap-flag instruction. "Flag any meeting where you couldn't find supporting material" turns silent hallucination into an honest coverage report.
  • Use Projects for context, Styles for shape. Save the workflow once in a "Daily Prep" Project so your morning prompt is one line, and let a Style enforce the output format.
  • Grant read-only scopes unless you genuinely need write. A read-only connector cannot misfire actions on your behalf. Widen access only for workflows that draft or send.
  • The same prompt graduates to the Agent SDK. Interactive chat runs are great for prototyping; when you need scheduled, hands-off runs, move the identical MCP-based logic to the Messages API or Agent SDK.

What to do, from this lesson

These actions are compiled in the role's Playbook.

  • Grant read-only connector scopes and revoke tokens at the provider quarterly
  • Name the tool sequence and sources explicitly when chaining connectors
See the full action playbook →