← Back to Blog

Claude Code's Google Problem: Why MCP Connectors Aren't Enough

Casey Handler·

On February 24, Anthropic launched Claude Cowork with native Google Drive, Gmail, and DocuSign connectors. The pitch: connect Claude to your existing tools and let it work alongside you. It's a good idea. The execution has some problems.

I spent the last two days reading through Claude Code's GitHub issues, MCP spec discussions, and user complaints. What I found is a pattern that goes beyond bugs. MCP connectors are being asked to do something they weren't designed for: act as an authorization layer.

The connector trust problem

Anthropic wrote the original Google Drive MCP server. It's MIT-licensed, sitting in their modelcontextprotocol/servers repo. That one's fine. The problem is Claude's Connector Directory is open to any developer.

Users have noticed. In issue #23735, one user trying to get Google Drive working in Claude Code put it bluntly: "The third-party MCP servers out there don't look very legitimate, and could just be out there to steal company secrets."

That's not paranoia. When you install a third-party MCP connector that handles Google OAuth, you're handing your Google tokens to whoever wrote that connector. There's no intermediary, no token broker, no sandbox. The connector gets your credentials directly.

And then yesterday, issue #28941 dropped: Anthropic silently pushed a feature flag (tengu_claudeai_mcp_connectors) server-side that enabled third-party MCP connectors without user consent. The issue author wrote: "This is exactly the kind of behaviour that erodes user trust." Users who carefully manage their MCP configurations had new connector capabilities injected into their setup without being asked.

The bugs are real

Beyond the trust model, Claude's MCP OAuth implementation has concrete bugs that have been open for months.

The MCP spec defines how OAuth should work between clients and servers. Anthropic wrote that spec. But their own client, Claude Code, doesn't follow it correctly.

Missing scope parameter. When Claude Code initiates MCP OAuth, it doesn't always send the scope parameter in the authorization request. The MCP Inspector project tracked this in issue #580, filed in July 2025. The MCP Python SDK has a related bug (#1636) where the OAuth client registration sends the resource URL as the scope instead of the actual scopes from the protected resource metadata. That means connectors may receive tokens with wrong or missing permissions.

Cowork's own scope bug. Claude Cowork launched three days ago. Within 48 hours, users reported that Cowork mode doesn't request the user:mcp_servers scope needed for connectors to work at all. Connectors get permanently blocked because the auth flow never asks for the right permissions.

Redirect failures. Multiple users report that MCP OAuth flows break on 302 redirects after authorization. The client doesn't follow the redirect, leaving the connection permanently failed. You authorize, the browser redirects, and Claude never picks up the token.

These aren't obscure edge cases. They're in the core authentication flow of a product Anthropic just launched to enterprises.

What the connectors can't actually do

Even when the OAuth works, the Google integration has gaps. Google Sheets and Google Slides aren't natively readable through the built-in Drive connector. Drive's API returns file metadata and raw binary content, but parsing a spreadsheet's cell data or a presentation's slide content requires the Sheets and Slides APIs respectively. The connector doesn't use those APIs.

So you connect Google Drive, expect Claude to read your spreadsheet, and get... a binary blob. Or an error. The connector technically "works" but doesn't do what users expect.

The real issue: connectors are per-agent silos

Say you get Claude's Google connector working perfectly. Every bug fixed, every scope correct. You still have a structural problem.

That connector only works in Claude. If you also use Cursor, Codex, or OpenClaw, you need separate Google integrations for each one. Each agent has its own OAuth flow, its own token storage, its own connector configuration. There's no shared authorization layer.

This creates several problems that compound as you add agents:

  • No central visibility. There's no dashboard showing which agents have access to your Google account. Claude has its connectors. Cursor has its own. They don't talk to each other, and neither talks to you in a unified way.
  • No unified revocation. Want to cut off all AI agent access to your Google Drive? You'd need to disconnect each connector individually, across every agent platform, and hope you didn't miss one.
  • No expiry controls. MCP connectors don't have a concept of grant expiry. Once connected, a connector stays connected until you manually disconnect it. There's no "give Claude access for one hour" or "revoke automatically after this project ends."
  • Token ownership is unclear. When a third-party connector holds your Google tokens, who's responsible for securing them? Anthropic? The connector developer? You? The answer is "it depends," which in security terms means "nobody."

What we built instead

TapAuth takes a different approach. Instead of each agent platform building its own Google connector with its own OAuth flow and its own token storage, TapAuth acts as a broker between agents and APIs.

Here's how it works for Google:

An agent needs to read your Google Calendar. It calls TapAuth's API with the scopes it needs. TapAuth shows you a consent screen in plain language: "This agent wants to read your calendar events for the next 7 days." You approve with a time limit. TapAuth issues a scoped token to the agent. The agent never sees your Google password. The grant expires when you said it should.

This works the same way regardless of which agent is asking. Claude, Cursor, Codex, OpenClaw, a custom script — they all go through the same API, the same consent flow, the same dashboard.

Revocation is one API call: DELETE /grants/{id}. The dashboard shows every active grant across every agent. You can set expiry from one hour to one year. And the agent never holds your Google OAuth tokens directly — TapAuth issues scoped, time-limited tokens that only work for the specific permissions you approved.

MCP is good. It's just not an auth layer.

I want to be clear: MCP is a well-designed protocol. The way it standardizes tool discovery and invocation genuinely matters. Anthropic deserves credit for open-sourcing it and building an ecosystem around it.

But the connector model asks MCP to do something it wasn't designed for. Auth got bolted on because users needed it, not because the architecture supports it. The result is OAuth bugs in the spec implementation, trust concerns with third-party connectors, and a fragmented experience across agent platforms.

The pattern here is familiar from web history. HTTP is a great protocol. It needed TLS for security. SMTP is a great protocol. It needed SPF and DKIM for trust. MCP is a great protocol. It needs an auth layer that's designed from the ground up for multi-agent, user-controlled authorization.

That's what we're building. Try TapAuth and see what agent auth looks like when it's the whole product, not an afterthought.