Skip to main content
This cookbook demonstrates how to build a natural language database query system using Mercury 2’s tool calling capabilities. The full loop — natural language question, SQL generation, execution, and formatted answer — completes in under 2 seconds. We walk you through how to:
  1. Load a SQLite database (sample or your own)
  2. Auto-detect the schema and define a SQL tool for Mercury 2
  3. Translate natural language questions into SQL using tool calling
  4. Execute queries and return natural language answers
  5. Measure end-to-end latency at each step

Run the SQL Agent

Directly via Google Colab or download the .ipynb to run it locally in Jupyter

Download Sample Database

Download the sample e-commerce SQLite database to use with the notebook.

Dependencies

Install packages and import the libraries required for the Mercury 2 API and SQLite:

API Keys

Set up your Inception Labs API key.
  1. Create a .env file in this directory
  2. Add your API key to the .env:
    • INCEPTION_API_KEY
The key will be automatically loaded from the .env file.

Initialize Client

Initialize the Inception (Mercury 2) client:

Load Database

We create a small in-memory e-commerce database with three tables — customers, products, and orders. If you want to use your own SQLite database instead, replace this cell with db = sqlite3.connect("your_file.db").

Inspect Schema

We introspect the schema directly from the database, so the tool calling setup automatically adapts to whatever tables are loaded:

Define the SQL Tool

We define a single tool — run_sql_query — that Mercury 2 can call to execute SQL against our database. The tool description includes the auto-detected schema so Mercury knows what tables and columns are available:

Query Helper

This function handles the full tool-calling loop:
  1. Send the user’s natural language question to Mercury 2 with the tool definition
  2. Mercury generates a run_sql_query tool call with SQL
  3. We execute the SQL and send results back to Mercury
  4. Mercury returns a natural language answer
We time each step to show the latency breakdown.

Natural Language Database Queries

Let’s run several queries and measure the full round-trip latency. Each query goes through: NL question, SQL generation, execution, and NL answer.

Query 1: Aggregation

“Who are the top 3 customers by total spending?”

Query 2: Filtering

“Which orders are still pending?”

Query 3: Join + Lookup

“Show me all orders placed by Sarah Lee.”

Query 4: Analytics

“What is the most popular product category by number of items sold?”

Query 5: Revenue

“What’s our total revenue from delivered orders?”

Latency Summary

Mercury 2’s diffusion-based architecture generates tokens ~5x faster than traditional autoregressive LLMs. In the queries above, the full tool-calling loop — understanding the question, generating SQL, executing it, and summarizing results in natural language — consistently completes in around 1-2 seconds. SQL execution itself is near-instant; the time is spent on two Mercury inference calls (tool call generation + answer generation), each typically under 1 second. This makes Mercury 2 fast enough to power real-time, interactive database assistants where users expect instant answers to ad-hoc questions — no waiting, no loading spinners.