What goes wrong without governed Looker MCP access for Claude
Someone in revenue asks Claude why new bookings dipped last week. The numbers live in Looker. An analyst wires Looker into Claude with whatever credential was nearest, and the first answer comes back in seconds. Two weeks later a dashboard has been changed, and nobody can say who changed it.
That is the failure to design against. Looker MCP access for Claude rests on three settings. One Looker connection per person. A block rule on the analysts' role covering the write and delete tools. A toolbox choice made on Elaichi's consent screen. One audit query afterwards shows whether they held.
Elaichi is a governed MCP control plane. MCP (Model Context Protocol) is the standard way an AI assistant calls tools in other apps. Claude, ChatGPT and Cursor all sign in at the same address, https://api.elaichi.ai/mcp. Which organization, which person and which tools a client reaches comes from the OAuth grant behind its token, not from the URL. A grant is the standing approval one person gave one named client on Elaichi's consent screen.
Does Looker publish its own MCP server?
This post does not claim either way. Google Cloud's own Looker documentation settles that, not Elaichi's. Read Looker's pages first, then take one of two paths.
The first path is the catalog. Elaichi's catalog carries 650+ connectors of two kinds. Some Elaichi authors and runs itself. The rest are native MCP connectors, where the vendor builds and runs its own MCP server and Elaichi handles sign-in, access and audit in front of it. The list changes with every connector sync, so open the Connectors section in the console and search. The Looker connector page shows what that connector carries.
The second path is your own. If Looker publishes a remote MCP server reachable over public HTTPS, an Org Owner or Org Admin can add that server as the organization's own connector. That needs the connector:create permission and the custom connectors feature, which Gold includes. Elaichi then signs members in, checks restrictions and OAuth scopes before a call leaves, and writes every call that runs to the audit log. Elaichi never forwards its own MCP access token to a remote server. That server only ever sees a token its own authorization server issued. The reasoning behind putting a vendor's own server behind one front door is the same either way.
Restriction one: one Looker connection per person
Give each person their own Looker connection, so Looker's own model and content permissions keep deciding what comes back. A connection is one row in Elaichi bound to one account at the app. Every call through it uses that account, whoever makes the call. A connection shared with a team therefore runs as its owner.
One admin connection shared with twelve people answers every question with that admin's reach. Looker's permission model stops being the thing that decides, and the audit row names the same connection for all twelve.
Per-person connections also change what the model is offered. For a remote MCP connector, tools are discovered per connection, with that connection's own credential. Different accounts at the vendor see different tools. A viewer and an analyst do not get the same list.
The trade-off is unattended work. Elaichi's MCP sign-in supports only the authorization-code grant with PKCE, plus refresh. Every grant needs a person at a browser, so there is no client-credentials path for a nightly job. Where one fixed permission set is genuinely what you want, a shared connection is how to get it. The log then names one account for everyone.
Restriction two: block the write and delete tools on the role
Write one block rule on the role the analysts hold, naming the Looker tools that change anything. In Elaichi, restriction targets are role or user only; the organization default is the absence of a rule, which means allow everything. A team is held to reads by way of the role its members hold.
Blocks and allows do not behave alike, and the difference catches people out.
- An allow rule turns on an allowlist for its whole layer. Every connector and tool that no allow rule names is then blocked for that role. That holds across every connector the role uses, not only Looker. An allow rule naming nothing blocks everything for its target.
- A layer with only block rules has no allowlist, so anything unnamed passes. You have to enumerate the write tools.
- A block matches a tool by name or by the operation it performs. An allow matches only the operation Elaichi pinned when the rule was saved. Renaming a tool cannot slip it past a block. That asymmetry has its own explanation, and the choice between naming tools and naming the whole app is worth making deliberately.
Read the tool names off the connector's tool list in the console. A restricted tool is not hidden from the person. Tool search lists it by name, flagged restricted, with no schema and no way to call it. They can file an access request from the chat. An admin resolves that request in the console under Governance, then Access requests. No AI surface can decide one. Approving records an access grant for that one person and never edits the role's rules. Before handing one out, know the limit. No screen lists or revokes grants. A grant ends when it expires, when a later approval supersedes it, or when the member is removed.
A restriction change reaches every surface within about two minutes.
One more thing to expect. Elaichi tiers each remote MCP tool from the server's own annotations. A tool the server marks read-only counts as a read. One marked non-destructive counts as a write. Anything else, including a tool with no annotations, counts as destructive. The tier labels the audit row and the hint sent to the client. It does not gate the call, because "Run your connected tools" runs every tier.
Restriction three: pick the toolbox at consent, not the whole account
When the analyst connects Claude, Elaichi's consent screen offers two reaches for tools. "All my tools" means everything they can run today and anything they connect later. "Only the ones I pick" names one to 50 stored toolboxes. For a BI rollout, pick. The grant then reaches exactly those toolboxes, re-checked on every call. If one is deleted or the person loses access to it, the grant reaches less, never everything.
What consent cannot do is make Looker read-only. "Run your connected tools" covers running every tier of connected tool, deletes included. "Delete data and remove access" is about Elaichi's own data and its members, not a connected app. Leaving "Create and change data" unticked does not stop a connected app's write tools either. Scopes narrow which toolboxes and which Elaichi operations; restrictions narrow which tools. Only the restriction makes the rollout read-only.
Toolbox choice can be changed later from Settings, then Connected apps, and applies on the app's next call. Scopes cannot widen without connecting again. The client-side half of this, adding the endpoint in Claude, takes a few minutes per person.
The client has controls of its own, and they sit beside Elaichi's rather than replacing them. On Claude Team and Enterprise plans an Owner adds a custom connector once for the organization, and each member then connects it with their own sign-in (Anthropic's custom connector documentation, checked October 2026). An Owner can also set a connector's tools to Always allow, Needs approval or Blocked (Anthropic's connectors article, checked October 2026). Those permissions see Elaichi's connected tools as one execute_tool, so they cannot single out Looker from the CRM. Cursor, signing in at the same Elaichi address, supports OAuth for MCP servers and asks for approval before using an MCP tool by default (Cursor's MCP documentation, checked October 2026). The per-tool decision still belongs in Elaichi.
The audit query that proves the restrictions held
Two queries, and one gap to state first: a call a restriction refuses writes no audit row. The log shows what ran, not what was stopped.
Query one, what ran. In the console's audit log, set the category to Assistant rather than MCP. A connected-tool call is recorded as an assistant action; the MCP category holds client grants and similar events. Put the connector's name in the free-text box. That search matches each word against the action, resource type, resource id, actor id and the event's stored metadata. The metadata carries the connector. Set the date range, then read the rows.
Every connected-tool row records the person and the tool's advertised and catalog names. It also records the connector, the connection the call reached, the tier, the surface, the MCP client and the outcome. Open one, and three lines in the detail panel carry the proof:
- What it did reads Read data, Changed data or Deleted data. In a read-only Looker rollout, every row reads Read data.
- Connection names the account the call reached, not the one the arguments asked for. If you expected a person's own connection and the row names a shared one, the rollout drifted.
- Approval reads that the call was allowed by the access the client was granted. Over MCP the grant is the approval, and Elaichi does not ask per call.
Check the client name too. Elaichi marks a client verified only when every non-loopback redirect address it registered maps to the same known client. Claude is one of seven that can be verified. Any other name is the one the client registered for itself, flagged as self-reported.
Query two, what the rules say. Search the log for restriction. Rule writes are recorded as restriction.created, restriction.updated and restriction.deleted, which date the control. Pair those rows with a month of Read data rows. That is both halves of the evidence a reviewer asks for, the same list any AI audit log has to carry.
Reading the whole organization's log needs the audit:view permission, held by Org Owner, Org Admin and Auditor. Auditor is a free, read-only role and takes no billable seat. It is the usual way to give a compliance reviewer the log and nothing else. Elaichi keeps 90 days of audit history; export to your own Datadog comes with the Black plan, which is launching soon. A console export stops at 10,000 entries, so narrow the range instead of asking for everything.
Where this breaks: large result sets and text you did not write
Plan around two things.
Results are capped value by value before they leave Elaichi. A string keeps 32,000 characters, an array its first 200 items, an object its first 200 keys. Anything nested deeper than eight levels is cut. One remote MCP tool call's result is capped at 4 MiB. A cut is flagged rather than silent, but a model handed part of a table will still try to answer. Ask Looker for an aggregate, not for 40,000 rows.
The second is prompt injection. An MCP server never receives the person's typed prompt, so Elaichi has nothing on that path to judge a proposed call against. No defense of that kind runs there, and none can, for the same reason. That defense belongs to the client. A dashboard title, a field description or a free-text dimension value is text somebody wrote, and it reaches the model. Blocking the write tools is what bounds the damage, which is the general shape of the risks worth reviewing.
When you do not need any of this
Two analysts, one BI tool, each signing in with their own account in Claude. That is a connector, not a rollout, and a second vendor adds nothing you cannot read off the app's own page. The honest version of that test is set out here.
The case starts when the question is no longer about one app. One address for Claude, ChatGPT and Cursor. One place to write the rule, applied to Looker and the CRM and the ticket queue alike. One log that covers all of them. One removal that revokes a leaver's grants and tokens and ends their membership, though their accounts in the connected apps still need deprovisioning there.
If that is the position you are in, read the wider picture of who may do what, in which app. The connector catalog shows what is already governed for you.
