Marmot: a single-binary data catalog that serves metadata to MCP agents

The problem Marmot targets: metadata that agents cannot reach

Most AI agents that touch data work from guesswork. Given a question about revenue, an agent will invent a table name, assume a column means what its label suggests, and join two things that were never meant to be joined. The failure is not the model. The failure is that the agent has no access to the catalog a human analyst would open first. Marmot's stated premise is exactly this: catalog your assets, then expose real metadata to your AI agents. The README frames the project as the open-source context layer for your AI, and the FAQ says Marmot exposes certified context through MCP so agents can query real metadata rather than guessing. The audience is data platform teams who already have a catalog problem but not the budget or headcount for an enterprise deployment. Marmot's pitch against that category is deployment shape: it ships as a single binary with a UI, and the README claims you can start cataloging in minutes. Whether that holds depends on your sources, since the catalog is only as complete as the plugins you run.

What gets cataloged, and what a plugin has to produce

Marmot's asset model is deliberately wider than tables. The FAQ lists five categories: tables from databases and warehouses, topics from message queues and event streams, queues from job and messaging systems, APIs including REST, GraphQL and internal services, and dashboards from visualization and BI tools. That breadth is the interesting design choice. A lineage graph that stops at the warehouse boundary cannot answer why a dashboard number moved, because the answer often lives in the Kafka topic or the service that produced the event. The README's feature list adds the metadata layer on top: ownership assignment, business context documentation, and shared glossaries. Those are human-authored fields, not scraped ones, and they are what the README means by certified context. The distinction matters for agent use. A scraped schema tells an agent that a column exists. A glossary entry tells it what the column means in the organization's language. Marmot stores both, and the MCP surface is meant to serve the second kind as well as the first.

How the pieces fit: plugins in, MCP out

The architecture visible in the README is a hub. Plugins pull metadata from external systems into the catalog, where it is stored alongside human enrichment and lineage edges. Three surfaces read it back out: the UI, an API, and an MCP server. The MCP server is the part that distinguishes Marmot from a conventional catalog, and it is listed as a repository topic alongside datacatalog and lineage. The README does not document the MCP transport, the tool names an agent would call, or how authentication works between an agent and the server. That is a gap, not a hidden feature. If you are evaluating Marmot specifically for agent integration, the repository description and the FAQ are the only confirmation you get that the MCP path exists; the operational details live in the documentation site, which this review has not read. The lineage feature is described as interactive, tracing data flows from source to destination so you can analyze impact before making changes. That implies lineage is derived from the plugins rather than declared by hand, though the README does not say how edges are constructed.

Getting it running: what the README actually gives you

The install instructions are thin by design. The README's Deploy section says only: if you are new to Marmot, follow the Deploy documentation for a guided setup. The FAQ adds a two-row table, offering either the documentation guide or downloading and running the single binary for your platform. There is no docker run line, no Helm chart reference, no configuration sample, and no environment variable list in the material provided. Development is pointed at a separate Local Development page. This is a real constraint for evaluation. You cannot judge from the README alone whether the binary expects an embedded store or an external database, what port the UI binds to, or how plugins are registered. Anyone who needs to size a deployment will have to read marmotdata.io/docs/Deploy first. The honest summary is that Marmot's distribution story is one command, but the README does not tell you what that command is.

The preview release line is the main adoption risk

The three most recent releases are v0.11.0-preview1, v0.11.0-preview2, and v0.11.0-preview3, pushed within eight days of each other in September 2026. That cadence is normal for active development and it is also a warning. Preview tags are not stability promises. For a catalog, instability has a specific cost: the metadata store is the artifact you accumulate over months, and a schema migration that goes badly can cost you the enrichment work your team typed in by hand. Before adopting Marmot, confirm what the upgrade path looks like between previews and whether the storage layer supports export. The README does not discuss backups, migrations, or version compatibility. A second limitation is scope. Marmot catalogs metadata; it does not appear to enforce access control over the underlying data, and the README makes no governance claims beyond the data-governance topic tag. If your requirement is policy enforcement or column-level masking, this is the wrong layer.

Where Marmot sits against DataHub and OpenMetadata

The obvious comparison set is DataHub and OpenMetadata, both open source, both built around a service-plus-storage deployment with a metadata ingestion framework. The difference in approach is packaging and center of gravity. DataHub and OpenMetadata assume you will run a multi-component stack and treat the catalog as a platform other tools integrate with. Marmot assumes one binary and treats the AI agent as a first-class consumer through MCP, which the other two do not lead with in their positioning. That is a genuine trade. You give up the ecosystem breadth and the maturity of a larger deployment, and you get a smaller operational surface and an MCP server that is part of the core product rather than an add-on. If your team already runs DataHub, adding Marmot means a second catalog with its own metadata to reconcile. If you have nothing and your first requirement is agent context, Marmot's shape is the more direct fit.

Licence, maintenance and what you are signing up for

Marmot is MIT licensed, which the FAQ states plainly: you can use, modify and distribute it, and self-hosting carries no licensing cost. MIT is permissive enough that embedding Marmot in a commercial internal platform raises no copyleft question, but the usual caveat applies: this is a description of the licence text, not legal advice, and if you plan to redistribute a modified binary, read the LICENSE file yourself. Maintenance cost is the harder number. The project is Go, which keeps the build simple, and the plugin system means every source you add is code you depend on. Each new plugin is a surface that can break when the upstream system changes its API. The README invites contributions specifically for new plugins, which suggests coverage is community-driven and uneven. Budget for reading plugin source before trusting a connector with production metadata, and check the contributing guide before assuming a fix will land on your schedule.

Editorial conclusion

Adopt Marmot if you want a self-hosted catalog whose primary consumer is an AI agent rather than a human analyst, and you are willing to run preview software. Do not adopt it if you need a stable release line or an SLA, because the newest tags are v0.11.0-preview1 through preview3. Before committing, verify the plugin list for your actual sources, confirm the MCP server's transport and auth model, and read the Deploy page at marmotdata.io/docs/Deploy to see what the single binary expects for storage and configuration.

Official sources

1. License: MIT
2. marmotdata/marmot on GitHub
3. Project website
4. README
5. Releases