Evaluate the catalog behind the MCP interface
OpenMetadata gives assistants access to a catalog that people still need to maintain. That makes it relevant to teams with a discovery, lineage, quality, or governance problem as well as an AI integration requirement.
The README describes a graph connecting technical metadata, ownership, quality signals, lineage, policies, glossaries, contracts, and organizational memory. It advertises 130+ connectors and 700+ JSON schemas. Those are project claims, not connector coverage or schema validation results from our run.
The README describes MCP tools for search, entity details, lineage, contracts, memory, and metadata changes such as descriptions, tags, and owners. This is a reason to evaluate the catalog as an assistant interface. It does not establish that a particular assistant will produce accurate answers or that every connector will preserve the metadata your organization needs. Check read and write permissions against your intended workflow.
What our recorded run establishes
Our stored run took place on 2026-09-29 at commit 5b9079b6aebdea3cf3d390210861406c499609a5. It used Yarn at the repository root in a sandbox configured with 3 CPUs, 8g of memory, and image lab-node:22. The image label and runtime detection are not an independently captured runtime version check.
The install step exited 0 after 45.650 seconds, reported as 46 seconds in the summary. The parser recorded 110 dependencies and 94 MB of dependency installation size. The checkout summary recorded 20,097 files, approximately 3,461,675 source lines, 321.9 MB, and 64 CI workflow files. These describe the checkout and root dependency step, not a running OpenMetadata deployment.
The harness skipped the build because it found no root build script. That does not mean the application needs no build: detection also found Maven and a Makefile in a repository containing Node, JVM, and Python code.
The root yarn test command exited 1 after 11.638 seconds, reported as 12 seconds. It invoked echo "Error: no test specified" && exit 1. No product test suite ran, and no passing-test count is available. This placeholder result does not show that OpenMetadata is broken.
We did not deploy the server, run a backend build, exercise the UI, check an installed product binary, ingest a source, or measure a workload. The record contains no audit result. Its parser summaries do not establish exhaustive test coverage. The harness also did not detect a Dockerfile, Compose file, or top-level tests directory in its checked scope; those signals do not establish their absence throughout the project or its releases.
Use the Docker trial to assess deployment
The v2.0.x Docker quickstart requires Docker 20.10.0 or newer, Compose v2.1.1 or newer, and at least 6 GiB of memory and 4 vCPUs allocated to Docker. Our 3-CPU sandbox did not meet that documented CPU allocation and did not attempt the deployment.
The supplied guide uses 2.0.5 release Compose files and starts database, Elasticsearch, server, and ingestion services. It documents the OpenMetadata UI at port 8585 and Airflow at port 8080, with default login credentials. Configure credentials and security before exposing a deployment. Treat storage, backups, authentication, and ingestion scheduling as deployment planning work rather than results verified here.
For a useful trial, connect one representative source. Check its owners, descriptions, inferred types, quality results, and lineage against what your team expects. Then exercise the assistant workflow with permissions appropriate to its read and write operations. The README also instructs users to match the Python SDK version to the server version.
Check the 2.0 upgrade requirements separately
The 2.0.0 release notes describe MCP as enabled by default and add cursor pagination while retaining offset parameters. They also require moving embedding configuration into llmConfiguration.embeddings and enabling the relevant LLM settings. An existing semantic-search configuration therefore needs explicit review during an upgrade.
The profiler defaults to dynamic sampling, with cardinality distribution no longer collected by default. The notes say existing profiler configurations are preserved; workflows using default agent configuration need attention if they depend on distinct-value metrics. We did not measure query cost or execution-time changes.
Other documented actions include updating external Databricks pipeline authentication YAML, replacing Knowledge Center links with Context Center links, and migrating Great Expectations 0.x to ~=1.3. Ingestion images use Python 3.12, but the notes explicitly say that change first shipped in 1.13.4. Custom image work depends on the version you are upgrading from. These are release-note requirements, not migrations performed in our run.
Compare deployment choices with maintenance in view
DataHub is a relevant comparison for teams seeking a metadata graph, column-level lineage, governance, and discovery. Its README explicitly separates self-hosted OSS from managed Cloud. Compare the offering you would actually deploy rather than assuming Cloud capabilities apply to OSS.
Amundsen describes a discovery engine that indexes data resources for search. Its repository also says it was archived in September 2026 due to inactivity. That maintenance status belongs in any recommendation: it remains relevant to existing deployments and architectural study, but a new deployment needs an explicit maintenance plan.
How to read the scores
These are editorial assessments of the supplied evidence, not benchmark results. Setup rates documented deployment effort: 1 means substantial assembly, 3 means a guided deployment with operational work, and 5 means a verified simple setup. Documentation rates the clarity and coverage of the supplied material. Community rates demonstrated maintenance and support evidence. Maturity rates demonstrated operational reliability and upgrade predictability. For the latter three, 1 means little supporting evidence, 3 means useful but incomplete evidence, and 5 requires broad corroboration. Missing evidence limits the score; it does not prove poor product quality.
OpenMetadata earns a place in an evaluation when someone will own both the services and the catalog content. The next useful evidence is a working deployment with a representative source, not another successful root dependency install.