Two problems in openmetadata-mcp SemanticSearchTool, found from a customer report on 1.13.1. Same on 1.13, 1.13.1, 1.13.2 and main.
1. A top-level entityType is silently ignored
parseFilters() only reads params.get("filters"), so a filter passed at the top level is dropped with no error and the search runs unfiltered:
{"query": "Active Customers", "entityType": "metric", "size": 3}returns two metrics and a database. {"filters": {"entityType": ["metric"]}} filters correctly.
The problem is the silence — the caller gets a wrong answer that looks right. It should return an error naming the correct nesting.
2. Metric results carry no metricExpression
cleanHit() returns a fixed ~15-field summary: name, description, tags, owners — but not the expression, which is most of what a metric is. It's already indexed and searchable via textToEmbed, just never returned. Small bounded string, worth adding.
extension (custom properties) is deliberately not proposed: it's unbounded user JSON and would compete with results for the response budget, dropping whole hits. It stays a get_entity_details / search_metadata concern.
Not blocking
get_entity_details, and search_metadata with fields: "metricExpression,extension", both return the fields correctly — verified live.
Two problems in
openmetadata-mcpSemanticSearchTool, found from a customer report on 1.13.1. Same on 1.13, 1.13.1, 1.13.2 and main.1. A top-level
entityTypeis silently ignoredparseFilters()only readsparams.get("filters"), so a filter passed at the top level is dropped with no error and the search runs unfiltered:{"query": "Active Customers", "entityType": "metric", "size": 3}returns two metrics and a
database.{"filters": {"entityType": ["metric"]}}filters correctly.The problem is the silence — the caller gets a wrong answer that looks right. It should return an error naming the correct nesting.
2. Metric results carry no
metricExpressioncleanHit()returns a fixed ~15-field summary: name, description, tags, owners — but not the expression, which is most of what a metric is. It's already indexed and searchable viatextToEmbed, just never returned. Small bounded string, worth adding.extension(custom properties) is deliberately not proposed: it's unbounded user JSON and would compete with results for the response budget, dropping whole hits. It stays aget_entity_details/search_metadataconcern.Not blocking
get_entity_details, andsearch_metadatawithfields: "metricExpression,extension", both return the fields correctly — verified live.