An MCP Server for Databases: Safe, Read-Only Analytics in Plain Language

Most companies have one or two people who can answer questions from the database. Everyone else waits. A sales director wants last quarter's revenue by region. An operations lead wants late orders by warehouse. Each request joins a queue, and simple questions take days.

The cost is slower decisions and a quiet habit of guessing. People stop asking because the answer arrives too late to matter. Meanwhile the analyst spends their week on small queries instead of the deeper work they were hired for.

What this does

MCP (Model Context Protocol) is an open standard introduced by Anthropic. It lets AI assistants such as Claude, and other clients that support it, connect to tools and data through small programs called MCP servers. Support varies by AI client, so check each client's current documentation before you plan a rollout.

A database MCP server lets a manager ask a question in plain English. The answer comes from Postgres, MySQL, SQL Server or a similar database. The assistant chooses a tool, the server runs a safe query, and the result comes back with the query shown for checking. Typical questions include:

• "What was revenue by region last quarter, compared with the quarter before?"
• "Which products had more returns than usual this month?"
• "How many orders shipped late from each warehouse last week?"

The key word is safe. The design below keeps the assistant read-only, away from personal data and unable to slow down production.

Predefined tools versus free-form SQL

There are two ways to let an assistant reach your data. Each suits a different audience.

Predefined tools

Each tool runs a fixed, reviewed query with a few parameters, such as a date range and a region. Answers are fast and consistent. The model cannot write a bad join, because it never writes SQL at all. This suits managers and most staff.

Guarded free-form SQL

The model writes a query, and the server checks it before running it. It must be a single SELECT against approved views, with a row limit added. This handles unexpected questions, but answers need more checking. It suits analysts who can read the query and spot mistakes.

Most teams start with predefined tools for the top questions. They add guarded SQL later, for a small group, if demand is there.

How it works, step by step

1. Use a read replica. Queries run against a copy of the database, not the primary. A heavy query cannot affect customers.
2. Create curated views. We build views with plain names, such as sales_by_region_monthly, instead of exposing raw tables. Views hide joins and internal columns.
3. Leave out personal data. By default, views exclude names, emails, phone numbers and similar fields. Aggregates answer most business questions anyway.
4. Create a read-only user. The server connects with a database user that can only select from the curated views.
5. Offer two kinds of tools. Predefined tools answer common questions with fixed queries. A guarded SQL tool, if you want one, accepts only single SELECT statements against approved views.
6. Enforce limits. Every query has a row limit and a timeout. Results are summarised before they return to the assistant.
7. Log every query. We record the user, the question, the SQL that ran, the time taken and the row count.
8. Test with known answers. Before rollout, we check the assistant against questions where the correct answer is already known.

Tools we use

• MCP SDKs for Python or TypeScript.
• Python with FastAPI and standard database drivers for Postgres, MySQL and SQL Server.
• A SQL parser to check that guarded queries are single, read-only statements against allowed views.
• Your existing database and its native read replica or replication features.
• Structured logging to your existing log platform, so queries are searchable and auditable.

Database and AI client features change. Check your database vendor's and client's current documentation for replica, permission and MCP support.

What you need to get started

• A database administrator who can create a read replica, views and a restricted user.
• Twenty or so real questions people ask today, with known answers for testing.
• A short data dictionary, even an informal one, explaining what key tables and columns mean.
• A decision on which data is sensitive and must stay out of every view.
• An agreed AI client that supports MCP for your users.

Typical scope and timeline

As an estimate, a first read-only version typically takes one to three weeks. That covers a handful of curated views and predefined tools. The range depends on how tidy your schema is and whether a read replica already exists. Messy schemas take longer because the views do the cleaning. A guarded free-form SQL tool, if needed, usually follows once the curated views prove reliable.

Risks and how we handle them

Confident wrong answers

An assistant can misread a column and give a plausible but wrong number. Curated views with clear names reduce this. The assistant shows the query it ran, and we test against known answers before launch.

Exposing personal or sensitive data

The restricted database user can only read approved views. Personal fields are excluded at the view level, so no prompt can reach them.

Slow or expensive queries

The replica, row limits and timeouts protect production. We watch the query log for patterns that need a new view or an index.

Prompt injection and SQL injection

Text stored in the database can contain instructions aimed at the assistant. The server only runs validated read-only statements, and tool outputs are treated as data. See our MCP server security checklist for the full list.

When not to build this

If your BI tool already offers a natural-language feature that covers your questions and permissions, use it. If the same five numbers are needed every Monday, a scheduled report is cheaper and more predictable. Our guide to automated KPI reports in Slack and Telegram covers that route. And if your data needs heavy cleaning before anyone can trust it, fix that first. An assistant makes bad data easier to reach, not more correct.

If your questions live in documents rather than tables, a retrieval system is a better fit. See an internal knowledge assistant for Slack and Teams. If you also need answers from APIs and older business systems, read MCP for internal APIs and ERP systems.

How UnlockLive can help

UnlockLive IT is a Toronto-headquartered software agency with its own engineering team. We build these integrations for companies in the US, Canada, the UK and Australia. Our MCP server development service covers scoping, the threat model, the build, deployment and ongoing maintenance. Because database access is sensitive, our cybersecurity team can review the permissions, logging and threat model before rollout.

If you want a second opinion on scope or risk, book a free 30-minute call. Bring one or two questions your team asks every week, and we will tell you honestly whether an MCP server is the right tool.