Collate OpenMetadata MCP Server

Widget generated by MCP Showcase
1. About
2. Examples
3. Connect & use

Introduction

This MCP server is provided by Collate, the company behind OpenMetadata — the open-source standard for data context, semantics, and metadata used by thousands of enterprise deployments. The server acts as a bridge between LLMs and your OpenMetadata/Collate instance, exposing your organization's data catalog, governance framework, and data quality systems through conversational AI.

The tools fall into several core categories: data discovery (keyword and semantic search, entity detail retrieval), lineage and impact analysis (dependency graphs, root cause analysis, lineage creation), and governance and metadata management (creating glossaries, terms, tags, classifications, domains, data products, and metrics). It also supports data quality operations (test definitions and test cases) and user context awareness (identity, ownership, and team roles).

Together, these tools let AI agents ground their answers in trusted business context — enabling accurate discovery, documentation, classification, and quality monitoring across your entire data estate, all backed by OpenMetadata's open context layer.

Use Cases

1. Discovering data assets by concept or keyword Combine semantic and keyword search to help users find the right tables, dashboards, or pipelines even when they don't know exact names.

  • Sample prompt: Find all BigQuery tables owned by the marketing team that contain customer spending or purchase history data.

2. Exploring entity details and schema Retrieve full descriptions, columns, tags, owners, and custom properties for a specific asset.

  • Sample prompt: Show me the full column details and description for the table analytics.prod.customer_orders.

3. Root cause and impact analysis Use lineage and dedicated root-cause tooling to diagnose why a data quality issue occurred and what downstream assets are affected.

  • Sample prompt: The dashboard "Daily Revenue Report" looks wrong. Run a root cause analysis to find any upstream data quality failures and tell me what downstream assets are impacted.

4. Tracing dependencies for a table Explore upstream sources and downstream consumers to understand data flow before making changes.

  • Sample prompt: Show me the upstream and downstream lineage for the table warehouse.sales.fct_transactions, going 3 hops in each direction.

5. Building and maintaining a business glossary Create glossaries and hierarchical glossary terms to standardize business vocabulary.

  • Sample prompt: Create a glossary called "Finance" and add a term "Net Revenue" with a description explaining it's total revenue minus returns and discounts.

6. Setting up data quality tests Look up available test definitions and create table- or column-level test cases to monitor data reliability.

  • Sample prompt: Add a data quality test on the "email" column of customers.prod.users to ensure values are not null, and a test that the table row count stays above 1000.

7. Governance: classifications, tags, and PII management Create classifications and tags to label sensitive data across your assets.

  • Sample prompt: Create a classification called "PII" that is mutually exclusive, then add a tag "Sensitive" under it for tagging personal data columns.

8. Organizing data into domains and data products Establish governance groupings by creating domains and data products tied to business value.

  • Sample prompt: Create a "Customer 360" data product under the Marketing domain and describe it as the unified view of customer profiles and engagement.

9. Bulk metadata enrichment via patching Update descriptions, owners, tags, or domain assignments on existing entities.

  • Sample prompt: Assign the "Finance" domain and set the owner to the data-engineering team on the table warehouse.finance.gl_entries.

10. Personal context and ownership review Answer identity questions and surface assets that need attention from the current user.

  • Sample prompt: What teams am I on, what's my role, and which of the tables I own are missing descriptions or a tier?

11. Registering business metrics/KPIs Define measurable KPIs with expressions, granularity, and units for governance and reuse.

  • Sample prompt: Create a metric called "DailyActiveUsers" as a SQL COUNT with daily granularity that counts distinct user_id from events.prod.sessions.

12. Creating lineage relationships manually Explicitly connect two assets where automated lineage is missing.

  • Sample prompt: Create a lineage relationship showing that the pipeline "etl_orders" feeds into the table warehouse.sales.fct_orders.

13. Auditing data quality across the catalog Search test cases and test suites to review the health of monitored assets.

  • Sample prompt: List all failing test cases in the sales database and show me the latest results for each.

Details

MCP Server URL:
https://sandbox.open-metadata.org/mcp
Type:
HTTP Stream
Authentication:
API Key (Bearer Token)
How to connect this MCP server

Tools

search_metadata
Keyword-based search for data assets and data quality entities in OpenMetadata. Best when you know specific names, owners, tags, tiers, services, or column names. Use this for exact lookups (e.g., 'find table X', 'tables owned by team Y'), filtering by metadata properties, counting assets, and aggregations. Also searches data quality test cases and test suites when entityType is 'testCase' or 'testSuite' — these are NOT part of the default search scope, so always set entityType explicitly for data quality questions. Supports pagination and advanced OpenSearch DSL queries. Choose this over semantic_search when the query targets known identifiers or structured attributes. Results include 'fullyQualifiedName' and 'entityType' — pass these directly to get_entity_details for full entity information.
semantic_search
Meaning-based discovery of data assets using vector embeddings. Best for exploratory or vague queries where you don't know exact names — it finds conceptually related assets even when no keywords match. Use this when the user describes what data they need in plain language (e.g., 'tables about customer spending behavior', 'anything related to revenue forecasting'). Returns entity summaries with name, columns, description, and metadata. Choose this over search_metadata when the query is about meaning or concepts rather than specific identifiers or attributes. Results include 'fullyQualifiedName' and 'entityType' — pass these directly to get_entity_details for full entity information.
get_entity_details
Get detailed information about a specific entity by its fully qualified name, including its custom properties (returned under the 'extension' field). IMPORTANT: Use the 'fullyQualifiedName' and 'entityType' values directly from search_metadata or semantic_search results — do not construct the FQN manually. Response is optimized for LLM context: verbose index/noise metadata fields are excluded. Descriptions (entity-level and per-column) are returned in FULL and are never truncated — total response size is bounded by column pagination instead. Only the raw schema DDL and dbt model SQL carry a large safety cap (~30000 characters, flagged with 'schemaDefinitionTruncated' or 'sqlTruncated' inside 'dataModel') to keep the response retrievable; realistic DDL/SQL is well under this. For wide entities (many columns), the 'columns' array is paginated: when it is capped the response sets 'columnsTruncated' with 'totalColumns', 'returnedColumns', 'columnOffset' and 'hasMoreColumns'. When 'hasMoreColumns' is true, fetch the next page by calling again with 'columnOffset' set to the previous 'columnOffset' + 'returnedColumns'; when it is false there are no further columns to retrieve.
get_user_context
Get context about the CURRENT authenticated user: identity (id, name, displayName, email, isAdmin, isBot), team memberships, roles (direct and team-inherited), domains, active persona, and lightweight summaries of owned and followed entities. Use this to answer identity questions such as 'what is my role?', 'which teams am I on?', 'what do I own?', or 'what do I follow?' before asking the user for their email. The user is resolved from the authenticated request; there is no user parameter and the tool cannot read another user's context.
create_glossary_term
Creates a new Glossary Term. Note that a glossary term must be part of a Glossary, so the glossary must be specified in the parameters. If you can't find the right glossary to use, respond back to the user to create a new Glossary first. Note that you can help the user to create the Glossary as well. If you don't find any Glossary that could be related, please list to the user the available Glossaries so users can choose if they want to create or reuse something. Also, note that glossary terms can be hierarchical: for example, a glossary term 'Accounts' can have a child term 'Credit Account', 'Savings Account', etc. So if you find any terms that can be related, it might make sense to create a new term as a child of an existing term.
create_glossary
Creates a new Glossary. A Glossary is a collection of terms that are used to define the business vocabulary of an organization. Typically, similar terms are grouped together in a Glossary. For example, a Glossary names 'Marketing' could contain terms like 'Campaign', 'Lead', 'Opportunity', etc.
patch_entity
Patches an Entity based on a JSONPatch. Beforehand the Entity should be validated by finding it and creating a proper patch. IMPORTANT field naming rules: all array/list fields use PLURAL names in the JSON body — use 'domains' (not 'domain'), 'owners' (not 'owner'), 'tags' (not 'tag'), 'reviewers' (not 'reviewer'). Domain values must be entity reference objects: {"id": "<uuid>", "type": "domain"}. Owner values must be entity reference objects: {"id": "<uuid>", "type": "user" or "team"}. To add a domain: [{"op": "add", "path": "/domains/0", "value": {"id": "<domain-id>", "type": "domain", "name": "<domain-name>"}}]. To replace description: [{"op": "add", "path": "/description", "value": "new description"}]. Always look up entity UUIDs using search or get tools before patching.
get_entity_lineage
Get a compact lineage graph (upstream/downstream dependencies) of a specific entity. Use this for root cause (upstream entities) or impact (downstream entities) analysis and explaining dependencies between entities. By default the response is table-level and optimized for size: each edge carries the connected assets' names, FQNs, types and relationship info (pipeline or sql), with long SQL truncated. Set includeColumnLineage=true only when the user explicitly asks about column-level lineage.
create_lineage
This tool can be used to create lineage between two assets. It takes the source and target asset details and creates a lineage relationship between them.
get_test_definitions
This tool can be used to get all the test definitions in the OpenMetadata. It returns a list of test definitions. These test definition can be used to create a test case for a table or a table's column. While creating column test for entity, column data type should be in supportedDataTypes of parameterDefinition.
create_test_case
This tool can be used to create a test case for a table or a table's column. It needs test definitions. These test definition can be found using the get_test_definitions tool. If this fails do not do other operations.
create_metric
Creates a new Metric entity in OpenMetadata. A Metric represents a measurable business or technical KPI (e.g. daily revenue, error rate). Use this to register new metrics with optional expression, type, granularity, and unit of measurement. Metric can be expressed in SQL, Python, Java, or JavaScript.
create_classification
Creates a new Classification in OpenMetadata. A Classification is a top-level container that groups related Tags (e.g. 'PII', 'Tier'). The 'name' becomes the root segment of every tag FQN under it. The 'mutuallyExclusive' flag is immutable once the classification exists: if you set it on an existing classification it is ignored and a '_warning' is returned. Owner and reviewer names must already exist in OpenMetadata. Any domain FQNs must already exist.
create_tag
Creates a new Tag inside a Classification in OpenMetadata. The tag FQN is 'Classification.TagName' (e.g. 'PII.Sensitive'). At least one of 'classification' or 'parent' MUST be provided. Provide 'classification' (the root classification name, which must already exist), and optionally 'parent' for a nested tag (the parent tag FQN, e.g. 'PII.PersonalData', which must already exist). If only 'parent' is given, the classification is derived from its root segment. If both are given, 'classification' must equal the root segment of 'parent'. Owner and reviewer names must already exist.
create_domain
Creates a new Domain in OpenMetadata. A Domain is a top-level governance grouping of data assets. To create a child domain, set 'parent' to the FQN of an existing parent domain (it must already exist). 'domainType' must be one of Source-aligned, Consumer-aligned, or Aggregate; it defaults to 'Aggregate' if omitted. 'experts' are OpenMetadata login names that must already exist. Owner names must also already exist.
create_data_product
Creates a new Data Product in OpenMetadata. A Data Product groups data assets that deliver business value and must belong to at least one Domain. Provide 'domains' as a list of existing domain FQNs (required, at least one; each must already exist). 'experts' are OpenMetadata login names that must already exist. Owner and reviewer names must also already exist.
root_cause_analysis
Performs comprehensive root cause analysis via data quality lineage. First identifies upstream failures that may be causing issues for the specified asset. If failures are found, automatically analyzes downstream impact to show which assets may be affected. Returns both upstream root causes and downstream impact analysis. In the response 'status' indicates whether upstream failures were found. If 'status' is 'failed', the 'upstreamAnalysis' can be used to identify the nodes and edges leading to failures and downstreamAnalysis can tell what all nodes in downstream are impacted. If 'status' is 'success', it means no upstream failures were found, and downstream impact analysis was not performed. Responses are compact and table-level by default: node and edge details are trimmed and SQL queries truncated to keep the payload within LLM context limits. Set 'includeColumnLineage' to true only when column-level lineage is needed.

Want to create a similar playground for your MCP?

Get Started Explore other servers