One URL. Sign in with Google. All your tools inside Claude.

Contents

• The problem: credential sprawl
• What MCP actually is
• The solution: one endpoint, Google SSO, everything
• What the gateway can do today
• What it looks like in practice
• Why we built this at Databy

AI assistants can do remarkably useful things — but their real value depends on what they can see. By default, they see only what you paste into the prompt.

Without access to tools, you copy data into the prompt, export CSVs, switch between windows. The friction turns a fast AI assistant into a slow text editor.

The problem: credential sprawl

Modern AI assistants can call external tools via Model Context Protocol (MCP). But getting MCP servers working for a whole team hits a practical wall fast.

Each MCP server needs its own configuration and its own credentials. In practice, that means:

• Service account JSON files on every developer's laptop
• API keys in config files
• A new team member spending hours setting up access before they can do any real work
• No central management — when someone leaves, you can't easily confirm their access is actually gone
• No audit log — no visibility into who accessed what and when

With four backends and five developers, this becomes unmanageable quickly.

What MCP actually is

Model Context Protocol (MCP) is the standard way to give an AI assistant access to external tools and data. Instead of pasting a SQL query into a prompt, Claude calls BigQuery directly. Instead of manually clicking through the GTM interface, Claude creates a tag or reviews triggers.

Anthropic introduced the protocol, but it's now implemented across multiple clients — Claude Code, Claude Desktop, Cursor, Windsurf, and others. An MCP server is simply a program that exposes a set of tools that an AI client can call.

The problem appears when you want this working for a whole team, across multiple tools, without the credential chaos.

The solution: one endpoint, Google SSO, everything

We built an MCP gateway for Databy. One endpoint, authentication via Google Workspace, access to all tools at once.

Developer config:

{
  "mcpServers": {
    "databy": {
      "url": "https://mcp.databy.io/mcp"
    }
  }
}

That's the entire setup on the developer side. The OAuth flow runs automatically on first use — the browser opens, you sign in with your @databy.io Google account, done. API credentials live server-side, not on developer machines. Access can be revoked in seconds. Every tool call is logged.

Onboarding a new team member: give them the URL, they sign in with Google, they have access to everything they're supposed to have access to.

What the gateway can do today

The gateway currently aggregates four groups of tools:

Google Tag Manager — browse accounts and containers, read and create tags, triggers, variables, templates. The full GTM API, accessible through natural language.

Google Analytics 4 — run reports and realtime reports, custom dimensions, property details. Instead of clicking through the GA4 interface: ask a question, get the answer in context.

Google Ads — access ad accounts, search campaigns, ad groups, keywords. Performance data from the ad account directly in the conversation, no export needed.

Google Workspace — Gmail (search, read threads, draft replies), Calendar (read and create events), Drive (search, read, share files), Docs (read and edit documents), Sheets (read and write), Slides (work with presentations), Forms (create forms and read responses).

All through single sign-on. One Google consent screen on first login covers permissions for every backend at once — no separate authorization flows per service.

What it looks like in practice

Concrete things that work today in Claude Code:

"Check GA4 — what's the conversion breakdown by channel for the last 30 days vs. the previous period?"

Claude calls the GA4 reporting API, returns structured data, interprets the results.

"In GTM, find all tags that fire on the checkout. Which ones don't have a consent condition?"

Claude walks the container, lists tags with checkout triggers, identifies those without consent gating.

"Go through today's emails and give me a summary of what actually needs a response today."

Claude reads Gmail threads, identifies action items, presents them structured.

"Create a Doc draft from these meeting notes — add sections for action items and deadlines."

Claude creates a new Google Doc with the structure from the prompt.

These aren't mockups. Each of these runs as a real Claude Code session — it calls the actual APIs and returns results in context.

Why we built this at Databy

Databy is a digital analytics agency. Our daily work — GTM configuration, GA4 analysis, reporting, Workspace coordination — is exactly the kind of repetitive, data-heavy work where an AI assistant with access to real data creates the most value.

Instead of every developer managing individual API access, we have one centrally controlled solution. New tools get added to the gateway, not to every developer machine individually.

Side effect: because everything flows through one place, we have full visibility. When something breaks, it's clear where to look. When someone needs access removed, it's a one-step operation.

The platform is internal, but the architecture is generic. If you're running a team that works with AI assistants daily and this sounds like a problem you're dealing with — we're open to talking about it.