A natural language dashboard lets someone type “What did we sell last month, by product?” and get an answer from live data. The same phrase is used for something much smaller: a chart Claude drew once from a pasted spreadsheet. Only the first is a system your team can rely on, and its hard parts are data access and checking the answer, not the chat box.
We build Claude integrations, including question-and-answer interfaces over business data, through our AI integration service, so weigh that. Every fact below about Anthropic, PostgreSQL and OWASP was checked against their own documentation in October 2026.
Short answer: You need four parts: a data source, a Claude API call that turns the question into a query, a database connection that can only read, and a check on the answer before anyone sees it. Named query tools are safer than free SQL. Enforce read-only access in the database, not the prompt, and make sure every number comes from the query result. Running costs are modest: in our worked example, 100 questions a working day on Claude Sonnet 5.5 cost about $51 a month at Anthropic’s published prices.
What the Documentation Says
As of October 2026, from Anthropic, PostgreSQL and OWASP documentation:
| Topic | What the docs say |
|---|---|
| Current models | Claude Opus 5.5, Sonnet 5.5 and Haiku 5.5 |
| Sonnet 5.5 price | $2 per million input tokens, $10 per million output |
| Haiku 5.5 price | $0.10 input, $0.50 output per million, for prompts up to 100,000 tokens |
| Batch API | 50% off, for requests that can wait |
| Prompt caching | 5-minute default; a Sonnet 5.5 cache hit is $0.10 per million tokens |
| Strict tool use | strict: true makes tool calls match your schema |
| Text-to-SQL | The cookbook gives Claude the schema and asks for SQL |
| Model retirement | At least 60 days’ notice for public models |
| PostgreSQL GRANT | SELECT can be granted per table or per column |
| Read-only default | Read-only transactions can’t alter non-temporary tables |
| Statement timeout | Aborts statements that run past the limit |
| OWASP LLM01 | Give the model the minimum access it needs |
Sources: Anthropic pricing, Claude models overview, prompt caching, tool use, SQL cookbook, model deprecations, PostgreSQL GRANT, PostgreSQL client settings, OWASP LLM01.
Claude-Generated Dashboards vs. Claude API-Powered Interfaces
“Claude built me a dashboard” usually means someone pasted a CSV into Claude and got a static chart. It’s useful once. The data never updates.
A Claude API-powered interface is different. A user types a question in plain English. Your application sends it to Claude with a description of your data, Claude proposes a query, your code runs it against the live source, and Claude turns the result into an answer. It runs against current data every time.
What “Natural Language Query” Means at the Architecture Level
At minimum, four components:
- A structured data source: a database, an API or a clean pipeline.
- A Claude API call that turns the question into a query or a tool call.
- A read-only connection to that source.
- A response layer that checks the output before the user sees it.
The validation layer is the one demos skip and production needs.
When This Makes Business Sense
Test it against your own reporting time. If people assemble the same figures by hand every week, a natural language dashboard is worth scoping. If reporting is already automated or rare, it probably isn’t, and a scheduled report may be the cheaper answer.
Use Cases That Fit
The strongest fits share three traits: a narrow set of sources, a known list of questions people already ask, and predictable volume. A small agency asking the same profitability questions every week fits.
Use Cases That Don’t Fit
Open-ended exploration over a large, messy dataset is a poor fit: the wider the questions, the more room for a plausible wrong answer. Unstructured data, such as scanned PDFs or inconsistent spreadsheets, needs a data pipeline before any language layer makes sense.
How to Build a Claude API Natural Language Interface
Define Inputs and Outputs Before Writing a Line of Code
Start with the questions, not the API. Write down every question your team asks today and group them by data source. The tables most of them touch are your first scope. Then define the output for each question type: a number, a short table, a sentence, or “I can’t answer that from this data”.
Connecting Claude to Your Data
Three realistic patterns:
- Direct API integration. Your application runs the queries and passes results to Claude. You control exactly what Claude sees.
- MCP. The Model Context Protocol is an open-source standard for connecting AI applications to external systems, including databases (source). You need an MCP server for your data source.
- Workflow tools such as Make, n8n or Zapier. These suit linear jobs, like a weekly digest, more than live questions.
With the direct API, the mechanism is tool use. You define a tool with an input_schema, Claude returns a tool_use block, and your application runs the operation and sends back the result (source). Claude never touches the database. Your code does.
Read-Only Access Belongs in the Database, Not the Prompt
A prompt that says “never modify data” is a request, not a control:
- SELECT-only grants. Give the dashboard its own role with SELECT on the tables, or columns, it needs. PostgreSQL supports column-level grants, though a table-level grant still covers every column (source).
- Read-only transactions.
default_transaction_read_onlysets whether new transactions are read-only, and those can’t alter non-temporary tables (source). It’s a default, so pair it with the grants. - A statement timeout.
statement_timeoutaborts any statement that runs past your limit (source), so one bad question can’t tie up the database.
OWASP’s prompt injection guidance says the same: restrict the model’s access to the minimum it needs, and handle functions in code rather than handing them to the model (source).
Prompt Architecture: Scoping Queries So Claude Doesn’t Hallucinate SQL
Anthropic’s cookbook shows the basic pattern: give Claude the schema and the question, ask for only the SQL, then run it (source). For production, add constraints:
- Name the tables and columns Claude may use, with a one-line meaning for each.
- Say what to return when the data can’t answer the question.
- Forbid estimating or filling in numbers.
- Check the SQL in code before running it: one statement, SELECT only, allowed tables, a row limit.
For a known question list, named queries are safer. You define tools like revenue_by_product with typed parameters, and Claude only picks the tool and fills in the dates. With strict: true, its tool calls match your schema exactly (source). Your code runs parameterised queries, which OWASP says offer more security guarantees than filtering input (source).
A schema match guarantees the shape, not that the numbers are right. Your response layer should compare figures in the answer with the rows the query returned.
Cost Controls for Production Use
You pay per token: input (instructions, schema, question, result rows) plus output. Our own worked example from Anthropic’s published prices (source), not a quote:
- Each question uses 8,000 input and 700 output tokens across its calls.
- On Claude Sonnet 5.5, that’s $0.016 plus $0.007, about $0.023 per question.
- At 100 questions a day for 22 working days, 2,200 questions cost about $51 a month.
If 4,000 of those input tokens are a fixed schema and instructions, prompt caching helps. A Sonnet 5.5 cache hit costs $0.10 per million tokens instead of $2, and the default cache lasts 5 minutes (source). That brings our example to about $34 a month before cache-write charges. Claude Haiku 5.5 is cheaper again, so test it on your questions.
The bigger risk is a question that drags thousands of rows into the prompt. Cap rows per query and aggregate in SQL. See our guide to context window management.
Worked Example: Reporting Dashboard for a 10-Person Agency
This is a worked example of how such a build is shaped, not a client story. Picture a 10-person agency with a project management tool, an analytics account and a financial spreadsheet updated by hand. They ask about utilisation by person, profitability by client and revenue against quarterly targets.
- Data access. Read-only API access to the project and analytics tools, and the spreadsheet replaced by a table that syncs from the accounting system.
- The Claude layer. One named query tool per question type, a prompt that lists the fields and the “can’t answer” response, and a check against the query result.
- Testing. Run the team’s real questions, log the misses, and fix the scope or tools, not only the prompt.
- Handover. The client owns the code, the API key sits in their own account, and the prompts are version-controlled.
When a question falls outside scope, the dashboard says so instead of guessing.
Related Posts
- How to connect Claude to your existing database: a query layer over what you have
- Claude API analytics reports in plain English: metrics into readable summaries
- Custom reporting automation with Claude: scheduled reports instead of live questions
- Designing AI tools for non-technical users: an interface people keep using
Frequently Asked Questions
What does it cost to build a Claude API natural language dashboard?
Build cost depends on your sources, data quality and question types, so we don’t quote a standard figure. Running cost is separate and usually small. In our worked example, 2,200 questions a month on Claude Sonnet 5.5 cost about $51 at Anthropic’s published prices.
Do I need a developer to build and maintain this?
Yes. It’s software, not a setting. Someone builds the data connection, tests the tools and prompts, and updates them when your schema changes. Someone has to own it.
How do I prevent Claude from hallucinating SQL or returning wrong numbers?
Limit what it can reach, limit what it can write and check what it returns. Use a SELECT-only role with a statement timeout, prefer named query tools over free SQL, and compare every number in the answer with the query result before a user sees it. Skip that and you have a demo.
Can Claude connect to our existing tools, CRM, Shopify, Google Ads?
Not on its own. Your integration layer connects to those tools through their APIs, or an MCP server, and passes the relevant data to Claude. Messy data gives unreliable answers whatever model sits on top.
What’s the difference between using Claude via MCP versus the direct API for a dashboard?
An existing MCP server can save integration work. The direct API with your own tools gives exact control over which queries exist and what data reaches Claude. For a known question list, we usually start with the direct API and named queries. MCP makes sense when a server for your source exists and fits your access rules.
What happens when Anthropic updates the Claude model?
Pin a specific model ID, such as claude-sonnet-5-5, and keep a test set of real questions with known answers. Anthropic gives at least 60 days’ notice before retiring a publicly released model and advises testing replacements well before that date (source). Run your test set on the new model before you switch.
Start with the Right Scope
A natural language dashboard fits a business with recurring questions, a bounded set of sources and clean data. It doesn’t fix undefined questions or messy infrastructure.