Claude Code as a back-office: wiring Drive, Gmail and Trello to actually run your company

Three tools, three versions of the truth

In a small company, reality is scattered across three places.

Drive holds the documents - what you produced. Gmail holds the commitments - what you said, promised, sent, received. Trello holds the intentions - what you think you're working on.

And these three versions diverge. Always.

I figured this out by wiring Claude Code into the three tools of the e-health startup I co-run. The starting goal was modest: tidy up some files. I didn't just tidy up files. A grant application everyone believed was submitted? Sitting in Gmail drafts. No recipient, no attachments, for three days. A follow-up to a funder? Never arrived: the address was dead and the bounce had been sleeping in the inbox for weeks, buried between newsletters.

Here's how each piece connects, with the traps I hit along the way. There were several.

Google Drive: rclone over MCP

First instinct: look for a Drive MCP server. Wrong instinct. For bulk document management (moving, renaming, syncing hundreds of files), a conversational protocol is the worst possible tool. rclone has been doing this for a decade, server-side, with transfers that never touch your machine.

rclone config   # "company" remote, type drive, OAuth in the browser

The empty My Drive trap

First real wall, and it's a sneaky one. Right after authenticating:

rclone lsd company:
# ... nothing.

Nothing. I almost concluded the account had access to nothing and moved on. Big mistake: the documents live elsewhere, in two spaces rclone doesn't show by default.

# Folders shared with the account
rclone lsd company: --drive-shared-with-me

# Shared Drives (formerly "Team Drives")
rclone backend drives company:
# → [{"id": "0AxXXXXXXXXXXXX", "name": "DOCUMENTS"}]

# And to work inside one, the connection string syntax:
rclone tree "company,team_drive=0AxXXXXXXXXXXXX:" --level 2

In a company that uses Shared Drives (and every company should), everyone's My Drive is a desert. If you conclude "the Drive is unreachable" at this point, you're missing everything.

Reorganizing 107 files without downloading a single one

Once access was sorted, Claude took inventory. Not pretty: 60% of files dumped in a "to sort" folder, duplicates, four versions of the same strategy document, and filenames with line breaks inside the name (thanks, Google Docs exports).

The reorganization ran purely server-side: a script mapping each file to a clean kebab-case tree with rclone moveto. 107 moves, zero bytes downloaded. And since the Drive tree now mirrors the local git repo exactly, syncing is a one-liner:

rclone copy "company,team_drive=0AxXXXXXXXXXXXX:" ./repo-docs/ -u

The -u (update) flag isn't decorative: it never overwrites a local file that's newer. When someone is editing a document in Word, they're right. Not the Drive.

The mistake I made: rclone link

Confession time. To share a document with my business partner, I used rclone link. Handy, it returns a URL.

Except that URL works because the command just created an "anyone with the link" permission on the file. A public share, silent, on an internal document. I noticed an hour later, thanks to the "External" badge in the Drive UI. One full hour during which a company document was readable by anyone holding the URL. Nobody had it, we checked. The cold sweat was real though.

The cleanup: delete the permission via the API, then audit permissions across all 209 items in the Drive (the API starts throwing 403 rate-limit errors after ~100 calls, bring a backoff). Verdict: one other publicly exposed file, a forgotten share from way back. Revoked too.

Rule carved into Claude's memory ever since: never rclone link, never an anyone permission. To reference a file, build the URL from its ID. It only works for Drive members, which is exactly what you want.

Gmail: Google's official MCP... and its trap

Google shipped an official Gmail MCP server (https://gmailmcp.googleapis.com/mcp/v1). On paper it's the royal road: clean OAuth, search and draft tools, no third-party code wandering around with full mailbox access.

The GCP side: enable gmail.googleapis.com and gmailmcp.googleapis.com, create a "Web application" OAuth client with a fixed-port redirect URI (Claude Code uses a random port by default, Google demands an exact match):

claude mcp add --transport http \
  --client-id YOUR_CLIENT_ID --client-secret \
  --callback-port 8765 \
  gmail https://gmailmcp.googleapis.com/mcp/v1

Authenticate via /mcp, browser opens, all good. And then:

The caller does not have permission

On every tool. Even list_labels. The kind of message that gives you strictly nothing to work with.

The scope that poisons everything

Two hours of debugging. Two hours I'm not getting back, so here's the answer served on a plate: Google's MCP server advertises five scopes, including gmail.metadata. And the Gmail API has a non-negotiable rule - as soon as a token carries that scope, the q search parameter and the FULL format are rejected. Even if the token also carries gmail.readonly, which allows them. The most restrictive scope wins. The token is poisoned at the root.

I tried scope pinning in the Claude Code config (oauth.scopes, available since v2.1.64). The running session ignored it and requested all five scopes again. Oh well.

The fix that works: bypass the MCP and run your own OAuth flow with minimal scopes. It's 40 lines of Python. A local HTTP listener on the callback port, the authorization URL with scope=gmail.readonly and nothing else, access_type=offline to get a refresh token, code exchange, save.

url = "https://accounts.google.com/o/oauth2/v2/auth?" + urlencode({
    "client_id": CLIENT_ID,
    "redirect_uri": "http://localhost:8765/callback",
    "response_type": "code",
    "scope": "https://www.googleapis.com/auth/gmail.readonly",
    "access_type": "offline",
    "prompt": "consent",
})

The resulting token does exactly what you ask. Search, full message reads, attachments: everything works through direct REST calls. A second token with gmail.compose added unlocks draft creation, and the refresh token makes the whole thing permanent.

What Gmail reveals when you actually dig

This is where it gets interesting. Three findings, from mundane to embarrassing.

The attachments. One has:attachment filename:pdf OR filename:docx query, and Claude inventoried 46 messages carrying documents. 38 files missing from the Drive: studies we paid consultancies for, application templates sent by funders, signed agreements. All of it asleep in email threads.

The ghost drafts. While checking the progress of a grant application, Claude noticed something odd about the "Complete application submission" email: labelIds: ['DRAFT']. No recipient. No attachments. The application everyone believed was submitted had never left.

The bounces. The query worth its weight in gold:

from:(mailer-daemon OR postmaster) OR subject:("Delivery Status Notification")

21 results. Twenty-one emails that never arrived, with failure notifications nobody had processed. Among them: a loan application (wrong address), a first contact with a national reference hospital (the hospital's domain had migrated), a grant request (dead generic mailbox). Steps counted as "done" that had simply... never existed for the recipient.

A sent email is not a delivered email. That check is now part of every audit.

Trello: the easiest of the three

No official MCP (Atlassian shipped nothing for Trello), but delorenj's community server is solid:

claude mcp add trello -s user \
  -e TRELLO_API_KEY=xxx -e TRELLO_TOKEN=xxx \
  -e TRELLO_BOARD_ID=xxxxxxxx \
  -- npx -y @delorenj/mcp-server-trello

The API key comes from trello.com/power-ups/admin (create a Power-Up, generate the token manually). No OAuth: the token grants access to every board on the account. Blunt, but that's how it is.

The coherence audit: where the three sources meet

The tracking board showed 9 cards "in progress" and 15 "waiting". The mailbox told a different story. The verification logic, card by card:

The outcome:

• 4 "in progress" cards whose action had been finished for weeks
• 3 "waiting" cards that were actually unblocked: the awaited certificate had arrived, the contact had replied
• 1 card moved to "done"... wrongly. The email had bounced. Corrected back the other way once the bounce check entered the loop
• 4 missing cards for very real events: a contract signed via Docusign, a meeting to prepare, the infamous never-sent draft

Every card move comes with a sourced comment ("email sent on X to Y, reply received on Z") and every card Claude creates carries a [CLAUDE] prefix. You always know who wrote what. Add checklists with already-completed steps ticked, and the board finally displays progress that matches reality.

The rules that keep the system livable

Plugging an AI into a company's mailbox and documents is not something you do without guardrails. Ours were forged in one day of incidents more or less avoided:

1. No automatic sending. Claude writes drafts, full stop. Emails wait in the Drafts folder for a human to proofread and hit send.
2. No public documents. No rclone link, no anyone permission, a permissions audit on every pass.
3. Traceability everywhere. [CLAUDE] prefix on cards, sourced comments, auto-creation dates in descriptions.
4. Minimal scopes. gmail.readonly to read, gmail.compose for drafts. No gmail.send. What a token doesn't allow can't go wrong, even on a hallucination.
5. Memory compounds. Every solved trap (the poisoned scope, the empty My Drive, the dead addresses) gets written into Claude Code's persistent memory.

That last point is the most underrated one. The difference between a gimmick and a management tool is that by the third audit, Claude knows which addresses bounce, the sync procedure, the naming conventions and the house rules. It doesn't rediscover. It verifies.

What it changes, concretely

One morning of setup, two thirds of it spent debugging OAuth, let's be honest. And since then: "sync the Drive", "any undelivered emails?", "is the board consistent with reality?", "pre-draft the follow-ups". Sentences that produce verifiable work in minutes.

The most valuable part isn't the time saved on tidying. It's what cross-referencing surfaces: the gaps between what you believe and what is. The draft application, the 21 bounces, the lying cards - none of these problems was visible from inside any single tool. You had to be sitting in the middle.

Three connectors, tight scopes, clear rules, a memory that compounds. The rest is conversation.