MCP builder tools return wrong results without an error: min/max of a DateTime is 0, and unknown options such as having are silently ignored #3543

Summary

Two cases where clickstack_table / clickstack_timeseries return a plausible-looking answer that is wrong, with no error or warning. Agents can't tell, so they build conclusions on them.

1. min/max on a DateTime column return 0. Every non-count aggregate wraps its value in toFloat64OrDefault(toString(expr)) (packages/common-utils/src/core/renderChartConfig.ts:540-543). For Date/DateTime/DateTime64, toString() gives '2026-11-04 08:00:00.000000000', which doesn't parse as a float, so every value becomes 0 and max(Timestamp) is 0.
2. Unknown options are dropped. The tool input schemas are plain z.object(...) (e.g. tableSchema in packages/api/src/mcp/tools/query/table.ts:32), so zod strips keys it doesn't know. having: "lines > 5" is accepted, the SQL has no HAVING, and rows with 1 come back. Agents try having because dashboard tiles support it (packages/api/src/mcp/tools/dashboards/schemas.ts:839).

Environment

HyperDX 2-nightly image (late Oct 2026) with ClickHouse 26.10.3. Code references checked on main at d08b2fa (2026-11-03, 2.43.1).

Steps to reproduce

1. clickstack_table on a log or trace source, select: [{aggFn: "min", valueExpression: "Timestamp", alias: "first_seen"}, {aggFn: "max", valueExpression: "Timestamp", alias: "last_seen"}], any time range with data.
2. Result: first_seen: 0, last_seen: 0. The SQL in system.query_log is max(toFloat64OrDefault(toString(Timestamp))).

The cast alone, on any ClickHouse:

WITH arrayJoin([toDateTime64('2026-11-04 07:59:01.123', 9), toDateTime64('2026-11-04 08:00:00', 9)]) AS Timestamp
SELECT max(toFloat64OrDefault(toString(Timestamp))) AS rendered, max(Timestamp) AS expected
-- rendered = 0, expected = 2026-11-04 08:00:00.000000000

3. clickstack_table with groupBy and having: "count > 5": no validation error, the generated SQL has no HAVING, and groups with count 1 are returned.

Expected vs actual

Impact

In 4 agent investigations on production-size data (about 170 MCP calls), 3 asked "first seen / last seen" questions and got 0 back, and 2 used having and got unfiltered results (one call returned 1,044 groups, which then hit response trimming, see #3542).

Proposed fix

• min, max and any don't need a Float64 value. Pass the expression through uncast for them, or convert dates numerically (e.g. toUnixTimestamp64Milli) instead of via toString. The aggregate already handles numbers and numeric strings today, so a type check (date-like → no cast) keeps that behaviour.
• Make the MCP tool input schemas .strict(), so an unknown key returns a validation error listing the accepted options. Adding having and limit to clickstack_table itself, as tiles already support, is part of MCP response trimming replaces the largest values whole (often the top result) and ignores topN; clickstack_table has no limit, having or default order #3542.

Related

• MCP response trimming replaces the largest values whole (often the top result) and ignores topN; clickstack_table has no limit, having or default order #3542: MCP response trimming, and clickstack_table has no limit, having or default order
• Metric selects ignore valueExpression: gauge and sum charts always aggregate the raw value #3499: valueExpression ignored on metric selects
• count_distinct aggFn on metric tiles ignores valueExpression, always counts distinct metric Values #2311 / fix(common-utils): count distinct attribute values on gauge metric charts #3237: count_distinct on metric tiles