{"slug": "looker-s-native-mcp-server-with-claude-code", "title": "Looker's Native MCP Server with Claude Code", "summary": "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.", "body_md": "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.\n\nUntil 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.\n\nLooker closed that gap. Every Looker (Google Cloud core) and Looker (original) instance now exposes an MCP endpoint on its own base URL:\n\n```\nhttps://780eb09e-7dab-4076-9ec1-ecf9d8414630.looker.app/mcp\n```\n\nThat is the entire install. Ask the endpoint who it is and the joke lands:\n\n```\ncurl -s -X POST \"$LOOKER_MCP_URL\" \\\n  -H 'Content-Type: application/json' \\\n  -H 'Accept: application/json, text/event-stream' \\\n  -d '{\"jsonrpc\":\"2.0\",\"id\":1,\"method\":\"initialize\",\"params\":{\n        \"protocolVersion\":\"2025-06-18\",\"capabilities\":{},\n        \"clientInfo\":{\"name\":\"probe\",\"version\":\"0\"}}}'\n{\"jsonrpc\":\"2.0\",\"id\":1,\"result\":{\n  \"protocolVersion\":\"2025-06-18\",\n  \"capabilities\":{\"tools\":{\"listChanged\":false},\"prompts\":{\"listChanged\":false}},\n  \"serverInfo\":{\"name\":\"Toolbox\",\"version\":\"1.4.0+container.release.linux.amd64.d67cfbe\"}}}\n```\n\n`\"name\":\"Toolbox\"`\n\n. 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.\n\nThree things, and only the first needs someone else.\n\n**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.\n\n**You need API3 credentials** — Base URL, Client ID, Client Secret. Looker admin panel, *Users → (your user) → Edit Keys*.\n\n**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.\n\n**1. Resolve credentials.** The setup script prompts for anything it cannot find, writes `.env`\n\nat mode 600, and derives `LOOKER_MCP_URL`\n\nfrom your base URL:\n\n```\nsource set_env.sh\n```\n\nSource it, do not execute it. The reason matters and catches everyone once — see step 4.\n\n**2. Install the Looker CLI.** Checksum-verified into the project root:\n\n```\nmake cli\nlooker-cli 0.4.8\n```\n\n**3. Smoke-test the credentials** before involving an agent. If this fails, nothing downstream will work:\n\n```\n./lk user me\n+----+--------------+-------------+----------+\n| ID | DISPLAY NAME | IS DISABLED | ROLE IDS |\n+----+--------------+-------------+----------+\n| 3  | xbill work   | false       | 8        |\n|    |              |             | 4        |\n|    |              |             | 149      |\n+----+--------------+-------------+----------+\n```\n\n**4. Register the server with Claude Code.** The whole configuration is four lines, and it holds no secrets:\n\n```\n{\n  \"mcpServers\": {\n    \"looker-managed\": {\n      \"type\": \"http\",\n      \"url\": \"${LOOKER_MCP_URL}\",\n      \"headersHelper\": \"${CLAUDE_PROJECT_DIR:-.}/lk headers\"\n    }\n  }\n}\n```\n\nCompare that with what it replaced: a `bash -c`\n\nwrapper that sourced `.env`\n\n, checked three variables, and exec'd a 292 MB binary with `--stdio --prebuilt looker,looker-dev`\n\n. Also gone is `startup_timeout_sec`\n\n— 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.\n\nTwo fields are doing real work here.\n\n`headersHelper`\n\nnames a *command*, not a static value. Claude Code runs it on every connection, and again automatically after a `401`\n\nor `403`\n\n, 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.\n\n`${LOOKER_MCP_URL}`\n\nis expanded **by Claude Code itself**, not by a shell. A stdio server could source `.env`\n\ninside its own wrapper; a remote server has no wrapper. The variable must exist in the environment of the process you launch `claude`\n\nfrom — which is exactly why step 1 says *source*, not execute. If your tools are missing, check this first.\n\n**5. Verify.** Start Claude Code and run `/mcp`\n\n. You should see `looker-managed`\n\nconnected with 40 tools. The endpoint will confirm the count itself, without credentials:\n\n```\ncurl -s -X POST \"$LOOKER_MCP_URL\" \\\n  -H 'Content-Type: application/json' \\\n  -H 'Accept: application/json, text/event-stream' \\\n  -d '{\"jsonrpc\":\"2.0\",\"id\":2,\"method\":\"tools/list\"}' | jq '.result.tools | length'\n40\n```\n\nMetadata is open — `initialize`\n\nand `tools/list`\n\nanswer unauthenticated, which is what lets a client discover the server before signing in. `tools/call`\n\nrefuses without a token. Nothing touches data anonymously.\n\nOne note on what this authentication actually is. `./lk headers`\n\nexchanges 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`\n\nand uses PKCE, so there is no client secret to store.\n\nHere is the pattern the whole setup exists to support. Start with a question, not a query.\n\nWhich product categories drive the most revenue?\n\nClaude walks the semantic model. `get_models`\n\nreturns the instance inventory:\n\n```\nbasic_ecomm, intermediate_ecomm, advanced_ecomm       sample_thelook_ecommerce\nlondon_bicycles                                       london_bicycles\ngcp_billing_block                                     marketplace_gcp-billing\nbq_agent_analytics                                    agent_events\n```\n\n`get_explores`\n\non `advanced_ecomm`\n\nnarrows it to two, and `get_measures`\n\nreturns the aggregates that actually exist — `order_items.total_sale_price`\n\n, `order_items.count`\n\n, `order_items.average_sale_price`\n\n. No guessing at column names, and no SQL. The agent is reading the same governed definitions your dashboards use.\n\nThen `query`\n\nruns it:\n\n```\n{\"products.category\":\"Outerwear & Coats\",\"order_items.total_sale_price\":971454.48,\n \"order_items.count\":6711,\"order_items.average_sale_price\":144.76}\n{\"products.category\":\"Jeans\",\"order_items.total_sale_price\":924765.39,\n \"order_items.count\":9428,\"order_items.average_sale_price\":98.09}\n{\"products.category\":\"Sweaters\",\"order_items.total_sale_price\":630197.03,\n \"order_items.count\":8476,\"order_items.average_sale_price\":74.35}\n```\n\nOuterwear 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.\n\n**Now hand it to the CLI.** The query shape is settled, so freeze it. Same fields, same sorts, in a file the CLI understands:\n\n```\n{\n  \"model\": \"advanced_ecomm\",\n  \"view\": \"advanced_example_ecommerce\",\n  \"fields\": [\n    \"products.category\",\n    \"order_items.total_sale_price\",\n    \"order_items.count\",\n    \"order_items.average_sale_price\"\n  ],\n  \"sorts\": [\"order_items.total_sale_price desc\"],\n  \"limit\": \"6\"\n}\n./lk query runquery --file q.json --format csv --output category-revenue.csv\nProducts Category,Order Items Sales,Order Items # of Order Items,Order Items Average Price\nOuterwear & Coats,971454.4791278839,6711,144.75554747845126\nJeans,924765.3913908005,9428,98.08712254887557\nSweaters,630197.0301675797,8476,74.35075863232427\n```\n\nIdentical numbers, different destination. That is the entire argument for running both.\n\nThe `view`\n\nkey is the one spelling trap — the CLI calls the explore `view`\n\n, while `model`\n\n, `fields`\n\n, `filters`\n\nand `sorts`\n\nmatch MCP exactly.\n\n**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.\n\nNative MCP (`looker-managed` ) |\nCLI (`./lk` ) |\n|\n|---|---|---|\n| Coverage | 40 tools: query, content, LookML dev, health | The whole API — git, users, roles, schedules, connections, deploys |\n| Results land | In the model's context | On disk |\n| Cost | Every row consumes context | Free of context until you read the file |\n| Good at | Discovery, judgement, structured content creation | Scale, files, determinism, repeatability |\n| Bad at | Bulk output, anything admin-shaped | Deciding what to ask for |\n\n**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.\n\nThe two also meet at the credential: `./lk headers`\n\nis 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.\n\n| MCP Toolbox (local binary) | Native (Looker-hosted) | |\n|---|---|---|\n| Install | 292 MB download per machine, updated forever | A URL |\n| Transport | stdio subprocess | Streamable HTTP |\n| Version | You pin it — currently v1.8.0 | Google pins it — currently 1.4.0 |\n| Tools | 46, from `--prebuilt looker,looker-dev`\n|\n40, from the admin allowlist |\n| Governance | Client-side, per developer, advisory | Admin panel, instance-wide, enforced |\n| Auth | API3 key in the subprocess environment | Bearer token, or OAuth 2.1 + PKCE |\n| Failure mode | \"Why won't the server start\" | \"Why is the endpoint slow\" |\n\nTwo rows deserve more than a table cell.\n\n**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.\n\n**Governance is the real win.** With a downloaded Toolbox, the tool set was whatever `--prebuilt`\n\nshipped, 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.\n\nMigrating 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`\n\nline in `.gitignore`\n\n. 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.\n\nThe gaps are not random. The server covers Looker as a *semantic model* and stops at the edge of Looker as an *administered system*.\n\n**Git, entirely.** `list_git_branches`\n\n, `get_git_branch`\n\n, `create_git_branch`\n\n, `switch_git_branch`\n\nand `delete_git_branch`\n\nall shipped with the local binary. The managed server exposes none of them. File editing and `dev_mode`\n\nare present, so the agent can write LookML — it just cannot get itself onto a branch to write it safely. The CLI covers that half:\n\n```\n./lk api project create_git_branch --project_id my_project --name my_branch\n./lk project checkout my_project my_branch\n```\n\n**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:\n\n```\n./lk meta search commit\nFound 7 matching commands:\n  looker-cli api project create_git_branch     - Checkout New Git Branch\n  looker-cli api project deploy_to_production  - Deploy To Production\n  looker-cli api project tag_ref               - Tag Ref\n  looker-cli api project update_git_branch     - Update Project Git Branch\n  ...\n```\n\nSo 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.\n\nPlan 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:\n\n```\n./lk project deploy my_project\n```\n\n`deploy_to_production`\n\nnever had an MCP equivalent either, so the deploy was always a CLI call. The commit is the only step neither interface can reach.\n\n** get_field_value_suggestions.** Gone. To find valid filter values, query the field's suggest explore directly —\n\n`get_dimensions`\n\nnames it in the `suggest_explore`\n\nand `suggest_dimension`\n\nattributes 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`\n\ncall.\n\nTwo permission failures look like bugs and are not: `health_analyze`\n\nand `health_vacuum`\n\nneed System Activity access and return *Access Denied* without it, and `plan ls`\n\nreturns 404 without `see_schedules`\n\n.\n\nEverything else — discovery, querying, content creation, LookML files, validation, tests, health — is present and works.\n\nThe native install is a smaller thing to own than what it replaced. A 292 MB download, a stdio wrapper and a `--prebuilt`\n\nflag collapsed into a URL and a `headersHelper`\n\n. Google patches the server, the admin panel governs which tools exist, and System Activity logs what the agent did.\n\nWhat you give up is specific and covered: five git tools and `get_field_value_suggestions`\n\n, 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.\n\nThe 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.", "url": "https://wpnews.pro/news/looker-s-native-mcp-server-with-claude-code", "canonical_source": "https://dev.to/gde/lookers-native-mcp-server-with-claude-code-11j8", "published_at": "2026-08-14 14:00:55+00:00", "updated_at": "2026-08-14 14:05:27.563385+00:00", "lang": "en", "topics": ["developer-tools", "ai-agents", "ai-tools"], "entities": ["Looker", "Google Cloud", "Claude Code", "MCP", "Toolbox"], "alternates": {"html": "https://wpnews.pro/news/looker-s-native-mcp-server-with-claude-code", "markdown": "https://wpnews.pro/news/looker-s-native-mcp-server-with-claude-code.md", "text": "https://wpnews.pro/news/looker-s-native-mcp-server-with-claude-code.txt", "jsonld": "https://wpnews.pro/news/looker-s-native-mcp-server-with-claude-code.jsonld"}}