OpenMetadata is a catalog before it is an AI tool
OpenMetadata gathers technical metadata, lineage, owners, quality results, glossary terms, policies, contracts, conversations, and operational notes into a common graph. The practical payoff is shared context. A data engineer can trace a dashboard to its source tables, a steward can attach definitions and classifications, and an assistant can ask which assets are trusted without connecting directly to every warehouse. The AI language in the README is prominent, but the catalog and governance system underneath it is the actual product.
The scope is large: the README advertises more than 130 connectors and over 700 JSON schemas, alongside APIs, events, webhooks, and SDKs in Python, TypeScript, and Java. MCP exposes search, lineage, entity details, contracts, ownership, quality tests, and metadata mutations to compatible clients. This can reduce custom glue for an organization that already maintains catalog content. An empty catalog still gives an agent very little, so owners, terms, quality checks, and lineage need ongoing stewardship.
MCP gives agents governed metadata, including write tools
The built-in MCP endpoint can feed a coding agent schema details, business terms, upstream dependencies, and quality status. That is more useful than handing the agent raw database credentials because catalog policies and definitions travel with the technical structure. OpenMetadata also lets MCP clients update descriptions, tags, owners, glossary terms, lineage, and tests. Those mutations require stricter permissions than search, especially when an assistant can influence the catalog other people trust.
Release 2.0 enables the MCP server by default and adds cursor pagination while retaining offset parameters. An issue opened on August 26 says the server shipped 24 tools, including several overlapping create and read operations, which adds repeated schema cost to each model request. A linked pull request proposes reducing them to 15. The report is specific and current, and it shows that the agent interface is being revised rather than frozen. Evaluate tool names and permissions against the exact release you deploy.
What happened when we ran it
Our Node 22 sandbox installed the repository root in 18 seconds. Yarn added 110 packages and used 93 MB. The checkout was 296.6 MB with 16,688 files and about 2,902,129 source lines. No build script or target was available to the harness, so build was skipped. The repository carried 61 CI workflow files, which indicates that the real validation paths are split across a much larger codebase than the root package exposes.
The root test command failed after 4 seconds. Its complete useful message was Error: no test specified, followed by Yarn reporting exit code 1. There were no test results to count and no hidden application failure to diagnose. The root script is a placeholder, so yarn test is not a contributor smoke test. Our run also found no top-level tests directory and no Dockerfile under the harness signals, although the product documentation distributes a Docker Compose deployment.
That distinction matters for purchasing and contributing. The 110-package install proves that the root JavaScript package resolves in a clean container. It does not start the server, compile the Java backend, connect a search engine, run ingestion, or exercise the UI. A new contributor must follow the dedicated development and test guides. An evaluator should run the published Compose stack or sandbox, then connect a real source and inspect the metadata it produces.
A local trial needs 6 GiB and 4 vCPUs
The official Docker quickstart requires Docker 20.10 or newer, Compose 2.1.1 or newer, at least 6 GiB of memory, and 4 vCPUs. It brings up OpenMetadata on port 8585 with database, search, and ingestion services. The published stack includes default OpenMetadata and Airflow admin credentials, both set to familiar admin values. Those are acceptable for a closed local trial and unsafe as deployed credentials. Persistent volumes, backups, TLS, and an external identity provider belong in a production plan.
Connector work is the next cost. Warehouses, BI systems, pipeline tools, and storage services each need credentials and scheduling. Semantic search adds an LLM configuration plus embedding provider credentials. The Python SDK version must match the server version. None of this makes OpenMetadata unusually bad among enterprise catalogs, but it means the five-minute demo is only a feature tour. The useful system begins after teams agree on owners, classifications, domains, and who fixes failed ingestion.
Release 2.0 makes upgrades an engineering project
Version 2.0.0 was released on August 24, 2026, two days before the repository's latest push. It changes the default profiler to dynamic sampling and stops collecting cardinality distribution by default. It moves embedding settings into llmConfiguration, updates ingestion images to Python 3.12, removes Great Expectations 0.x support, changes Databricks authentication structure, and migrates Knowledge Center pages into Context Center. Existing stored configurations are migrated in several cases, but external YAML and hard-coded links may require edits.
The combined GitHub counter showed 855 open issues and pull requests. That is a busy work queue, not a count of confirmed bugs. Current activity includes UI editor migration, connector fixes, MCP consolidation, lineage work, and data-type handling. One open issue documents NoSQL types such as Decimal128 and BSON Timestamp being converted into less precise catalog types. Teams using MongoDB, DynamoDB, Cassandra, Couchbase, or Bigtable should verify inferred column types before letting agents or governance rules depend on them.
Choose it when metadata ownership already has a home
OpenMetadata has enough surface area to replace several separate catalog, lineage, quality, and agent-context tools. Apache 2.0 licensing, active development, explicit upgrade notes, and a built-in MCP server make it a credible shortlist candidate. The deciding question is operational, not whether the feature list is long. If a platform team can own the services and the organization will maintain definitions and responsibility, the graph becomes useful. Without that ownership, a smaller discovery tool will create less machinery and fewer stale promises.