Natural-language querying by industry
These examples show plain-language questions about operational, financial and support data. Start with known tables, ask one focused question and compare the returned rows with the intended query. Availability depends on the instance configuration.
- Choose the relevant business dataSelect the tables and clarify field names and units.
- Ask a focused questionState the time period, filters and result you want.
- Review the executed planCheck selected tables, conditions and calculations.
- Validate the business meaningCompare returned records with a known example.
Operations: the question nobody wrote a dashboard for
Dashboards answer the questions someone anticipated. Incidents produce the others.
Ask it directly
No ticket to the data team, no new panel, and the answer comes from live rows rather than yesterday's export.
{ "nl": "which services had more than 50 errors in the last hour?" }show the plan next to the answer
An operator acting on a number needs to know which table it came from. Return the plan alongside the rows and the answer becomes checkable.
Finance: self-service without a warehouse export
The recurring monthly questions are known; the follow-ups are not.
Scope it and ask
Name the relevant schemas so Ask has fewer tables to interpret. Schema selection narrows the question; it does not grant or enforce access.
{ "nl": "settled volume by currency last month", "schemas": ["fin.payments"] }permissions still apply
Use the intended database identity and verify permissions on the generated query. Check allowed and denied results. A natural-language prompt is not an access-control boundary.
Support: triage in the agent's own words
An agent asks about a customer mid-conversation and needs the answer now, not a query builder.
One sentence, one answer
Ordinary phrasing, over the same tables the product writes to.
{ "nl": "open tickets for acme corp older than three days" }Internal tools: an assistant with a real backend
The assistant should read the database, not a copy of it, and should be honest when it cannot.
Plan first, then run
Check the contract of the endpoint you use. In the documented /ask request, show_plan returns the plan alongside executed results; it is not a dry run. Review permissions before sending a request and inspect its plan and rows afterward.
{ "nl": "...", "plan_only": true } // inspect
{ "nl": "..." } // then executean agent can call this directly
MCP is not offered in the new one-token console flow while a compatible published server is being verified. Check MCP availability before planning an agent integration.
What these have in common
-
Inspect the plan and rows. A successful request can still reflect a misunderstood question.
-
Name the relevant tables. Give Ask enough context to identify the fields you mean.
-
Your policies still hold. The generated query runs as the caller, under the same row and column rules.
-
Start from zero — Ask, scope, inspect the plan.
-
Ask reference — Request fields, plan inspection and limits.