Skip to content

ContextCake and OpenMetadata

OpenMetadata calls itself a context layer. So do we. The words match. The job does not.

OpenMetadata is a data catalog. It crawls your warehouses, dashboards, and pipelines, then records what each table holds, who owns it, and what feeds it.

ContextCake is a context resolver. It reads the rules your team has written down — decisions, standards, runbooks, personal notes — and works out which one applies right now.

Both hand their answer to an AI tool over MCP. They are answering different questions.

OpenMetadata indexes data assets and answers questions about tables. ContextCake indexes written rules and answers questions about which rule applies. OpenMetadata indexes data assets Tables Dashboards Pipelines Catalog of your data “Which table has revenue in it, and who owns it?” ContextCake indexes written rules Company Team You One answer, with its sources “Which rule applies here, and who said it?”
Same phrase, different subject. One maps your data. The other maps what you decided about your work.
OpenMetadata ContextCake
What it indexes Data assets — tables, columns, dashboards, pipelines, models Written knowledge — decisions, standards, runbooks, notes
Where the truth lives A server you run: MySQL for entities, Elasticsearch for search Markdown files in git repos you already own
How it gets the data Python crawlers pull from 130+ connected systems It reads the folders and repos you point it at
When two sources disagree People review and approve one value Higher layer wins per section; the other rides along, dated
What you install Docker or Kubernetes, plus a database and a search engine One command, or a Mac app. No database, no services
Who runs it A data platform team One person, then their team
How AI reads it MCP server, under the same permissions as a user MCP server, reading the files you can already read

OpenMetadata copies your metadata into its own store. Crawlers run on a schedule and keep that copy fresh. The catalog becomes the place you look things up, and it has to stay up.

ContextCake never copies anything. A layer is a folder of Markdown or a git repo. Add the folder, and it is a layer. Read access is repo access — if you can clone it, you can read it, and if you cannot, it never reaches your agent. See the layer cake.

A catalog wants one right answer. Someone proposes a value, someone approves it, and that value becomes the record. This is the correct design for a column description. Two teams should not disagree about what orders.total means.

Written rules do not behave that way. The company sets a standard. Your team documents an approved exception. You carry a constraint that only applies to the machine in front of you. All three can be true at once, at different scopes. Flattening them into one approved value throws away the part that makes the answer safe.

A catalog collapses three competing values into one approved value and drops the rest. ContextCake ranks them, returns the winner, and carries the disagreement along with its date. A catalog converges Company says: Postgres Team says: SingleStore You say: read replica only SingleStore — approved the other two values not in the answer ContextCake ranks and keeps You say: read replica only Team says: SingleStore Company says: Postgres SingleStore team · 2026-03-04 also on record: Postgres company · 2026-01-12
The catalog picks a winner and drops the rest. ContextCake picks a winner and shows you what it beat, with the date.

The disagreement is the product. See conflicts and provenance for what an agent actually receives.

If you are choosing between the two for data work, choose OpenMetadata. It is a mature tool with real strengths we do not match and are not trying to match:

  • 130+ connectors. Snowflake, dbt, Airflow, Looker, Tableau, S3. We have none of this.
  • Column-level lineage. Change a column, see every dashboard that breaks.
  • A permission engine. Roles, policies, domains, approval workflows. Our access model is repo membership, which is simpler and much less precise.
  • A formal ontology. 700+ published schemas in JSON Schema and RDF. If your company needs its metadata to speak a W3C standard, they have that and we do not.
  • Data quality tests and contracts, wired into the same graph.
  • You have a warehouse and nobody can find the right table.
  • You need to know what breaks when a column changes.
  • You want owners, quality checks, and approvals on your data.
  • You have a platform team to run it.
  • Your agent keeps ignoring a rule that lives in someone’s head.
  • Your team’s practice differs from the company standard, on purpose.
  • You want to see why the agent was told something, not just what.
  • You want to start today, alone, without asking anyone for a server.

Most teams that want one do not want the other instead. They want both.

ContextCake reads a foreign MCP source as a layer. If your company already runs OpenMetadata, point a layer at it. Its graph joins the cascade as one more source, under the same precedence rules as everything else — and your team notes can speak over it without editing the catalog.

An OpenMetadata deployment can act as one layer inside a ContextCake cascade, read over MCP, with team and personal layers stacked above it. One cascade. One of the layers is OpenMetadata. Your notes level 3 · local folder Team practice level 2 · git repo OpenMetadata level 0 · source: mcp resolve ContextCake merges by section MCP Your agent The catalog stays where it is. Nothing is copied, and nobody edits it to add an exception.
The foreign graph is translated to OKF at read time. The catalog is not modified, and it does not have to know we exist.

Pointing a layer at a system you do not control is a trust decision. Read the trust boundary first.

OpenMetadata tells your agent what your data is. ContextCake tells it what you decided — and who it should believe when the answers differ.