Introducing the SQL MCP Server | Jerry Nixon | .NET Day 2026
In a Nutshell
The SQL MCP Server is Microsoft's open-source solution that lets AI agents safely interact with databases without writing SQL queries themselves. It solves the core problems of agent-generated SQL—stochastic unpredictability, schema exposure, and SQL injection—by using a deterministic query engine that abstracts the database schema and builds queries based on agent instructions. The server provides built-in RBAC/OAuth security, multi-database support, caching via Redis, and pass-through authentication for proper audit trails, eliminating the need for developers to write thousands of lines of CRUD code while enabling secure agent-to-database interactions.
These notes were generated by AI and may contain inaccuracies.
Jerry Nixon works at Microsoft in the Data Platforms and Artificial Intelligence team, focusing specifically on SQL Server. This includes the entire Microsoft SQL family, from Azure database in the cloud to managed instances on virtual machines and on-premises servers. He currently works in the developer testing team and notes the significant investment SQL is making toward developers.
Jerry introduces the SQL MCP server as the third item from the top in the presentation. He also highlights the Data API Builder at the top of the same column, noting both pave the way for applications and software agents. When thinking about data-driven applications and data-driven proxies, both Data API Builder and SQL Server MCP become central to the discussion.
From a software engineer's perspective, the process of building applications begins with adding a database. When Microsoft SQL is added, it introduces substantial database interaction code into the application. This code links all database work to the application, making changes in one part require changes throughout. It also requires installing the database definition within the application.
Microsoft has made significant improvements to database definitions, recently announcing features that make it faster, more scalable, and fixing accumulated problems. However, because the database definition continues to be updated, applications must also continue updating their drivers. This creates a maintenance burden where security updates to database drivers become necessary.
The solution involves disconnecting the database integration by creating an API layer where the database driver can be installed. This moves Entity Framework code into the API, separating the work into two different places. This separation benefits maintenance, development, and updates since the API can be updated outside the application.
This approach is common when the API relates to the database. It allows database owners—whether DBAs, administrators, or developers—to look at the database and develop a consistent disclosure strategy for applications. By moving the API next to the database, the database is never spoken to directly but always handled through a controlled API.
The block of code for simple APIs includes classes, database context for Entity Framework, Data Transfer Objects (DTOs), unit tests, and CI/CD integrations. This can represent a quarter or a third of an application's codebase. Data API Builder addresses this by handling direct CRUD operations or executions against the database, allowing deletion of approximately one-third of the codebase.
Data API Builder is open source, made open source by Microsoft from the beginning 4 years ago. It is free to use against SQL or non-SQL databases, in Azure, locally, or in another cloud. This creates a compelling case for replacing large amounts of code in software architecture.
When agents need to talk to databases, they cannot do so directly because agents are the envelope surrounding models that provides instructions, security, and capabilities. Agents do not come with database drivers automatically—they communicate through a common gateway, which is MCP (Model Context Protocol).
A local or remote MCP server serves as the middle layer, similar to an API. It can be written in .NET and displayed like REST, functioning as a special type of REST dedicated to proxies. Local servers installed on devices are designed for developer development cycles and are typically more powerful, complementing remote servers deployed in production environments.
SQL Server MCP is an open-source, free MCP server that provides agents direct access to databases for CRUD operations on tables, views, or stored procedures. It is based on the Data API Builder tool, functioning as Data API Builder with a third endpoint. It remains free, secured, managed by Microsoft, and easy to install.
While MCP servers can be written in .NET, the question becomes whether bringing maintenance burdens onto an organization and impacting application lifespan is worthwhile. The default answer should be "no" unless there is a strong reason to say "yes."
When thinking about MCP servers, security remains paramount and performance is important. There are other security controls to consider that may not be present in usual application APIs. The typical approach of converting natural language to SQL puts the burden of creating SQL queries on the agent.
Agents are not adept at writing complex queries, especially sophisticated ones. Complex SQL queries are built upon academic concepts presented through documentation, and agents type queries based on their training. However, remarkable queries are hidden behind institutional firewalls and not published on GitHub, making training data limited.
To fully understand a query, the schema must also be fully understood. Organizations are unlikely to publish internal schemas, creating obstacles for models attempting to write good SQL queries.
The word "stochastic" derives from the English word "chaos." Models have a probabilistic nature where asking a question with three possible answers creates probabilities of which is most correct. When probabilities are statistically identical, models use random number generators to choose randomly, giving interactions a natural, conversational character.
This stochastic behavior creates problems for SQL query generation. Every time an SQL query is requested, three possible answers emerge with varying quality levels. The temperature setting in models, defaulting to 0.8, makes these possibilities converge to look identical, even when one is clearly better and another clearly worse.
Models do not attempt to destroy work or delete databases—they simply write queries with surrounding settings, internal behavior, and training constraints. The result is a good query that works against a database, but testing a thousand times provides no guarantee the 1001st time will be identical. Models are probabilistic engines always looking for inferred probabilities, not deterministic engines.
The SQL MCP server solves this by writing queries for the proxy. It presents the recipe and asks how many of each are wanted, defining tables, processes, and predicates. The MCP server then writes the query on behalf of the user, solving the first nightmare of modern-era SQL injection.
The server includes built-in pagination and flow control to ensure proxies don't crash, servers don't crash, and databases aren't overloaded. An abstraction engine makes the database schema abstract to agents, preventing the need to know database structure.
A normal database might contain 100 or 1000 tables, with 2000 tables being typical. Extracting every table, relationship, column, data type, and semantic descriptions would bypass the context window with enormous amounts of information, not including actual data or business operations. The SQL MCP server slowly leaks schema information instead.
The SQL MCP server includes Role-Based Access Authorization (RBAC) and standard OAuth authentication. When database security cannot be implemented due to permission restrictions, the SQL MCP server provides built-in capabilities for row-level security, column-level security, group security, custom predicates, and other database-level implementations.
The Data API Builder with MCP enabled becomes the SQL MCP server. It allows easy integration, reducing code while increasing capabilities and enabling intelligent agent experiences within organizations. The SQL MCP server is open source, free, provided and supported by Microsoft. It is used internally as the engine behind Microsoft Fabric and Graph API endpoints, and is an integral part of the Raven and Fabric framework.
The SQL MCP server is published as a container requiring database credentials. Environment variables can be used in Kubernetes environments, or secret managers like Azure Key Vault can be used, which is supported locally. The Azure Key Vault is Azure-specific, but the SQL MCP server and Data API Builder do not require Azure—they can run on-premises or in other clouds.
Managed Instance Identity (MI) is the best option for eliminating passwords entirely. Multiple databases can be referenced simultaneously, allowing composite queries across cloud and on-premises databases to return single payloads from multiple data sources.
Not every database needs to be Microsoft SQL, though this is considered important. The system fully supports all SQL versions in addition to PostgreSQL, including all PostgreSQL versions. It also supports Cosmos DB for adding NoSQL payloads to composite queries, as well as MySQL and MariaDB.
Consider all these database options, plus that you can have multiple databases at the exact same time. The fastest or easiest way to keep your database fast is to query it less. There is no escaping it. Therefore, the easiest way to reduce queries is simply to use caching. Where should the cache be placed? Within your Model Control Protocol (MCP).
Remember, if you're building an API, you'll need to build it with these features. We have already built it for you and we are delivering it to you ready-made. You can use Redis as a managed service as an option, run Redis in a container, or install it wherever you want. Again, the MCP server or the SQL Data Interface Builder, both are shipped as a container. Therefore, you can safely add it to your distributed application. However, if you are not a fan of containers, you can run it as a sidecar to interact with it without needing containers in your technical infrastructure.
Redis provides us with a second-level cache. We also have a first-level cache. All caching operations are managed behind the scenes by Fusion Cache. This is a perfect example where the author and developer of Fusion Cache came to our aid with implementation inside SQL MCP servers. Let me ask you, do all developers come to help you build your interfaces to perfectly match the specifications, and do they return for consultation at every update to ensure performance quality? I just wanted you to see the enormous advantages of taking advantage of this and integrating it into your applications.
Microsoft Foundry is where Microsoft hosts all of our AI models. This includes all GPT models or OpenAI models, all Anthropic models, Llama models, and everything else you can think of, right? All of them are located within Foundry, including MAI models or Microsoft AI models. It is a great way to abstract and avoid being tied to a specific source of models. What's great about it is the complete integration, where you can easily build an agent inside Foundry using any model you see fit, and then connect it to an SQL MCP server to talk to your databases on the other end. And by the way, this is hosted by you. Therefore, you decide where the container is located and where the application service is located. You are the one who decides its size and extent of expansion. It's good that we give you this flexibility so that you can do that.
We have other integrations as well. We integrate with Aspire, and we integrate with Azure application services, so we have the Easy Auth feature. There is a lot going on, perhaps more than we can talk about, but the most important thing, and perhaps what I don't want to overlook, is the OAuth protocol. As far as our security is concerned, we clearly allow no security. You could say it's not certified. That might make sense within a secure virtual private network (VNet). However, you will most likely use OAuth to interact with your secure system. It will be up to you.
As you know, you go to a website and log in using OAuth. You get that code and are able to pass it on. This is how you connect to a REST API, let's say. But for agents, it's a little different. Because the agents are slightly different, we had to provide an additional feature to solve a truly new problem in the context of artificial intelligence. They are as follows. The question is, within the database itself, whose name do you want in the audit records? If someone deletes a product from the database, do you want the SQL Server MCP to appear in the audit logs to say that MCP deleted that product? Do you want an agent? Is it the agent who removed that product, or do you want the user? Do you want the name "Jerry" to appear in the audit records so that you can see who actually did it, not what he actually did?
Well, to accomplish that, we use authentication by proxy or pass-through authentication, where I log in using OAuth normally, take my token, pass it through, and it's routed through all the different services. This is really powerful, and perhaps it's the right way to do it. There are certainly a few extra steps to make everything work, but ultimately, it makes changes and operations within your database subject to rigorous auditing to be returned to the user who performed them. Therefore, even if the user or even the agent does something unexpected, the ultimate responsibility lies with the one who made the initial summons. Therefore, there is a lot of power in being able to do that. You can apply OAuth however you like.
If you are using Microsoft Entra, we certainly support that. If you have your own OAuth provider, we support that too, because OAuth is a great standard. We are able to make all roles usable. We are able to pass your code. We use an SQL session, take all the details of your claims, and include them within the database as well. So, whether you want it detailed or simple, it's up to you.
Speaking of simplicity or detail, sometimes from an architectural standpoint, you want to deploy your application, and you say that we have a service-based architecture, where we have a lot of things and multiple databases. Most of them deserve their own application programming interface (API). This is good. We can certainly do that, because it is a small and temporary container, making it stateless and easy to use. You can put it anywhere, it hardly matters. It can enter a completely sleep state when not in use. It can wake up when needed. You can use a second-level cache if you want a warm start instead of a cold start for your containers like this. We support that too. So, it's good to know that all of this can be consistent with your current behavior.
Another architectural concept you might have is the ability to use a back-to-front (BFF) structure. Obviously, we support this, allowing you to scale up or down each independent endpoint based on the scope or type of user it serves. It's entirely up to you. Finally, if you have a command separation and are creating a read-only copy of your database, which seems to be built into everything, we support that too, as you can disable all writes at one endpoint and enable reads only, or conversely, disable reads at the other. So, in this case, the upper part writes but does not read. Below, the lower API reads but does not write. This is a great way to keep your database fast because the heavy, difficult queries you read are isolated at the bottom, and we handle the data mirroring process in the background logs so that it does not affect performance. Again, just a nice feature that could be included.
Because you are a developer, just know that we have already integrated it. We have a cross-platform command-line interface (CLI) where you can do everything and write scripts for everything. We also have Swagger built-in so you can perform REST tests. We have Nitro, formerly known as "Banana Kick Pop," where you can conduct all your GraphQL tests within VS Code. You can upload a local MCP server directly to us. We have an add-on called "Omnibus" that you can find for the Data API Builder, and we now have a new and great MSSQL add-on that I will show you shortly. It's not entirely new. We've had it for years, but it has a new capability that lets you view, interact with, and design your database schema. Interact with it and design it, then you can move on to using that same blueprint to run and design the API. So, these are really great things.
In this case, I use "DAB init" in the command-line interface here to simply select the single JSON file. This is how you control this matter. A single JSON file submitted to the container is how you control everything. It determines how I connect to my database. In this case, I am providing an environment variable to connect to my SQL Server. Then I say let's add the customers. You're not simply displaying everything. Now, you can view the tables, stored procedures, and views that you like and want to expose. Then decide which classes will be revealed. Then decide which columns to reveal. In this case, I expose everything to strangers, allowing them to create, read, update, and delete, and then I run it. This is the local developer loop. With that, I've begun. It's working now. I have a fully functional REST, GraphQL and MCP server on my local machine and it's ready to use. Isn't that so? So, this is really great. You may not have a customer schedule, so you can create your own schedule that makes sense to you.
Well, a quick overview of the SQL MCP server: it's really built around security measures to ensure that your MCP server isn't the weakest link in your proxy journey's security. Isn't that so? This is important. We care a lot about our data. We care about the security of our data. We care about the quality of our data. We care about the performance of our data. We want everything to be secure. Therefore, we have a great database with great security. However, once we open this door, we need to make sure we are protected from things like SQL injection. We may not be thinking about those things, but prompt injection is what's on our minds. Therefore, we want to restrict all capabilities while continuing to grant the agent the necessary powers to do whatever we want. What is interesting here is the ability to perform this delicate balance regarding the amount of powers that are granted or restricted.
So, if you're going to solve this problem, especially the problem of converting natural language to SQL, you're definitely going to write something similar to what we do inside the SQL MCP server. We create an abstraction layer for the entities, and then create a query-building engine that accepts instructions from the agent instead of requiring the agent to understand and be able to write SQL. Then we create a T-SQL query and execute it on the database, to return only the data to the agent. The reason this is important is that when we create a query, we create it in a deterministic way. It's identical every time, no matter what happens. This is just an extra.
We can never achieve perfect security. You will have to completely shut down your database. That's the only way to make your data completely secure. But as long as we are interacting with it, we can start by closing windows and doors to reduce all the security risks we may face. For the SQL Server MCP, trust me, we've thought long and hard over and over again to ensure that not only is the data protected, but also the proxy and its context window are protected so that we don't overwhelm it, allowing us to serve it small bits of the schema or abstraction diagram at a time.
Aside from the protective measures, we have a number of other aspects worth noting in the engine itself. Firstly, multiple data sources create a whole new world for us to design solutions, especially if these services that we create are database-centric. We have a Level 1 and Level 2 cache to keep things off the database, making simple queries—like the ones that might come in from users every morning when they all need to fill out that one drop-down list—simple. Okay, let's put that in the cache to make it instantaneous. You will look like a hero because the database is responding faster than ever before. The database can be smaller than ever because it requires very few direct queries. There is a lot of power in that.
We also have a full suite of status checks at our status endpoint, as well as support for OpenTelemetry, so if you have a unified monitoring dashboard, you can use the SQL MCP server and integrate it directly into your existing solution. Think about it. We've talked about all the backend databases and we're adding more. So you can use any database, any architecture, and any cloud, right? This is amazing. You can use any programming language you want to write in. There are no libraries and there are no frameworks. It is delivered to you as a container that you can run either inside Kubernetes, or inside ACA or ACI, or you can simply run it as a "sidecar" for your web application. The whole thing is open source and free. This is perhaps one of the most wonderful things that could be said. Definitely not what I expected.
So, let me show you this very quickly. This is the designer, yes. Time is running out for us if you want to answer any questions. Ah, so I really want that. Yes, you are right. Let me...let me... let me not talk about him and say that this is the API designer, and that was my last slide anyway. Okay, great. And you have the link there so people can find out more. So, this is perfect. This is correct. Yes, Jerry.
We have a question from Donny J 266 asked: "Can we use it for schema optimization, bulk inserts, database maintenance, and tasks along with query analysis? Is this part of that?" If you want to perform schema processing, you certainly wouldn't do it against a production database. You will do this against a developer database or possibly an Acceptance Testing (UAT) environment. And we have another MCP server for that. This is an MSSQL extension within VS Code that gives you complete freedom. You can do that. You can run any SQL query against the database in this way. So, if you need to... what would happen if we added this column? What would happen if we deleted this table? All of that makes sense within that developer circle. It certainly doesn't make sense to do that against your production database. This is an MCP server dedicated to your production database. Great, thank you. Yes. Yes. And also, sorry to talk about VS Code. Writer extensions are on the way. Oh, that's good. Good news.
Okay, we'll wrap up with one last question for you while our next speaker prepares to share their screen. However, as you know, privacy and data security are always a big topic these days. If a company is resisting vectors because it doesn't want its data or queries used to train models, is there an approach they can use with your tools to keep their data secure? Yes, that's an excellent point. I mean, now that we have a vector data type, in order to get the data in the vector, some model has to do it for you. Therefore, you can use remote forms, such as those in Microsoft domains, but you can also use local forms. For example, the Department of Defense is clearly a client of Microsoft. They do not want any information to be able to cross their boundaries. Therefore, they can run the models internally or within the database itself. The SQL MCP server, which is currently in preview, can host an ONNX model in a database-managed ONNX runtime environment. Amazing. Okay, thank you for all the information about SQL Server and MCP servers, Jerry. I really appreciate you being with us today. Thank you, Pak. I appreciate that. Okay. We will see you again.
Keep JetBrains in your library
Save the videos and channels worth coming back to, and find them again in one place.
