Semantic SQL layer and query execution engine with Python bindings, WebAssembly support, and LangChain/Pydantic AI integrations
WrenAI provides 6 well-named tools with clear verb-noun patterns (wren_query, wren_dry_plan, wren_list_models, wren_fetch_context, wren_recall_queries, wren_store_query). Descriptions are substantive (100-200 chars) and include usage guidance. Input schemas are present with types and descriptions for all parameters. However, output schemas are not documented in the source code provided, and error handling guidance is absent. Tool composition is sound, each tool has a single responsibility and outputs chain naturally (e.g., wren_fetch_context → wren_dry_plan → wren_query). Parameter descriptions are actionable (e.g., 'Default limit is 100 rows; increase only when you need more. Hard cap is 1000 rows'). No security issues detected (no credentials in params). Missing: documented return types, error recovery guidance, and per-tool error classification.
Plan SQL through MDL and return the expanded target-dialect SQL. Use this to verify your SQL targets Wren models correctly before running wren_query. Cheap (no DB round-trip).
Fetch relevant schema and business context for an analytical question. Call this BEFORE writing SQL so you query the correct Wren models and columns. Use ``item_type`` to narrow scope (e.g. only columns) and ``model`` to narrow to a single model when known.
List all models defined in this Wren project with column counts and descriptions.
Execute SQL through the Wren semantic layer and return rows. Use this after wren_dry_plan looks correct. Default limit is 100 rows; increase only when you need more. Hard cap is 1000 rows — beyond that, aggregate in SQL instead.
Recall up to *limit* past NL→SQL pairs similar to *question*. Useful as few-shot examples before writing new SQL. Pairs are previously confirmed by users (or seeded for the project).
Output schemas not documented. LLMs cannot plan downstream tool calls or extract required fields without knowing what wren_query, wren_fetch_context, and wren_recall_queries return.
No error handling guidance. Tools lack recovery hints (e.g., 'If SQL is invalid, check wren_dry_plan first' or 'If model not found, call wren_list_models'). Errors are not classified as retryable, user-fixable, or fatal.
wren_list_models description is minimal (27 chars). Does not explain when to call it, what structure it reveals, or how results chain to other tools.
wren_fetch_context 'item_type' enum is present but lacks guidance on when to use each value (model vs column vs relationship vs view). LLMs may guess wrong.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-23 | C | 69 | 2026-07-28+ | v2 |
Save a confirmed natural-language → SQL pair for future recall. Call this AFTER ``wren_query`` succeeds and the result was useful, so future agent runs can recall the example via ``wren_recall_queries``.
No confirmation or dry-run pattern for wren_store_query (a write operation). Agents could accidentally save incorrect NL→SQL pairs without verification.