Integration guide

Gmail integration for AI agents and workflows

Swfte Studio has a Gmail node. Its shipped data shows three read actions: list messages, get a message in full and list labels. It shows no send action, so a Gmail workflow built from this data reads a mailbox and leaves replies to a person.

Gmail does not have an entry of its own in Swfte’s integration catalogue, which lists a single Google entry in the miscellaneous category. The Gmail node is visible in the shipped workflow templates, and that is the evidence used on this page. The MCP tool list has no Gmail server either, so this is a workflow node and not an MCP integration.

Built in Swfte Studio, run as a governed workflow, and held to the same rules as any governed agent.

Gmail at a glance

Catalogue
No entry of its own
Actions in the shipped data
3 (3 read, 0 write)
Credential type shown
gmailOAuth2Api
MCP server
None in the MCP tool list
Shipped templates that use it
Gmail Email Workflow

What you can do with Gmail

Every action below is read from a node in a shipped workflow template. Nothing is listed that the data does not show.

Gmail actions in the shipped workflow templates
ActionTypeOperationWhat the data shows
List MessagesReadmessage.getAllLists messages. The shipped template asks for ten and filters to the INBOX label.
Get First MessageReadmessage.getGets one message by its id, in full format.
Get LabelsReadlabel.getAllLists the labels in the mailbox.

All three are reads. No action in the shipped data sends, drafts, labels or deletes a message, even though the template’s description mentions sending a draft. Plan on a person doing the sending.

The template starts from a manual trigger. New-mail events are not in the data: <Gmail trigger events - founder to fill>.

A mailbox is the most personal data most workflows touch

Email carries customer details, contracts, invoices, passwords sent in error and conversations that were never meant to be summarised. A workflow that lists messages reads real people’s words, and an agent that sends a model the full text of a message moves those words to the model provider.

The shipped template is cautious in useful ways. It lists ten messages from the inbox label, reads one in full and lists the labels. That is enough to build triage and summaries. It is also a short step from there to reading far more than you meant to, which is why the label and the limit are worth keeping explicit in every Gmail workflow you build.

How to connect Gmail

The shipped template names the credential type gmailOAuth2Api, an OAuth 2 connection to a Google account.

  1. 01

    Use a shared mailbox where you can

    Connect a shared or service mailbox, such as a support address, rather than a person’s own inbox. The workflow then reads only mail that was meant for a team.

  2. 02

    Authorise with the least access

    Complete the OAuth sign-in and read which permissions it asks for. The data does not list them: <Gmail OAuth scopes - founder to fill>.

  3. 03

    Keep the label and the limit

    Start from the INBOX label and a small limit, as the shipped template does, and widen only with a reason.

  4. 04

    Gate what leaves

    Anything a model drafts goes to a person through a human-input step before it is used.

Three governed Gmail workflows to build in Studio

Each has a label. A starting point builds on a shipped template, which is an integration test with no approval step. A design is intent only.

Inbox summary for a shared mailbox

Starting point

Builds on the shipped template “Gmail Email Workflow” (6 nodes), which you can find in the template library.

Give a team a morning read of what arrived, grouped by label, with the mailbox left untouched.

  1. List the latest messages from the inbox label.
  2. Get the full text of the ones the summary needs, and not all of them.
  3. A policy rule redacts card numbers and similar patterns before the text reaches a model.
  4. An LLM node writes the summary, and an output step delivers it to the team.

Where the approval sits. A read-only run needs no approval, but the redaction and the choice of recipients are the controls.

Reply suggestions that a person sends

Designed

Draft a reply for the person who owns a message, and stop there.

  1. Get the message in full.
  2. An agent drafts a reply from the message and an approved set of standard answers.
  3. A human-input step shows the draft to the owner, who approves or rejects it.
  4. The approved text goes back to the owner as output, to paste into Gmail themselves.

Where the approval sits. The approval is on the draft, and sending stays manual because the shipped data has no send action. If a send action is ever added, require an approval before it runs.

Label audit for a support mailbox

Designed

Check that the labels a team relies on still exist, before an automation depends on them.

  1. List the labels with the get-labels action.
  2. A code node checks them against the list the team agreed.
  3. Missing or unexpected labels go to a human-input step for the mailbox owner.
  4. The result is recorded as output. Nothing is changed in Gmail.

Where the approval sits. The approval here is a confirmation that the owner has seen the differences. There is no write to approve.

Shipped template
A governed template with its approval step already in it ships in the platform.
Starting point
A shipped template runs the same actions. It is an integration test with no approval step, so you add the gate.
Designed
Design intent. It uses the actions listed above plus generic nodes, and nothing has been built as a template.

Approvals and records for Gmail

Reading a mailbox is a decision about people’s data, even when nothing is written.

Needs a person’s approval

  • Connecting a personal mailbox instead of a shared one.
  • Sending any message text to a model when it may contain personal data.
  • Widening beyond the INBOX label or the agreed limit.

Can run without one

  • Listing labels.
  • Listing recent inbox messages for a team summary that is redacted first.

What is recorded

  • Each list and get action in the run, in order.
  • The approval or rejection of every reply draft.
  • A policy decision on the message text, such as redaction before the model call.

The human-input step, the policy engine and the run ledger are built in the product, and the engine only acts on runs that have a policy attached. Google decides who may use the mailbox. Swfte decides what a workflow does with what it reads, and keeps a record.

A policy step in a design below describes the intent. The policy engine acts only on runs that have a policy attached, and a self-serve way to author policies is not something we describe as built.

Swfte’s own security position and any attestations are on the trust page. How approvals, policy and records fit together is on the governed agents page.

Comparing tools for Gmail work

These comparison pages are dated and sourced. Each says who should pick the other tool.

  • Zapier alternatives

    The Zapier comparison covers when a trigger-and-action tool is enough for mail rules.

  • Lindy alternatives

    Lindy is an AI assistant platform. The comparison covers where it fits better than a workflow builder.

  • Best automation platforms

    How automation platforms compare on governance, approvals and records, with the method shown.

Gmail questions

Is there a Gmail MCP server in Swfte?

No. The MCP tool list has eight entries and Gmail is not one of them. You reach Gmail through the Studio workflow node described here.

Can a Swfte workflow send email through Gmail?

Not with the actions in the shipped data, which are list messages, get message and list labels. The template’s description mentions a draft, but no node creates one.

How do I keep personal data out of a model’s prompt?

Attach a policy to the run that redacts the patterns you care about, read only the messages you need, and avoid sending whole threads. Redaction reduces exposure but is no substitute for deciding what the workflow should read in the first place.

Which Google account should I connect?

A shared or service mailbox for the team’s own work. The shipped template uses an OAuth 2 credential, so whoever authorises it sets the access the workflow gets.

What is recorded when a workflow reads a mailbox?

The run ledger records the policy decisions, approvals and actions for the run, so you can see that a list or get action ran and who approved any draft that followed. It is a record of what the workflow did, kept apart from Gmail.

Build a governed Gmail workflow

Begin with a read-only workflow on a test account, then add one write with an approval in front of it.

Build this in Studio

Describe what you need in plain language. Studio builds the agents and workflows, and you keep every version.