A while back we argued that data modelers are the only engineers still paying for their IDE, and that data development should work the way software development already does: authoring tools free, infrastructure paid. This post is the start of the proof. We are open-sourcing the agent skills and the MCP tools behind Credible's Malloy agents, contributed straight into Malloy Publisher, the open source semantic model server for Malloy. (Here is the PR.) They run wherever you already work, with no Credible account required.
This is the anchor post for a short series. It covers what we shipped, the principles behind it and points you at the hands-on posts. If you just want to get an agent answering questions, jump to the tutorial.
A quick primer
A few terms will make the rest clearer:
A Malloy model here means a data model - file(s) that define your data's meaning. Malloy models consist of sources (think tables), join relationships and dimensions, measures, and views (pre-defined queries) that turn raw columns into business concepts like revenue or active customers. A package bundles one or more models.
Publisher, the open-source server we build on and contribute to, serves a package over a REST API and over MCP, the protocol AI agents use to call tools. Credible is our hosted platform built around Malloy & Publisher; everything in this post is the open-source part.
The gap is not the language
Malloy is a beautiful, well-documented language for modeling data, and a defined model is what makes an AI answer trustworthy in the first place. AI does not remove the need for a model; it requires one. Without one, you can't tell a correct answer from a plausible one.
But a good model is not enough on its own. The gap we set out to close is not the syntax. It is that an AI agent, dropped into a data model it has never seen, arrives with no map and no judgment. It does not know which of your sources answers the question, which measures already exist, or how the model defines them. And on its own it does not bring the discipline that separates a real analysis from a plausible-looking one: grounding a query in the data's actual scope, sanity-checking magnitudes, confirming the parts reconcile with the whole.
Closing that gap takes two things working together: a way for the agent to look up what your model actually defines, and the know-how to use it well. The tools provide the first; the skills, the second.
What we shipped
We added two read-only retrieval tools, reachable by agents over MCP:
malloy_getContexttakes a plain-English question and returns the most relevant model entities (sources, views, dimensions and measures), each with its location and docs. It indexes both entity names and the documentation the modeler attached to them, and works in two phases: find the source, then drill into its fields. That's how a question about "departure delay" reaches a field nameddep_delay, and why a well-documented model works better.malloy_searchDocsis keyword search over a bundled index of the Malloy documentation, so the agent looks syntax up instead of guessing.
We left Publisher's existing query tool, malloy_executeQuery, in place: the new retrieval tools find what to run, and executeQuery runs it. Together they're the full loop.
And 24 agent skills: the query patterns, the gotchas that trip up SQL muscle memory, chart selection, and the analysis discipline that makes an answer trustworthy, plus the skills to build, migrate, evaluate and evolve your models. The skills are portable. Agents that load skill files natively (Claude Code is one) use them directly; agents that work over MCP get the same skills served as MCP prompts. One set of skills, any agent.
Publisher also ships with ready-to-run example packages (a fictional ecommerce store, the IMDb movie database, and FAA flight data), so you can point an agent at real data before modeling any of your own.
The hands-on walkthrough, with the worked examples and the design rationale, lives in the next post. This one is the why.
The principles behind these tools and skills
We did not just port a pile of prompts. We work from a small set of principles, and the discipline itself is the point.
We think of this as skill engineering and model evaluation: applying ordinary software-engineering rigor, separation of concerns, DRY, evaluations, a contributor guide, to the problem of making an agent reliable in a domain. It is young, and we do not think we have it all figured out. Our posture is open on purpose: here is our current approach, here is where it is weak, and we would like to hear how you would do it differently.
Separation of concerns comes first. Agents reason, skills guide, tools retrieve, and a tool never tries to infer intent. Each tool does one narrow job and returns plain data that drops into the next tool's input.
The reason principles exist at all is DRY (don't repeat yourself). Without a clear separation, the same piece of guidance ends up restated in four places: the skills, the host prompt, the tool descriptions, and the tool responses. That is four copies to keep in sync and four places to drift. Drawing the lines once, and writing them down in a contributor guide, is what keeps the whole thing maintainable as it grows.
The series
This is post one. Coming up:
- This post: what we open-sourced and the principles behind it.
- Query any data with an agent, through Malloy: a few-minute tutorial to get an agent answering real questions, plus the retrieval design in depth.
- Build or migrate a Malloy model with an agent (coming soon!): take your own data, or an existing LookML project, to a governed model.
- Evaluating and improving a semantic model (coming soon!): how to know whether a model returns trustworthy answers, whether they reconcile with your existing source of truth, and how to close the gaps.
If you want to start now, the tutorial is the place to go. If you are working on agents for your own domain, read the contributor guide, try the skills, and tell us where they fall short. Join the Malloy Slack and let us know how you would do this differently. The model is the product, and the best way to make it better is in the open.
