Loading today’s stories
Build1 distinct publisher3 min readUpdated
Google moved MCP Toolbox to the server side of the wire. The client config drops to four lines with no secrets in it, but the security boundary is now one global allowlist.
The Engineer · Build desk
Compiled by The EngineerSomething wrong?How this is made
Every Looker (Google Cloud core) and Looker (original) instance now exposes an MCP endpoint on its own base URL, at path `/mcp` [1]. That retires the arrangement it replaces: MCP Toolbox as a 292 MB binary on each developer laptop, taught your API credentials, launched as a stdio subprocess, and maintained forever by whoever installed it [2].
The interesting part is what the endpoint says about itself. A credential-free `initialize` probe, documented in a walkthrough published on dev.to, returns protocol version `2025-06-18` and a `serverInfo` block naming the software `Toolbox` at version `1.4.0+container.release.linux.amd64.d67cfbe` [3]. It is the same software you were already running; Google moved it to the far end of the connection and took over operating it [4]. Migrating is an operations change, not a capability bet [4].
Three things have to happen, and only one needs somebody else. An admin enables the server at Admin > Platform > Model Context Protocol, the same page that holds the allowlist of which tools agents may call [5]. A tool switched off there does not exist as far as any client is concerned [6]. You still need API3 credentials, meaning base URL, client ID and client secret from Users > your user > Edit Keys [7].
The client side is where the reduction shows. Registering the server with Claude Code is four lines holding no secrets: transport `http`, a `url` of `${LOOKER_MCP_URL}`, and a `headersHelper` pointing at a local CLI [8]. It replaces a `bash -c` wrapper that sourced `.env`, checked three variables, and exec'd the 292 MB binary with `--stdio --prebuilt looker,looker-dev` [9]. Also gone is `startup_timeout_sec`, which existed only because the binary had to boot and handshake before the client would call it ready [10].
`headersHelper` names a command rather than a static value: Claude Code runs it on every connection, and again automatically after a 401 or 403, retrying once with fresh headers [11]. Looker access tokens live one hour [12], so an eight-hour working session crosses expiry at least seven times [1], and each of those becomes a retry nobody sees [11]. The counterpart trap is that `${LOOKER_MCP_URL}` is expanded by Claude Code itself, not by a shell, so the variable must exist in the environment of the process you launch `claude` from [13]. That is why the setup script is sourced, not executed [14].
Verification runs in the right order: `make cli` drops a checksum-verified `looker-cli 0.4.8` into the project root [15], `./lk user me` smoke-tests the credentials before an agent is involved [16], and `/mcp` should then show `looker-managed` connected with 40 tools [17]. The endpoint will confirm that tool count without credentials [18].
Read the preview limits before planning around them. Customer-hosted instances are not supported [19]. There are no fine-grained scopes: tool access is one global allowlist, not per-user or per-group [20]. Tool-list changes take roughly 30 seconds to reach clients, which then have to reconnect [21]. And the credential itself has not left the laptop. The setup script still writes client ID and secret into a local `.env` at mode 600 [22], derived from your base URL [22]; what moved server-side is the tool runtime and the version you are running, not the secret.
Worth watching: whether per-user or per-group scopes arrive before teams point this at anything with row-level sensitivity, since today the admin toggle is the entire boundary [20]. Watch customer-hosted support, which currently excludes an entire deployment class [19]. And watch the `serverInfo` version string, because the Toolbox build behind the endpoint can now change without anyone on your side downloading anything [3][4].
Follow any of these and your For You feed starts watching them — no settings page required.
Ranked by verification strength, evidence, and original report placement.
Every Looker (Google Cloud core) and Looker (original) instance now exposes an MCP endpoint on its own base URL, at the /mcp path (example: https://<instance>.looker.app/mcp).
Until recently, connecting an agent to Looker meant running MCP Toolbox as a local binary: a 292 MB download onto the laptop, configured with your API credentials, launched as a stdio subprocess, kept updated indefinitely, with every developer needing their own copy and the server running on the client side of the wire.
A credential-free JSON-RPC initialize call to the endpoint returns protocolVersion 2025-06-18, capabilities for tools and prompts with listChanged false, and serverInfo name "Toolbox" version 1.4.0+container.release.linux.amd64.d67cfbe.
The hosted endpoint runs the same Toolbox software as the local binary; Google moved it to the other end of the connection and took over running it, so migrating is described as the server you were already running minus the operational burden.
An admin must switch the server on at Admin > Platform > Model Context Protocol, the same page that holds the allowlist of which tools agents may call.
A tool switched off in the admin allowlist does not exist as far as any client is concerned.
Evidence-backed comparisons of source perspectives and observed adoption signals. Read the methodology
Which Builder, Operator, and Investor concerns the observed source mix emphasized—not a truth score.
Evidence, demonstrated adoption, hype gap, incentives, and confidence are assessed independently, each on its own current evidence. How these are measured.
First-hand reproducible transcripts, one publisher
The core technical claims are backed by pasted request/response artifacts — an unauthenticated initialize returning Toolbox 1.4.0 and protocolVersion 2025-06-18, a tools/list count of 40, looker-cli 0.4.8, and the ./lk user me output — which is unusually checkable for a single post. But the cluster contains exactly one source and one publisher, and the platform-level assertions (availability on all instances, absence of fine-grained scopes, unsupported customer-hosted instances, ~30s tool-list propagation) have no vendor documentation or second observer behind them.
One practitioner deployment against a preview endpoint
Observable adoption is the feature's own preview availability plus a single documented working integration (Claude Code showing 40 tools, CLI 0.4.8 installed). There are no organisation counts, usage disclosures, or reports from other teams, and the preview explicitly excludes customer-hosted instances, so the addressable installed base described is itself partial.
Marginally understated
The framing tracks the evidence closely and in places undersells nothing while overselling nothing: the author explicitly refuses the novelty pitch ('it is the same software'), enumerates preview limits, flags that API3-key auth misattributes every action to the key's user, and recommends OAuth with PKCE for shared instances. The only mild stretch is generalising instance-wide availability from one instance. Net effect is a slight tilt toward under- rather than over-claiming.
Vendor-adjacent advocacy, limitations disclosed
The article is a promotional-adjacent enablement post for a Google Cloud product, published on dev.to under a 'gde' (developer-expert) organisation path, with no independent evaluation of alternatives and no cost or contractual detail. That is a real favourability incentive. It is partly offset by content that cuts against the pitch: enumerated preview limits, the attribution weakness of API3-key auth, and the recommendation to use OAuth for shared instances.
Moderate-low: checkable mechanics, single observer, preview product
Confidence is held down by one publisher, one instance, and a preview feature whose behaviour and limits can change without notice. It is held up by the reproducibility of the central artifacts and the internal consistency of the account: config shape, unauthenticated metadata versus authenticated tools/call, and token-refresh behaviour all cohere with the stated architecture.
build
Kubernetes MCP servers hide the delete tool; hiding is not removing1 distinct publisher
product
Binance gives agents a trading seat, and gives users the permission slip1 distinct publisher
build
LoreKit puts agent memory in Markdown files you can grep, not a vendor's database1 distinct publisher
product
A 2x LLM bill is not a bug report: token spend is an observability problem1 distinct publisher
Distinct publishers with included, body-backed reporting in this cluster.
dev.to
1 article · August 14, 2026