WrenAI 0.15.0 makes “top N” mean ranked N across MCP cube queries
The release adds orderBy to the agent-facing cube tool and fixes query-rewrite edge cases that could change or break generated SQL.
WrenAI 0.15.0 closes a deceptively important gap in its agent-facing cube interface: an MCP client can now specify how a cube query should be ordered before applying a limit. The release also fixes several SQL-rewrite edge cases across supported warehouses.
A limit is not a ranking
Before this release, Wren’s cube engine already understood orderBy, but neither the wren cube query command nor the MCP query_cube tool exposed it. The merged implementation notes that the tool did expose limit, which meant a request such as “top five customers” could return an arbitrary five rows—or the earliest five under an existing time ordering—rather than the five largest values.
Version 0.15.0 adds an order_by argument to the MCP tool and a repeatable --order-by option to the CLI. Both accept member:direction specifications, with asc and desc validated by Wren’s core engine. Ordering and execution use the same query-building path, including the tool’s SQL-only mode. The tagged package also requires wren-core-py>=0.8.0, the binding version that carries the underlying cube-ordering support.
That is a correctness change, not just interface polish. In an agent workflow, LIMIT 5 can look plausible while answering the wrong question; adding explicit ordering turns the requested superlative into inspectable SQL with ORDER BY ... LIMIT 5.
The release tightens the rewrite boundary
The same release fixes wildcard detection for UNION, INTERSECT and EXCEPT. Previously, Wren’s rewriter inspected only the first branch of a set operation. A SELECT * in a later branch could therefore be missed, causing that branch to fall back to an explicit column list instead of passing wildcard visibility handling through Wren’s core layer. The fix walks every top-level branch while keeping nested subqueries in their own scope.
WrenAI 0.15.0 also repairs limit wrapping when input SQL ends in a line comment. In the affected connectors, putting the wrapper’s closing syntax and LIMIT on the same line allowed the trailing comment to consume them. The release lists fixes for BigQuery, DuckDB, PostgreSQL, Oracle, Redshift and Trino; the BigQuery and DuckDB patch adds a newline around the wrapped query and regression tests for the affected call sites.
For operators, the practical upgrade test is small: run a cube top-N request through the MCP tool, inspect the generated SQL for the expected ORDER BY, and include trailing-comment and set-operation cases in connector regression tests. Those checks target the precise boundaries changed in 0.15.0 rather than treating a successful tool call as proof that the ranking semantics survived translation.
sources
- WrenAI 0.15.0 releasegithub.com
- WrenAI PR #2730: expose cube orderBy through CLI and MCPgithub.com
- WrenAI PR #2743: detect SELECT * across set-operation branchesgithub.com
- WrenAI PR #2734: fix trailing-comment LIMIT wrapping for BigQuery and DuckDBgithub.com
- WrenAI 0.15.0 package metadataraw.githubusercontent.com
comments · 0