Data MCP server

What is a data MCP server?

A data MCP server is an MCP server whose job is to let an AI agent read your data. It sits in front of a database, a data warehouse or a business application such as your ERP or CRM, and it offers the agent a short menu of things it may do: list the tables, describe a table, run a query, fetch a record. The agent never sees a password or a connection string. It sees the menu.

The MCP entry in this dictionary explains the protocol itself. This entry is about the use of it that most companies meet first: someone wants to ask Claude, Copilot or a home-built agent a question about sales figures, and the shortest path is to put an MCP server between the agent and the tables.

Compare it to the difference between handing a visitor the keys to your archive room and putting a colleague at the counter who takes requests. Both get the visitor an answer. Only the second lets you decide in advance which drawers may be opened, how many files come out at once, and who gets to know that a file was requested.

What a data MCP server exposes

Almost every data MCP server, whether you build it or buy it, has some mix of these tools.

• List tables
  The names of the tables or entities the agent may see. Not the whole database, only the allowlisted part.

• Describe a table
  Columns, data types, relationships and, if you did your homework, a description per column. The model uses this to write or pick a query, so its quality decides the quality of the answers.

• Run a read-only query
  The agent writes SQL, the server checks it, runs it under a read-only role with a timeout and a row limit, and returns the rows. This is where text-to-SQL lives.

• Run a saved query
  The agent writes no SQL at all. It calls revenue_by_country(period) and the server runs a query someone on your team wrote and tested. Microsoft's SQL MCP Server goes furthest here: it deliberately does not support text-to-SQL and builds every query itself from a configuration file of entities and permissions.

• Fetch a record
  One customer, one invoice, one order, by key. Servers in front of a business application, such as the Business Central MCP server, are mostly built from list and record tools of this kind, one set per API page.

Next to tools, MCP has resources: passive, read-only content the client can pull into the model context. For a data server the useful resource is a data dictionary, a document that says what "revenue" means at your company, which date column is the one that counts and which tables are deprecated. Put it there once and every agent that connects reads the same definitions.

Data MCP server versus a direct database connection

The dimension that matters is what the agent can reach, and who decided that.

With a direct connection you give the agent a user name and a password, or an API key, and the database decides. Whatever that account can see, the agent can see, and anything the agent can read, a prompt injection can ask it to read too. The account was usually created for a person or an integration, so it has more rights than a question-answering agent needs, and nobody looks at the queries.

With a data MCP server you decide. You choose which tables and columns appear in the list, you attach a database role to the server that can read those and nothing else, you set the timeout and the row cap, and every tool call passes through code you control and can log. If the agent asks for something outside the menu, there is no tool to call, so the request fails before it reaches the database.

The MCP specification draws the same line: the server must validate inputs, apply access controls and rate limit calls; the client should show tool inputs to the user, set timeouts and log tool usage. A connection string does none of that.

The design choices that decide whether it is safe

A data MCP server is only as safe as the choices below. Most of them are configuration, none of them are optional.

1. Read-only by default
   The server's database role has SELECT and nothing else. Snowflake ships its SQL tool with read_only: true as the default, Business Central gives agents read access only until an administrator unblocks edit tools, and Supabase runs every query as a read-only Postgres user when you set its read_only flag. Treat any write tool as a separate decision with a person approving in front of it.

2. A dedicated database role
   Create a role for the server, not for a person, and point it at the reporting schema or a set of views, never at the raw transactional tables. If the role leaks, you know exactly what it could see.

3. Row-level security tied to the calling user
   A sales rep who asks about "my customers" should get the same rows they get in Power BI. That only works if the server passes the user's identity down. Fabric data agents, Databricks and Business Central all run the query as the signed-in user, so existing row-level security keeps working. A shared service account throws that away.

4. Query timeouts and row limits
   An agent will happily ask for every row in the fact table. Cap the result at a few hundred rows and the query at a few seconds. Fabric data agents cap answers at 25 rows and 25 columns; Snowflake's SQL tool takes a query_timeout in seconds.

5. An allowlist of tables and columns
   Expose the tables the questions need, and drop the columns nobody should see in a chat: salaries, IBANs, national register numbers. Fewer tables also make the agent more accurate, because the schema it reasons over is smaller.

6. No service-role or admin keys
   A service-role key skips row-level security by design. The Supabase case that General Analysis published in July 2025, covered in the tool poisoning entry, worked because the agent held one and read a support ticket that told it what to query.

7. Log every query
   Store the tool name, the parameters, the generated SQL, the user and the row count for every call. When a number in a board pack looks wrong, this log is how you find out which query produced it.

Where text-to-SQL fits in

A data MCP server is the place where text-to-SQL either runs or gets replaced. In the open version, the model writes the query and the server constrains it: read-only role, allowlist, timeout, row cap. In the closed version, the server only has saved queries, and the model's job shrinks to picking the right one and filling in the parameters.

The closed version answers fewer questions and gets those right every time. The open version answers almost anything and is sometimes confidently wrong, because a wrong join returns a number rather than an error. Most companies end up with both: saved queries for the figures that go to management, plus an open query tool labelled as exploratory. Snowflake's guidance is to keep that free SQL tool on a separate server with its own least-privileged role, so a client cannot use it to get around the governed path.

What vendors ship

These are examples, and the list changes every quarter. Check the vendor page before you decide anything.

Microsoft SQL MCP Server is part of Data API builder from version 1.7. You describe entities and their permissions per role in a JSON file, and the server exposes seven tools such as describe_entities and read_records, plus stored procedures as named tools. Self-hosted and open source.

Fabric data agent can be published as an MCP server, in preview as of September 2026. The whole agent becomes a single tool: the client sends a question, the agent picks a lakehouse, warehouse, semantic model or KQL database, generates a read-only query as the calling user and returns the answer.

Snowflake has a managed MCP server, generally available, defined with a CREATE MCP SERVER statement. Tools are Cortex Analyst for natural language to SQL against a semantic view, Cortex Search, plain SQL execution, and your own functions and procedures. Access to the server does not grant access to the tools; each tool needs its own privilege.

Databricks has five managed MCP servers in public preview, including Genie for natural language analytics, Databricks SQL and Unity Catalog functions. Unity Catalog enforces permissions and requests run on behalf of the signed-in user.

Supabase ships an MCP server for its Postgres projects with tool groups you switch on, a read_only flag and a project_ref scope. Supabase's own documentation says to point it at a development project, not production.

Business Central MCP server is one Microsoft-hosted endpoint. You pick which API pages become tools and which operations each allows; read is on by default, create, modify and delete are off. Sign-in goes through Microsoft Entra ID, so every action carries the user's identity into the audit trail.

Peliqan adds an MCP server on top of its data platform. You sign in with your Peliqan account and get tools to explore the tables and query tables you manage there, and you can publish your own Python functions as MCP tools with the filtering you want, such as returning only the deals owned by the person asking.

Where an SME should start

You do not need a platform to start. You need four things.

1. One read-only role on the reporting database
   Not on the ERP. Point it at the views or warehouse tables your reports already use, so the agent and the dashboards read the same numbers.

2. Five saved queries as tools
   Pick the five questions people actually ask: revenue by month, open invoices by customer, stock below minimum, orders per sales rep, gross margin by product group. Each becomes one tool with one or two parameters.

3. One metric definition per query
   Write down, in the tool description, what the number means: "net revenue, excluding credit notes and intercompany, by invoice date". The model reads that every time, and so does the colleague who wonders why the agent's figure differs from the spreadsheet.

4. A test question set before anyone else gets access
   Twenty questions with the answer you expect, including five the agent should refuse: "list all salaries", "delete the test orders". Run them after every change to the server, the way you test a report before you publish it.

Only when those five tools answer correctly and the log shows what you expect do you add an open query tool, and only for people who can read the SQL it produces.

What to watch out for with a data MCP server

Tool descriptions are prompts
Everything you write in a tool description lands in the model's context. Keep it short, write it for the model, and review changes to it the way you review code.

Your data leaves through the client
The rows a tool returns go to whichever AI client called it. Microsoft warns that answers from a Fabric data agent used as an MCP server can be processed and stored under the terms of that client. Choose the client with the same care as the server.

Tool limits are real
Snowflake allows 50 tools per server and Copilot Studio 70 per agent, and the more tools a model sees, the more often it picks the wrong one. Five good tools beat fifty generated ones.