Your agent needs to answer questions out of Looker. Looker now ships a managed MCP server built into the platform, and it has shipped a REST API for a decade. Both paths reach the same semantic layer, but they hand you different tool surfaces, different consent flows, and a very different amount of admin coordination before anything runs in production. For a multi-tenant agent, one of those differences is a hard onboarding blocker rather than a preference.
Two objects are worth separating before comparing them. Google ships a managed MCP server inside the Looker platform, and it separately maintains MCP Toolbox for Databases, an open source server you run yourself. Google's own documentation states the Toolbox is provided as-is, is not a supported Google Cloud product, and carries no SLA. For a production B2B agent, the managed server is the object that matters, so that is what this article compares.
The managed server embeds an MCP endpoint directly into a Looker instance at LOOKER_INSTANCE_URL/mcp. It is in preview, available on Looker-hosted Looker (Google Cloud core) and Looker (original) instances, and explicitly unavailable on customer-hosted deployments.
Authentication is OAuth 2.1. The client runs an Authorization Code flow with PKCE against /auth on the UI host and /api/token on the API host, requesting the cors_api scope with no client secret. Once connected, the agent inherits the Looker roles and content access of the user who authenticated.
Looker API 4.0 is the current generally available version, with 3.x on a published deprecation path. It exposes the full instance: queries, Looks, dashboards, folders, scheduled plans, LookML projects, connections, users, groups, and roles.
Auth is a client ID and client secret pair bound to a Looker user account. You exchange them at POST /api/4.0/login for a short-term access token, then send it as Authorization: token <access_token>, not as a bearer token. Expired tokens fail with 401 Authorization Required, and logout invalidates a live token.
The interesting comparison is not raw endpoint count. It is which of the two surfaces can carry the workflow your agent actually runs, and what breaks when it cannot.
Google documents one tool catalog covering 30 tools across four families: model and query tools, content tools, instance health tools, and LookML authoring tools. The shape of that catalog tells you what the MCP path was designed for.
The managed server is built for a developer or analyst sitting in an IDE. It reads the semantic layer, runs queries, drafts content, and edits LookML. It does not manage the objects around that content.
That gap is specific. No scheduled plans means an agent cannot set up or fire a delivery, which is the single most common "do something with this analysis" action in Looker. No folder tools and no delete or update tools means any agent doing content lifecycle work hits a wall after the create call.
The LookML authoring family is the real MCP advantage. An agent that can call dev_mode, read project files, write them back, and introspect connection schemas is doing work that costs meaningful adapter code against the API.
The health family is the other one. health_pulse, health_analyze, and health_vacuum are composite analyses, not single endpoints. Reproducing them on the API means writing the analysis yourself against System Activity.
LookML write access is a two-sided capability. An agent with dev_mode and update_project_file enabled can change the definitions of your governed metrics. The tool allowlist is instance-wide, so enabling those tools for a LookML copilot also enables them for every other agent connected to that instance.
If your product ships a read-only Looker assistant to customers, you do not want LookML authoring in the allowlist. On the managed server you cannot have it both ways on one instance.
Both paths run as a specific Looker user, which is the correct security posture. They differ sharply in what it takes to get there and in what happens when the credential goes stale.
Dynamic Client Registration is not supported in the preview. Before any agent can connect, a Looker admin has to register it as an OAuth client by calling register_oauth_client_app, which is POST /api/4.0/oauth_client_apps/{client_guid} with a redirect_uri and a display name.
That is a per-agent, per-instance, admin-only step. For a B2B product whose customers each run their own Looker instance, it is a manual coordination item in every onboarding, and it lands on someone with the Admin Looker role rather than on the developer integrating your product.
API credentials are always bound to a Looker user account, and requests execute as that user. Looker's own guidance is to avoid credentials bound to admin accounts in production and instead create minimal-privilege API-only service accounts scoped to the intended activity.
Notably, Looker API authentication is independent of user login protocols. Two-factor, LDAP, and SAML do not apply to API credentials. That decoupling is convenient for background agents and inconvenient for offboarding, because removing a user from your IdP does not by itself kill their API credentials.
On Looker (Google Cloud core), user authentication runs through Google OAuth, and API credentials inherit that authorization. If a user's Google OAuth authorization expires or is revoked, their API credentials stop working and any live access tokens stop working with them.
Recovery is not automatic. The user has to log back into the Looker UI for each affected instance before their credentials work again. Google's documented mitigation is to use API-only service accounts for API access so agent credentials do not ride on an interactive user's consent.
Looker's per-user model is the reason to care. User attributes and access filters enforce row-level security against the authenticated identity, so a sales rep's agent sees only that rep's territory. Run the agent on a shared service account and that enforcement collapses to a single data slice for everyone.
So a multi-tenant Looker agent needs one credential per user per instance. MCP gives you an OAuth token per user; the API gives you a credential pair per user. Neither path stores them, refreshes them, or revokes them for you. This is where access control for multi-tenant AI agents becomes a real engineering concern rather than a theoretical one.
The managed server removes infrastructure work and adds coordination work. Knowing which of the two your team is short on is most of the decision.
Because fine-grained OAuth scopes are not supported, access control on the managed server is the instance-wide tool allowlist plus the user's base Looker permissions. You cannot give a reporting agent five tools and a LookML copilot twenty on the same instance.
Changes to that allowlist are not pushed to connected clients either. Google's documented procedure is to wait 30 seconds after editing the list, then reconnect each client to refresh its tool manifest.
Google notes that the prebuilt tools are pre-1.0 and that tool changes between versions should be expected. An agent built against a specific tool signature is consuming a contract that can move without a version bump you control. The API 4.0 surface is versioned explicitly, which is why deterministic pipelines belong there.
The preview also runs on fixed capacity. Google says occasional timeouts during peak usage are expected behavior, which is a retry-policy requirement rather than a bug.
The managed server is free, but tool calls consume the instance's standard administrative and query-based API quotas. An agent that issues several sequential queries per user turn burns quota faster than a traditional integration, and the same calls bill the underlying warehouse. Budget for Snowflake or BigQuery spend, not just Looker capacity.
Network boundaries mostly hold. The managed endpoint respects VPC Service Controls and is CMEK-compliant with no extra configuration. One asymmetry to plan around: the managed server is not compatible with IP allowlists on Looker (original), though it is on Looker (Google Cloud core). Browser-based MCP clients also need their domain added to the Embedded Domain Allowlist for CORS.
Audit is the genuinely good news. Every action an agent takes through the managed MCP server is recorded in Looker System Activity, in the History and Event Attribute Explores, and Looker (Google Cloud core) instances also capture it in Cloud Audit Logs.
That is instance-side attribution, and it is only as useful as the identity behind it. If your agent runs on one shared service account, every row in that audit trail names the same actor. The broader challenge of audit trails for agent auth in B2B SaaS applies here exactly as it does everywhere else.
The split is cleaner here than with most tools in this series, because the managed server's tool catalog is openly aimed at a developer workflow rather than an embedded product workflow.
This is where both paths converge, and where the interesting engineering actually lives.
Looker's identity model is correct. Every MCP tool call and every API call runs as an authenticated user, with their roles, content access, user attributes, and access filters applied. Auditors like it, and it is the reason a Looker agent can be safely exposed to end users at all.
But Looker enforces identity. It does not manage the credential lifecycle on your behalf.
For a B2B agent serving 60 analysts across 12 customer Looker instances, that is 60 OAuth grants or credential pairs to store encrypted and isolated per tenant, 60 short-term tokens to refresh before they expire, and 60 to revoke when someone leaves. Add the registration records for each instance's OAuth client on the MCP path.
Then add the failure modes. A revoked Google OAuth authorization silently kills a Looker (Google Cloud core) user's API credentials. A 401 Authorization Required is the only signal your agent gets, and it arrives mid-task. Understanding how to handle token refresh for AI agents is not optional at this scale — it is foundational.
The problem is structurally identical whichever path you picked. The token type differs; the infrastructure required does not.
Scalekit's Google Looker connector runs the per-user OAuth flow, stores each user's tokens in a vault outside your agent runtime, and refreshes them automatically. The connector ships 31 Looker tools, including the scheduled plan and folder tools the managed MCP server does not expose.
The practical effect is that the MCP versus API question stops being a credential architecture question. It becomes a tool coverage question, which is much easier to answer. For a deeper look at credential ownership across agent tool-calling patterns, the tradeoffs become even clearer.
Setup is a one-time Google Cloud OAuth client in the project that hosts the Looker instance, registered once in the Scalekit dashboard. After that, everything is per user.
Create a Web application OAuth client in Google Cloud Console, paste the redirect URI from the Scalekit dashboard into its authorized redirect URIs, then add the client ID and secret under AgentKit, Connections. Keep Access Type set to Offline so Scalekit receives a refresh token.
One Looker-specific requirement: each connected account carries the user's Looker instance hostname, without the scheme, for example your-company.cloud.looker.com. That is how one connection serves users across different Looker instances.
The authorization link is generated per user and redirects them through Google's consent screen. Scalekit stores the resulting tokens and marks the connected account active.
In TypeScript, pass the user's instance hostname through state so the connected account is bound to the right Looker instance.
Before wiring anything into an agent, retrieve the tools bound to this user's connected account. The agent is not loading a flat catalog of every Looker tool Scalekit offers; it is loading the surface this specific user's connected account authorizes, which is what keeps a multi-tenant agent from over-reaching.
The LangChain adapter converts that same scoped list into StructuredTool objects. Filtering by tool name here is how you give a read-only reporting agent a narrow surface while a separate agent role gets a wider one. This pattern is central to how LangChain tool calling works at the auth boundary.
A note on googlelooker_run_inline_query: it takes model, view, fields, and result_format, and Looker applies a 120 second timeout. Point agents at aggregated Explores rather than wide raw ones, or long-running queries will surface as tool failures.
For anything outside the tool catalog, request proxies an authenticated call to the Looker API 4.0 using the connected account's credentials. Scalekit resolves the instance host from the connected account and injects the token, so no Looker credential reaches your agent runtime.
This is the practical answer to the MCP versus API tradeoff: the tool catalog covers the common path, and the proxy covers the rest of API 4.0 without you building a second credential path.
Two capabilities matter more for Looker agents than for most connectors, because BI data is sensitive and Looker agents tend to sit alongside three or four other tools in the same workflow.
Looker's own System Activity records what the authenticated user did inside Looker. It cannot tell you which of your product's users triggered the agent run, or which agent role made the call, because that context lives on your side of the boundary.
Scalekit logs every execute_tool call against the connected account that made it, so a Looker query is attributable to a specific end user rather than to a shared service identity. Pair that with Looker's System Activity and you get both halves of the trail. More on that pattern in agent tool observability and audit trails for agent auth.
Most real Looker agents are not Looker-only. A revenue commentary agent reads Looker, pulls context from a CRM, and posts to Slack. Wiring three MCP servers together means three consent flows, three allowlists, and every tool from all three in the model's context.
Virtual MCP servers collapse that into one scoped endpoint. You declare which connections and which specific tools an agent role can see, and mint a short-lived session token per user before each run. The default session token expiry is about an hour, adjustable with the expiry parameter on create_session_token.
Token cost is the unglamorous reason. A server exposing 40 tools at roughly 200 tokens each spends about 8,000 tokens of context before the agent does any work. Scoping to five or ten tools cuts that by roughly 80%.
That is the per-agent scope the managed Looker MCP server does not currently offer, and it works the same way whether the underlying call lands on a Looker tool or a Slack one. The cost argument for why MCP can be significantly more expensive than CLI covers the fuller token math in detail.
If your users are analytics engineers working inside an IDE on a Looker-hosted instance, and a Looker admin is on hand to register agents and curate the allowlist, the managed MCP server is the right path. Nothing else gives you LookML authoring and instance health analysis for free.
If you are shipping a Looker capability inside a product, build against API 4.0. The manual OAuth client registration per instance does not survive customer onboarding at scale, scheduled plans and content lifecycle are absent from the MCP catalog, and customer-hosted instances are not supported in preview at all.
Does a Looker admin at every customer have to touch your integration before it works? If yes, and that is unacceptable, you are on the API path. The credential management problem is identical either way, and that is the part worth putting production-grade infrastructure behind.
Start with the connector docs and the working code samples, then bring the hard questions to an engineer.
Building Looker agents and want to compare notes on instance registration, allowlists, or per-user scoping? Join the Scalekit Slack community, or talk to an engineer if you need an answer today.
