Looker's Native MCP Server with Claude Code

Looker has introduced a native MCP server for its instances, allowing developers to connect Claude Code directly via an HTTP endpoint instead of running a local binary. The server, hosted by Google, requires an admin to enable it and API3 credentials, and it supports a global tool allowlist. The setup simplifies configuration to four lines, eliminating the need for a 292 MB local installation.

Looker hosts its own MCP server now. This walks through connecting Claude Code to it, pairing it with the Looker CLI, and being clear-eyed about where the tool set stops. Until recently, connecting an agent to Looker meant running MCP Toolbox as a local binary. You downloaded 292 MB onto your laptop, taught it your API credentials, launched it as a stdio subprocess, and kept it updated forever. Every developer needed their own copy, and the server ran on your side of the wire. Looker closed that gap. Every Looker Google Cloud core and Looker original instance now exposes an MCP endpoint on its own base URL: https://780eb09e-7dab-4076-9ec1-ecf9d8414630.looker.app/mcp That is the entire install. Ask the endpoint who it is and the joke lands: curl -s -X POST "$LOOKER MCP URL" \ -H 'Content-Type: application/json' \ -H 'Accept: application/json, text/event-stream' \ -d '{"jsonrpc":"2.0","id":1,"method":"initialize","params":{ "protocolVersion":"2025-06-18","capabilities":{}, "clientInfo":{"name":"probe","version":"0"}}}' {"jsonrpc":"2.0","id":1,"result":{ "protocolVersion":"2025-06-18", "capabilities":{"tools":{"listChanged":false},"prompts":{"listChanged":false}}, "serverInfo":{"name":"Toolbox","version":"1.4.0+container.release.linux.amd64.d67cfbe"}}} "name":"Toolbox" . It is the same software. Google moved it to the other end of the connection and took over running it. Migrating is not a bet on new technology — it is the server you were already running, minus the operational burden. Three things, and only the first needs someone else. An admin has to switch the server on. It lives at Admin → Platform → Model Context Protocol . That page also holds the allowlist of which tools agents may call. A tool switched off there does not exist as far as any client is concerned. You need API3 credentials — Base URL, Client ID, Client Secret. Looker admin panel, Users → your user → Edit Keys . Note the preview limits before you plan around them. Customer-hosted instances are not supported. There are no fine-grained scopes — tool access is one global allowlist, not per-user or per-group. Tool-list changes take about 30 seconds to reach clients, which then have to reconnect. 1. Resolve credentials. The setup script prompts for anything it cannot find, writes .env at mode 600, and derives LOOKER MCP URL from your base URL: source set env.sh Source it, do not execute it. The reason matters and catches everyone once — see step 4. 2. Install the Looker CLI. Checksum-verified into the project root: make cli looker-cli 0.4.8 3. Smoke-test the credentials before involving an agent. If this fails, nothing downstream will work: ./lk user me +----+--------------+-------------+----------+ | ID | DISPLAY NAME | IS DISABLED | ROLE IDS | +----+--------------+-------------+----------+ | 3 | xbill work | false | 8 | | | | | 4 | | | | | 149 | +----+--------------+-------------+----------+ 4. Register the server with Claude Code. The whole configuration is four lines, and it holds no secrets: { "mcpServers": { "looker-managed": { "type": "http", "url": "${LOOKER MCP URL}", "headersHelper": "${CLAUDE PROJECT DIR:-.}/lk headers" } } } Compare that with what it replaced: a bash -c wrapper that sourced .env , checked three variables, and exec'd a 292 MB binary with --stdio --prebuilt looker,looker-dev . Also gone is startup timeout sec — it existed because the binary had to boot and handshake before the client would call it ready. An endpoint that is already running has nothing to wait for. Two fields are doing real work here. headersHelper names a command , not a static value. Claude Code runs it on every connection, and again automatically after a 401 or 403 , retrying the call once with fresh headers. Looker access tokens live one hour; this makes expiry heal itself. A stale token becomes one 401 you never see. ${LOOKER MCP URL} is expanded by Claude Code itself , not by a shell. A stdio server could source .env inside its own wrapper; a remote server has no wrapper. The variable must exist in the environment of the process you launch claude from — which is exactly why step 1 says source , not execute. If your tools are missing, check this first. 5. Verify. Start Claude Code and run /mcp . You should see looker-managed connected with 40 tools. The endpoint will confirm the count itself, without credentials: curl -s -X POST "$LOOKER MCP URL" \ -H 'Content-Type: application/json' \ -H 'Accept: application/json, text/event-stream' \ -d '{"jsonrpc":"2.0","id":2,"method":"tools/list"}' | jq '.result.tools | length' 40 Metadata is open — initialize and tools/list answer unauthenticated, which is what lets a client discover the server before signing in. tools/call refuses without a token. Nothing touches data anonymously. One note on what this authentication actually is. ./lk headers exchanges your API3 key for a short-lived Looker access token. It works, and it is the right call for evaluation, but every action is attributed to the API3 key's user rather than the human who asked. For a shared instance, register an OAuth client instead — the instance advertises the endpoints at /.well-known/oauth-authorization-server and uses PKCE, so there is no client secret to store. Here is the pattern the whole setup exists to support. Start with a question, not a query. Which product categories drive the most revenue? Claude walks the semantic model. get models returns the instance inventory: basic ecomm, intermediate ecomm, advanced ecomm sample thelook ecommerce london bicycles london bicycles gcp billing block marketplace gcp-billing bq agent analytics agent events get explores on advanced ecomm narrows it to two, and get measures returns the aggregates that actually exist — order items.total sale price , order items.count , order items.average sale price . No guessing at column names, and no SQL. The agent is reading the same governed definitions your dashboards use. Then query runs it: {"products.category":"Outerwear & Coats","order items.total sale price":971454.48, "order items.count":6711,"order items.average sale price":144.76} {"products.category":"Jeans","order items.total sale price":924765.39, "order items.count":9428,"order items.average sale price":98.09} {"products.category":"Sweaters","order items.total sale price":630197.03, "order items.count":8476,"order items.average sale price":74.35} Outerwear leads on revenue with a third fewer items sold than Jeans, because it carries a 48% higher average price. That is the kind of read worth having an agent for: the rows are in its context, so it can reason about them. Now hand it to the CLI. The query shape is settled, so freeze it. Same fields, same sorts, in a file the CLI understands: { "model": "advanced ecomm", "view": "advanced example ecommerce", "fields": "products.category", "order items.total sale price", "order items.count", "order items.average sale price" , "sorts": "order items.total sale price desc" , "limit": "6" } ./lk query runquery --file q.json --format csv --output category-revenue.csv Products Category,Order Items Sales,Order Items of Order Items,Order Items Average Price Outerwear & Coats,971454.4791278839,6711,144.75554747845126 Jeans,924765.3913908005,9428,98.08712254887557 Sweaters,630197.0301675797,8476,74.35075863232427 Identical numbers, different destination. That is the entire argument for running both. The view key is the one spelling trap — the CLI calls the explore view , while model , fields , filters and sorts match MCP exactly. Why bother with the second interface at all? Because the two differ in what happens to the answer, not in what they can reach. Same instance, same API3 key, same REST API underneath. Native MCP looker-managed | CLI ./lk | | |---|---|---| | Coverage | 40 tools: query, content, LookML dev, health | The whole API — git, users, roles, schedules, connections, deploys | | Results land | In the model's context | On disk | | Cost | Every row consumes context | Free of context until you read the file | | Good at | Discovery, judgement, structured content creation | Scale, files, determinism, repeatability | | Bad at | Bulk output, anything admin-shaped | Deciding what to ask for | Discover and decide over MCP, execute and persist with the CLI. Asking an agent which explore holds revenue by cohort is worth twenty minutes of clicking through the Explore UI. Routing 40,000 rows through its context is not. Once the shape is settled, the CSV job runs forever with no agent in the loop and no tokens burned. The two also meet at the credential: ./lk headers is what authenticates the MCP server in the first place. The CLI is not a second path bolted on beside MCP — it is what gets MCP connected. | MCP Toolbox local binary | Native Looker-hosted | | |---|---|---| | Install | 292 MB download per machine, updated forever | A URL | | Transport | stdio subprocess | Streamable HTTP | | Version | You pin it — currently v1.8.0 | Google pins it — currently 1.4.0 | | Tools | 46, from --prebuilt looker,looker-dev | 40, from the admin allowlist | | Governance | Client-side, per developer, advisory | Admin panel, instance-wide, enforced | | Auth | API3 key in the subprocess environment | Bearer token, or OAuth 2.1 + PKCE | | Failure mode | "Why won't the server start" | "Why is the endpoint slow" | Two rows deserve more than a table cell. Version is the real trade. The hosted server reports 1.4.0 while the downloadable binary is on v1.8.0. You stop patching, and you also stop choosing. If you depend on something that landed in Toolbox after 1.4.0, stay where you are for now. Governance is the real win. With a downloaded Toolbox, the tool set was whatever --prebuilt shipped, and any restriction had to be re-implemented in every client by every developer who installed it. Now a tool switched off in the admin panel does not exist for anyone. That is the difference between a policy and a suggestion. Migrating is mostly deletion: add the new server, move your git workflow to the CLI, then delete the binary, the download step, the launcher script and the toolbox line in .gitignore . In this repo that removed 292 MB, a checksum routine, a stdio wrapper, and an entire class of "why won't the server start" support question. The gaps are not random. The server covers Looker as a semantic model and stops at the edge of Looker as an administered system . Git, entirely. list git branches , get git branch , create git branch , switch git branch and delete git branch all shipped with the local binary. The managed server exposes none of them. File editing and dev mode are present, so the agent can write LookML — it just cannot get itself onto a branch to write it safely. The CLI covers that half: ./lk api project create git branch --project id my project --name my branch ./lk project checkout my project my branch Commit is missing from both, and that one is not an MCP limitation. The Looker API has no commit endpoint at all. Search the CLI's entire surface and you get deploy verbs: ./lk meta search commit Found 7 matching commands: looker-cli api project create git branch - Checkout New Git Branch looker-cli api project deploy to production - Deploy To Production looker-cli api project tag ref - Tag Ref looker-cli api project update git branch - Update Project Git Branch ... So the agent creates the branch, writes the files, validates them and runs the tests — then stops. Committing the workspace is an IDE operation. The loop that looks like it should close branch → edit → validate → commit → deploy closes at every step except the second to last, and that step needs a browser. Plan around it rather than fighting it. The agent does the branch, the edits, the validation and the tests; a human commits in the Looker IDE; the terminal deploys: ./lk project deploy my project deploy to production never had an MCP equivalent either, so the deploy was always a CLI call. The commit is the only step neither interface can reach. get field value suggestions. Gone. To find valid filter values, query the field's suggest explore directly — get dimensions names it in the suggest explore and suggest dimension attributes of any suggestable field. The entire administrative surface. Users, groups, roles, permissions, user attributes, schedules, alerts, connections, themes and sessions have no MCP tools and never did. Every one is a ./lk api call. Two permission failures look like bugs and are not: health analyze and health vacuum need System Activity access and return Access Denied without it, and plan ls returns 404 without see schedules . Everything else — discovery, querying, content creation, LookML files, validation, tests, health — is present and works. The native install is a smaller thing to own than what it replaced. A 292 MB download, a stdio wrapper and a --prebuilt flag collapsed into a URL and a headersHelper . Google patches the server, the admin panel governs which tools exist, and System Activity logs what the agent did. What you give up is specific and covered: five git tools and get field value suggestions , all of which the CLI handles. What you should fix before production is the auth shortcut — swap the API3 token helper for a registered OAuth client so actions are attributed to a person rather than a key. The durable lesson is the division of labor. The MCP server is for discovery and judgement; the CLI is for execution and persistence. Install only one and you will find the seam within a week — most likely on a Tuesday afternoon, halfway through a LookML change, at the commit step.