Credible vs. Looker

Looker’s MCP tools mirror its API, which is a coherent design: an agent calls get_models, then get_explores for a model, then get_dimensions and get_measures for an Explore. Google’s own guide describes that sequence, and it gives the agent a real map of the instance. Credible searches an index of the model instead — typed search targets come back as a ranked set of sources, dimensions and measures, so the agent asks for the handful of fields a question needs. The trade is coverage against round trips, and which one suits you depends mostly on how large the model is.

LookML is authored and maintained by data engineers, and Looker is built to make that craft good — the review workflow, the IDE and the validator all assume a team that owns the model. Credible assumes you already have a coding agent and points it at the work: it builds and maintains the model from documentation, query history and knowledge stores already in your stack. The parts that make an agent good at this — the MCP retrieval tools and the agent skills — are open source in Malloy Publisher and need no Credible account, so they run inside whatever agent your team already uses. Same model at the end; a different answer to who does the work, and to who owns the expertise that makes them good at it.

LookML made the model explicit and centrally governed, and a great deal of what this category now takes for granted starts there. It is deliberately declarative, which is what lets a team review a change before it ships — and the cost of being that explicit is volume. Definitions get restated, and a project that has run for a few years tends to carry LookML nobody is certain is still in use. Malloy is aiming at something adjacent: a language with imports, inheritance, and public and private members, so a definition is written once and reused rather than repeated. That composition is what keeps a large model comprehensible to people and safely extensible by an agent, which is the case we are optimizing for.

A persistent derived table means a derived_table block carrying its own SQL, a persist_for TTL or a datagroup_trigger, and usually a datagroup alongside — a second description of logic the model already holds, kept in step by hand. Credible materializes a source with a single annotation on that source: one definition, with its persistence sitting beside the logic it persists. A PDT is always a table in your warehouse; a Credible source can be that, or it can be held hot in the engine’s own storage, decided per source. Same intent either way — the difference is how much you write to get there, and whether the warehouse has to be the thing that makes it fast.

access_filter, access_grants, persistent derived tables and value_format are each their own mechanism, configured alongside the model — which is what lets Looker admins reason about them separately. Malloy folds annotations, access rules and materialization into the language, so they are versioned and reviewed in the same diff as the logic they protect.

Looker reads Snowflake and BigQuery semantic definitions now, which meaningfully widens where it reaches, and its LookML model is the asset a Looker investment is built around. Credible is open core: Malloy is open source, we maintain Malloy Publisher, and the model runs across BigQuery, Snowflake, Postgres, MySQL, Databricks, Trino and DuckDB. That is the bet we made — that the model should be a file you own, in a format anyone can read.

Migration tooling is usually a black box: you hand over a project and get a model back. The adapter that reads LookML here is `malloy-lookml-review`, MIT-licensed in Malloy Publisher, and every phase of it is a markdown file you can read before you run it — how a `hidden: yes` field is told apart from a `fields` exclusion, when a derived table is performance-only rather than a real transformation, which patterns are flagged for a person instead of converted. That distinction is not cosmetic: `hidden` mapped to an access modifier over a few hundred fields is the difference between a model an agent can use and one it quietly misreads.

A LookML project that has run for years exposes far more than anyone queries. On one certified dashboard migration — 28 tiles over three explores — the explores exposed roughly 6,500 fields and the rebuilt model kept 377 of them, with every supported tile reproduced and validated row by row against live data. The trim is the work: Looker knows what people actually ran, so the set that matters can be established from query history rather than argued about. Recreating tile for tile ports the ceiling along with the content.