Databases | The .NET Blog

SQL MCP Server — The Right Way to Give AI Agents Database Access

Emiliano Montesdeoca — Fri, 10 Apr 2026 00:00:00 +0000

Let’s be honest: most database MCP servers available today are terrifying. They take a natural language query, generate SQL on the fly, and run it against your production data. What could go wrong? (Everything. Everything could go wrong.)

The Azure SQL team just introduced SQL MCP Server, and it takes a fundamentally different approach. Built as a feature of Data API builder (DAB) 2.0, it gives AI agents structured, deterministic access to database operations — without NL2SQL, without exposing your schema, and with full RBAC at every step.

Why no NL2SQL?

This is the most interesting design decision. Models aren’t deterministic, and complex queries are the most likely to produce subtle errors. The exact queries users hope AI can generate are also the ones that need the most scrutiny when produced non-deterministically.

Instead, SQL MCP Server uses an NL2DAB approach. The agent works with Data API builder’s entity abstraction layer and built-in query builder to produce accurate, well-formed T-SQL deterministically. Same result for the user, but without the risk of hallucinated JOINs or accidental data exposure.

Seven tools, not seven hundred

SQL MCP Server exposes exactly seven DML tools, regardless of database size:

describe_entities — discover available entities and operations
create_record — insert rows
read_records — query tables and views
update_record — modify rows
delete_record — remove rows
execute_entity — run stored procedures
aggregate_records — aggregation queries

This is smart because context windows are the agent’s thinking space. Flooding them with hundreds of tool definitions leaves less room for reasoning. Seven fixed tools keep the agent focused on thinking rather than navigating.

Each tool can be individually enabled or disabled:

"runtime": {
 "mcp": {
 "enabled": true,
 "path": "/mcp",
 "dml-tools": {
 "describe-entities": true,
 "create-record": true,
 "read-records": true,
 "update-record": true,
 "delete-record": true,
 "execute-entity": true,
 "aggregate-records": true
 }
 }
}

Getting started in three commands

dab init \
 --database-type mssql \
 --connection-string "@env('sql_connection_string')"

dab add Customers \
 --source dbo.Customers \
 --permissions "anonymous:*"

dab start

That’s a running SQL MCP Server exposing your Customers table. The entity abstraction layer means you can alias names and columns, limit fields per role, and control exactly what agents see — without exposing internal schema details.

The security story is solid

This is where Data API builder’s maturity pays off:

RBAC at every layer — each entity defines which roles can read, create, update, or delete, and which fields are visible
Azure Key Vault integration — connection strings and secrets managed securely
Microsoft Entra + custom OAuth — production-grade authentication
Content Security Policy — agents interact through a controlled contract, not raw SQL

The schema abstraction is particularly important. Your internal table and column names never get exposed to the agent. You define entities, aliases, and descriptions that make sense for the AI interaction — not your database ERD.

Multi-database and multi-protocol

SQL MCP Server supports Microsoft SQL, PostgreSQL, Azure Cosmos DB, and MySQL. And because it’s a DAB feature, you get REST, GraphQL, and MCP endpoints simultaneously from the same configuration. Same entity definitions, same RBAC rules, same security — across all three protocols.

Auto-configuration in DAB 2.0 can even inspect your database and build the configuration dynamically, if you’re comfortable with less abstraction for rapid prototyping.

My take

This is how enterprise database access for AI agents should work. Not “hey LLM, write me some SQL and YOLO it against production.” Instead: a well-defined entity layer, deterministic query generation, RBAC at every step, caching, monitoring, and telemetry. It’s boring in the best possible way.

For .NET developers, the integration story is clean — DAB is a .NET tool, the MCP Server runs as a container, and it works with Azure SQL, which most of us are already using. If you’re building AI agents that need data access, start here.

Wrapping up

SQL MCP Server is free, open-source, and runs anywhere. It’s the prescriptive approach from Microsoft for giving AI agents secure database access. Check out the full post and the documentation to get started.

SQL MCP Server, Copilot in SSMS, and a Database Hub with AI Agents: What Actually Matters from SQLCon 2026

Emiliano Montesdeoca — Sat, 28 Mar 2026 00:00:00 +0000

Microsoft just kicked off SQLCon 2026 alongside FabCon in Atlanta, and there’s a lot to unpack. The original announcement covers everything from savings plans to enterprise compliance features. I’m going to skip the enterprise pricing slides and focus on the pieces that matter if you’re a developer building things with Azure SQL and AI.

SQL MCP Server is in public preview

This is the headline for me. Azure SQL Database Hyperscale now has a SQL MCP Server in public preview that lets you securely connect your SQL data to AI agents and Copilots using the Model Context Protocol.

If you’ve been following the MCP wave — and honestly, it’s hard to miss right now — this is a big deal. Instead of building custom data pipelines to feed your AI agents context from your database, you get a standardized protocol to expose SQL data directly. Your agents can query, reason over, and act on live database information.

For those of us building AI agents with Semantic Kernel or the Microsoft Agent Framework, this opens up a clean integration path. Your agent needs to check inventory? Look up a customer record? Validate an order? MCP gives it a structured way to do that without you writing bespoke data-fetching code for every scenario.

GitHub Copilot in SSMS 22 is now GA

If you spend any time in SQL Server Management Studio — and let’s be honest, most of us still do — GitHub Copilot is now generally available in SSMS 22. Same Copilot experience you already use in VS Code and Visual Studio, but for T-SQL.

The practical value here is straightforward: chat-based assistance for writing queries, refactoring stored procedures, troubleshooting performance issues, and handling admin tasks. Nothing revolutionary in concept, but having it right there in SSMS means you don’t need to context-switch to another editor just to get AI help with your database work.

Vector indexes got a serious upgrade

Azure SQL Database now has faster, more capable vector indexes with full insert, update, and delete support. That means your vector data stays current in real time — no batch reindexing needed.

Here’s what’s new:

Quantization for smaller index sizes without losing too much accuracy
Iterative filtering for more precise results
Tighter query optimizer integration for predictable performance

If you’re doing retrieval-augmented generation (RAG) with Azure SQL as your vector store, these improvements are directly useful. You can keep your vectors alongside your relational data in the same database, which simplifies your architecture significantly compared to running a separate vector database.

The same vector enhancements are also available in SQL database in Fabric, since both run on the same SQL engine underneath.

Database Hub in Fabric: agentic management

This one is more forward-looking, but it’s interesting. Microsoft announced the Database Hub in Microsoft Fabric (early access), which gives you a single pane of glass across Azure SQL, Cosmos DB, PostgreSQL, MySQL, and SQL Server via Arc.

The interesting angle isn’t just the unified view — it’s the agentic approach to management. AI agents continuously monitor your database estate, surface what changed, explain why it matters, and suggest what to do next. It’s a human-in-the-loop model where the agent does the legwork and you make the calls.

For teams managing more than a handful of databases, this could genuinely reduce the operational noise. Instead of jumping between portals and manually checking metrics, the agent brings the signal to you.

What this means for .NET developers

The thread connecting all these announcements is clear: Microsoft is embedding AI agents at every layer of the database stack. Not as a gimmick, but as a practical tooling layer.

If you’re building .NET apps backed by Azure SQL, here’s what I’d actually do:

Try the SQL MCP Server if you’re building AI agents. It’s the cleanest way to give your agents database access without custom plumbing.
Enable Copilot in SSMS if you haven’t already — free productivity win for daily SQL work.
Look into vector indexes if you’re doing RAG and currently running a separate vector store. Consolidating to Azure SQL means one less service to manage.

Wrapping up

The full announcement has more — savings plans, migration assistants, compliance features — but the developer story is in the MCP Server, the vector improvements, and the agentic management layer. These are the pieces that change how you build, not just how you budget.

Check out the full announcement from Shireesh Thota for the complete picture, and sign up for the Database Hub early access if you want to try the new management experience.