Connect an AI agent to live data (MCP)

Connect an AI agent to live data (MCP)#

This tutorial gives you a working mental model for letting an AI agent — an LLM in any MCP-compatible client — answer questions against live data in Querona, without copying it anywhere and without the model writing SQL. By the end you will have exposed a virtual database over the Model Context Protocol (MCP) and asked an agent a question that can only be answered from fresh data.

For the concepts behind this, see Querona for AI; for the endpoints, see Open data endpoints.

The mental model#

Keep this picture in mind throughout:

AI agent / LLM
     │  calls governed tools (read · filter · aggregate · write where permitted · your functions)
     ▼
Querona  — entity layer + your permissions
     │  fetches on demand, no copy
     ▼
Live sources (databases, REST/SaaS, files, big data)

The agent never reaches your databases directly and never writes free-form SQL. It discovers a small, fixed set of tools that Querona generates from the objects you exposed, calls them with parameters, and Querona returns governed rows read from the live sources. Because nothing is materialized, every answer reflects the current state.

What you’ll use#

  • A running Querona instance (see Installation).

  • A virtual database exposing the objects you want the agent to use. You can build it over a database or a REST API — the REST tutorial shows the API case end to end.

  • An MCP-compatible client — for example an AI desktop app, an IDE agent, an agent framework, or MCP Inspector for a quick check. Any MCP client works, including a local LLM served through tools like Ollama.

Throughout, picture a small banking-style model: accounts, transactions and a payment_status view or function. The agent will use these to answer a question such as why a particular payment has not settled.

Step 1 — Model what the agent may use#

In a virtual database, expose only the tables, views and functions the agent should reach. A handful of well-named objects beats exposing everything: it keeps the tool surface small and the agent’s choices obvious.

Note

Give each object a clear description. Querona passes these descriptions to the model as part of each tool, so a good description (“Customer payments with current clearing status”) is what lets the agent pick the right tool for a question.

Step 2 — Grant a governed role#

An agent has no special privileges — it sees exactly what the identity it connects as is allowed to see. Create a dedicated role for the agent and grant it only what it needs (Access rights). Row- and column-level security, dynamic data masking and pseudonymization all still apply, so you can expose sensitive operational data and trust that the model only ever receives the permitted slice.

Step 3 — Publish over MCP#

The built-in Data API publishes your virtual database over REST, GraphQL and MCP at the same time. Make sure a Data API instance is running for the database (Managing Data API), and note the MCP endpoint URL and the authentication it expects — both are shown in the dashboard’s Interfaces / How to connect section, alongside the SQL Server and REST endpoints.

Step 4 — Connect your MCP client#

Point your MCP client at the endpoint from Step 3. Most clients take a small server entry like:

{
  "mcpServers": {
    "querona": {
      "url": "<MCP endpoint URL from the Querona dashboard>"
    }
  }
}

To verify the connection on its own, run MCP Inspector against the same URL:

npx -y @modelcontextprotocol/inspector "<MCP endpoint URL from the Querona dashboard>"

Supply whatever the endpoint requires — a token for a JWT-protected instance, or nothing for an instance left anonymous behind a trusted front end.

Step 5 — Let the agent discover the tools#

On connecting, the client asks Querona what it can do. It receives a predictable set of operations over your entities — read and filter records, aggregate them, call the functions you exposed, and, if the role from Step 2 permits, create, update or delete records — each described in plain language. This is the key difference from “text-to-SQL” tools: the model chooses among governed tools, it does not author queries, so its access is deterministic and bounded by the role from Step 2.

Step 6 — Ask a fresh-data question#

Ask something that is only answerable from current data, for example:

“Why hasn’t payment 10293 settled for account 5567?”

The agent reads your tool descriptions, calls the right ones (say, the payment and its status, the account balance and limits), passes the parameters, and composes an answer from the rows Querona returns. Those rows were read from the live sources at that moment — so if the payment clears a second later, asking again gives the new answer. No pipeline, no stale copy.

Why this stays safe#

Three properties make this suitable even for sensitive systems:

  • No copy — data is read on demand and never replicated into a vector store or warehouse to go stale or leak.

  • No free-form SQL — the agent calls a fixed set of tools, so it cannot run an arbitrary query.

  • Your governance, unchanged — the same roles, masking and row/column security that protect SQL and BI users protect the agent.

Next steps#

  • Querona for AI — the why behind this, and where it fits versus copy-first AI stacks.

  • Open data endpoints — the REST, GraphQL and MCP endpoints in full.

  • Materialization — when you do want to materialize, and why you usually should not for agent freshness.